If you’re going to be a developer, you can’t be afraid of commitment.
It's okay. You can do this.
The “commit” command is used to save your changes to your repository. Each change you make - adding or removing a space, changing a character from lowercase to capital, adding or removing variables - is noted as an update by your computer and a commit will save them to your repo, along with when they were made.
Not only does git help keep straight which version of a program is current or being worked on, git commits preserve the history of its development. Unlike a regular “ctrl+s”, every commit is a snapshot of where the code was at that moment in time, and every message shines a little light on why things were changed. Not only is this helpful for others, it can be helpful for you if you pick up a project you haven’t worked on in a while.
Commits should be made often and cover small, digestible chunks of code and/or code that is related by a single idea. That is, you don’t need to necessarily commit after defining a variable, but it would be a good idea to commit after writing the function you’re using the variable in.
If you grew up in a time before autosaves, you’ll remember Save Early, Safe Often - it’s a good rule of thumb here. It’s possible to return (or revert) to a prior commit, which is helpful if you’ve just gotten so far round the bend you’re not sure who you are or where you came from anymore. If you’ve been diligent about your commits, you may not have to back up very much. If not, you could end up too close to the beginning and losing a lot of your good progress.
From the command line, you need to add your changes and then commit them with a message re: what the changes are about. For simplicity in this description, we’re going to use “git add .” which will add all of your changes. (If you’re curious, you can absolutely be more specific: see here and here.) This is called staging a commit.
Once your changes have been added/staged, you need to commit with a helpful message. The command line will look as below. The “-m” denotes “message” and the comment in quotes is what your message will be.
git add .
git commit -m “helpful message here”
Commit messages describe the changes that are made in the commit.
Here, I specified that the change was to “remove unnecessary p tag.” When opening the code to look at the changes, the change that was made matches up with what I said in the comment.
Messages should be short and written in the present tense, not past tense - fix bug, versus fixed bug. Most importantly, the messages should describe the changes that were made. This is easy when you’re making small changes and need to make a brief statement. If you need more room to add context, that can be done too. The most important thing to take away is that the messages will provide explanation and context for others who look at your code later.
Think about reviewing work you did a long time ago - maybe pulling out an old essay from middle school - and seeing scratched out text and changes all over it, making it hard to read. It would be helpful to have some notes explaining why past-you made those changes, right? That’s what you’re doing with commit messages.
Now you go forth and create things.