close-up of a fern plant in the shade

Welcome to the blog

Your Coding
Resources

Working with Git: Version control for your project

decoration scribbly

by Claudia Engelsman

Remember writing Word documents and then saving your final version as XYZ-Final2-FINAL.doc? Meanwhile, there are about 5 other versions with final in their name and at least 3 with capital letters in it. With coding, you will have different versions of your project as well and Version control is the solution for this in coding. There are many different tools to do this and Git is by far the most commonly known way to go. All version control tools keep track of changes in code. This is super handy when working together on a project. It allows for comparisons between code, easily spot the difference between the code that the website is now running on and the changes you or your colleagues made. This is also particularly handy when something unfortunately breaks, you can easily go back to an older version when everything was working fine and dandy. Let’s set up Git and see how it works!

Setting up Git

Starting to work with Git will have you install Git first. You can get it here. After Git is installed you will have to go open your terminal and navigate to your project folder where your first code might already be, or not yet that’s ok too. When you’re in your project folder with your terminal, type ‘git init’ to make this project version controlled with Git. Tada! You are now using Git. Because the terminal is a pretty ugly place with a bad overview I prefer using the more graphical interface of a Git GUI.

A Git GUI is an extra program to download and possibly buy (there are free options available too) and if you don’t want to do that, the terminal is a fine option too. I only use the terminal if I have an issue with my GUI, so I will not get into that too deep right now and instead quickly mention my 2 most used GUIs.

The first one I’ve ever used is Sourcetree by Atlassian. It looks a bit outdated, but it has a nice graph and lists all the recent commits, making it easy to search through. It is free to download and use, which is nice to start with. I have noticed that if I have more projects to keep track of, Sourcetree gets slower and slower.

My favourite is the cute GitKraken, they have this super cute squid animation (totally irrelevant for functionality but I still love it) and their GUI looks so much sleeker and nicer than Sourcetree’s. They have a free version with which you can do all the basics as long as your project is set to public. We will get into public and private projects in the next post, for now this is not yet important.

You can download Sourcetree here and GitKraken here.

Disclaimer: this GitKraken link is a referral link, if you enjoy GitKraken so much that you upgrade it to a paid account in the future (at no extra costs to you), I might get a sticker. Or if more people do this, possibly a T-shirt. Woop!

After you install either of these, you can open your project folder with it, and it should recognize the .git folder that was set up in your project by the ‘git init’ command. You are now set to work with it. For this article we will use GitKraken for reference, it is free and super easy to set up.

Staging code and commits

When you are working on your project, every file that changes will be shown on the right side of your overview in GitKraken. You can ‘stage’ files or part(s) of them: hunks. You will want to group changes together with a common goal or functionality. After staging your files, you have to add a message to it, describing what that group of code does. I was taught to write commit messages that finish the sentence “This code will…”, in this example my message will be ‘add a navigation menu to the homepage’. Being consistent with this, as well as descriptive will save you many headaches and trouble in the future.

When you are happy with your group of code and your accompanying message, you click ‘commit’. This will save these changes with the message, your commit message, and create a new entry in Git. This will create the first commit in what will become a timeline of your project. If you have been working on different things at the same time you will still have a few files that are unstaged. For example, if you have worked on adding a navigation menu, added an about page, and edited a paragraph on your homepage, you will probably want to split this into 3 separate commits. Each commit saves that group of code to be part of your project. Making small commits makes it easier to track and to change things back if it turns out a little different than expected. If you have these 3 changes in 1 commit, and you want to undo the navigation menu for example, you will also undo the text edit and the about page if you have grouped these together. Commits don’t cost anything and you can make as many as you want, so follow this best practice and split things up.

The cool part about Git is that it does not save your whole project over and over again. You will not end up with hundreds of project folders all a little different from each other. Git is smart and only saves the changes. It layers all your changes in chronological order on top of each other and that is how you get to a new version every time. This also makes it easier to go back to a previous version. Don’t like your changes from last week but you don’t remember exactly where you added code and what you changed? Git knows, find the commit, and you can see exactly what changed, and if you want to undo it, Git can do that for you as well.

This is also why commit messages matter, they tell you, or someone else, what the code in that change is for. If you just name your commit ‘Bob’, it looks funny but it doesn’t help you when you’re trying to find where and when you changed the menu 4 months ago. Don’t name your commits ‘Bob’ and be as descriptive with them as possible. Instead of saying ‘change the font size’ say ‘increase font size’ that way you know in what way it has changed, and even better state shortly why it was done, ‘increase font size to improve readability on mobile screens’ is a lot more descriptive than ‘change font size’ and contains much more information. You never know when you might be reading back these messages and what you are looking for in the future, so help yourself and make the most of it.

Master branch

You might have seen it in your GitKraken already, on the left side, this thing called master… This means you are on the master branch of your project. Your project can have multiple branches, like a tree. Your first and most important branch is the master branch. In projects everywhere that is the version of the project that is live for customers to see. Let’s call it the FINAL-final version of today, because we all are working constantly to make our websites better right? In a few days there might be a newer version of the master branch, with a nice new feature on the website. 

I will leave you for now to work with this info, and next time we will dive more into branches and how to work with multiple people on the same project with Git. I feel this is enough to get you started with Git and you should be able to work on your project and practice making some commits on it. Next week, when we continue, you will feel more confident about this part and will be ready for more.

<< Back to blog overviewThe career path for developers is ridiculous  >>