Sometimes, collaborating in a group project can be a hassle. Everyone has their own piece of code that they need to add. One way you could work together is by using a shared file system, where everyone has access to the same files. But of course this system would consume a lot of time, because only one person can only modify a certain file at a time to avoid overwriting other members’ works.

A better approach for team projects is by using Git. Git is a version control which allows us to work parallelly to our other team members. When you want to integrate your changes into the main code, you can easily merge your work with Git. Git can also help us ensure that there aren’t any conflicts in between codes and monitor the changes that happen to the group project.

Setting up a Git repository

A Git repository stores all the files related to your project and tracks any changes that happen to them. A local repository is a repository stored on your computer, whereas a remote repository is a repository that is connected to an online host (such as GitLab or GitHub).

To get started, create an empty folder on your computer and run the following command:

This will initialize an empty repository in the folder.

Another way to create a repository on your computer is with git clone. This command will copy a remote repository and its contents into your designated folder.

Staging and Committing Files

Now that you have a Git repository, you can start adding your files and codes into the project folder. Soon, you will want to record your changes into your repository by committing them. In order to do that, you will need to stage your changes. Staging essentially means telling Git which files you want to commit.

You can stage certain files using:

To stage all of your changed files in your project folder at once, you can also use:

After staging, you can commit your files with:

When you write your commit message, make sure to use meaningful descriptions of your commit, so that it is easier to keep track of your commits.


Image from

Git branches are pointers to the changes that you have made. You can switch branches to isolate your changes from your team’s codes. By default, the main branch when a repository is created is called the master branch.

You can view your local branches with:

You can also view your remote branches with:

To create a new branch and switch to that branch, you can use the following command:

To move to another branch, use:

In order to let other developers access your branch, you will need to push your branch into a remote repository by using:

Pulling and Merging Branches

Remote repositories are constantly changing when working in a team. To keep your local repository up to date, it is important to pull changes from your team’s main branch.

You can also combine two branches together using the merge command. For example, you want to merge branch-a into the master branch. First, switch to the master branch then run the following command.

Sometimes after merging there won’t be any conflicts left, but in other cases you will have to resolve the conflicts manually.

Undoing a Commit

One way to undo a commit is to use the revert command. This command will create a new commit containing a version of your code without the change you want to undo.

The syntax for git revert is:

To revert your latest commit, run:

You can also revert a certain commit with:

Git Flow and How It’s Implemented

A popular workflow for collaborative projects using Git is Git Flow. Some advantages of using Git Flow are that it facilitates tracking the work of each team member and also eases deployment. In this guide, I will also be sharing how my team implements Git Flow.

Git Flow diagram (from PPL Git Flow Guide)

Our workflow consists of a few branches which are master, staging, hotfix, coldfix, PBI (Product Backlog Item), and task branches. When we develop our own piece of work, we first push it to our own task branches. After we are done with our task, we merge our task branch into our corresponding PBI branch. Before our sprint review, we merge all the PBI branches into our staging branch. If the product owner approves our code, we can merge the staging branch into the master branch which is where we store the code that is ready for deployment. If there is a PBI that the product owner doesn’t approve, we rollback the corresponding PBI changes into the coldfix branch. The hotfix branch is for debugging any issue that is found in the master.

The branches from our project

Keep on Exploring

This guide has covered the basics of Git, but there are many more helpful options and commands that Git has to offer. So, don’t forget to keep learning and exploring!


PPL Git Flow Guide

A computer science student.