How to use Git

Are you sometimes afraid of trying something out, because you don’t know if it will work and then you’ll have to somehow undo everything? Well, you should be using a version control system, a VCS, like Git.

You’ll have a history of all the changes that you made. You’ll be able to see exactly what lines of code you changed. And if you find a bug, you can go back in time to see at what point the bug first appeared and then you’ll know what change created it—this makes the bug much easier to understand!

So let’s learn the basics of working with a VCS like Git.

Commits

The core of Git are commits. You should aim to commit you code after every change. With Git you can make each commit come alive again and have everything just the way it was back then!

Commit messages are important. Writing good messages has to be learned, because at first you won’t know what is important to include in there. Over time, when you have had to go back to fix things a few times, you’ll understand what you want from a commit message and it will get easier to write good ones. So just keep doing it!

That being said, there is a popular guideline for writing commit messages that I suggest you try: Use a command. Do not describe what has happend, like “Buttons made pink”, but rather “Make buttons pink”. A way to remember this form is to complete the sentence “If applied, this commit will …”. So in this example, “if applied, this commit will Make buttons pink.”

If you have other important information about the change that are difficult to summarize in one line, add it to the message as a paragraph! Just hit Enter twice and explain what and why you changed it. The first part of a commit message should be short, but here you can give all the information that is needed to understand the commit. Note that Git will easily show you what the exact changes were, so you don’t need to include that in the commit message. Use the commit message to summarize and motivate your change, so that others looking through the history will know whether they need to have a closer look at this commit.

Branches

Branches are what allows you to experiment and easily go back to a previous state. The idea is that you say, “Ok, I’d like to try making the buttons change color when clicked. But if anything goes wrong, I’d like to go back to how everything is right now.” Branches are how you mark where you are now and, in this case, the changes that you made trying to make buttons change color.

You can easily switch between branches. So if in the middle of working on the buttons’ color change you find a bug that you need to fix, you can do that on the regular branch. Later on, when you’ve finished the color-changing buttons, you can merge those changes from the color-changing branch with the normal branch.