Git Fundamentals: How To Collaborate

This git fundamentals post will help you to understand how to collaborate using git with your colleagues. Considering you already know what is git and how to create a repository, now we can dig further using git effectively with other collaborators. Note that this won’t include open source project approach. Even the principle is the same, some of the projects have different requirements for pull requests. You can further investigate how to create pull requests for this.

First of all, I would like to stress what a development process would be like without source control. A friendly advice: if you think it is hard to work with git, think twice. It might take a while to understand and get used to work on git, but it definetely worths your time.

Without source control, basicly the major problems are those:

  • In order to work together, you should set up a NAS, cloud or use something like USB to share your work between your colleagues.
  • It would be impossible to work on the same code at the same time. If not careful, you can override your friends work with your save. If you are careful, you should check the conflicts by hand.
  • You can’t check the progress of your colleagues and create test builds using only the features you want to test out

The list above is the common problems, and imagine you can hit much more road blocks in the development process.

The Theory

Before diving further, we should talk about some theory first. In order to work effectively you and your collaborators should know the theory behind Git. To keep it simple, we will focus on 2 developers: Back-End and Front-End.

Consider your repository is a station at the beginning of a road and each developer is at the same station. Since they are working on different stuff, they should take different paths from that station. When Front-End finishes his work, he puts his work into the road, as a new station. Same applies for Back-End developer as well. This time, when Back-End developer puts her work into the road, it is automatically put after Front-End station. Now that the road contains 2 developers work, when they start a new path they will both have that stations combined together. To illustrate this in a graph

As you can see above, Road now includes all work done! Whenever someone creates a new path from Road 3, they will all have the work done so far, allowing everyone to keep up. All those Road, and Paths are actually called branches. Branching is one of the most important things you should learn while collaborating. There are different branching approaches around, you should find or create one that best suits your workflow. You can check GitFlow, an extension for making branching easily. But we will focus on our simple branching model, close to GitFlow rules.


Here, we have our basic branching rules every colleague should use:

  1. Master Branch: Master branch will be your release branch. Everything merged to here should have passed QA tests.
  2. Develop Branch: Everything worked on should be merged into develop. When time comes, QA should test from latest commit’s build. When everything is in order, develop merges into master for release.
  3. Feature Branches: Feature branches are the branches you will spend time mostly. Since branches can be nested, if you create a branch feature/MyBranch it will be created under feature, just like a folder. Those features can be merged into develop.

When you create a repository, there will be a master branch by default. When you clone the repo for the first time (considering you didn’t directly checked-out to a different branch) you will also be checked-out to master branch. You can use that branch to push your initial commit including your .gitignore and readme files. Then, time to create your first branch:

This will create develop branch and check out to it. This branch includes everything commited to master branch at the time you checked-out. You can also create and check-out to a branch with a single command: ‘git branch -b develop’. Now everything seems to be set up. but you need to push your branch to server to let your colleagues, access it.

You will realise there is an error telling you there is no branch on server called develop, and it shows a code instead to set upstream. You can copy-paste that code to push it to remote. Once you have pushed develop into remote, you can only use push command instead.

Now it is time for your colleagues to checkout to remote develop to create their branches.

This code pulls the develop branch and tracks it. Basicly tracking is saying “this branch on my local is that branch on remote” in a short way.

Working on feature branch

This section is a general approach for all your collaborators. It is time to create your own branch to move on

Now you have your own feature branch to work on. When you have created files, you are ready to commit. Don’t forget, commiting is also useful when you wan’t to revert your changes back, until you push to remote. Here is the code to do so:

You can continue commiting your changes whenever you feel right. You can also push your code to remote. First, check if you have anything left to be commited and be sure you are on the correct branch.

With that command, you can see untracked files as well. If you need to commit files, you can do so. Otherwise no necessary files have changed, you can set them to their first state.

You can also stash files to get back to them, but to keep it simple I am not going to explain it. You can further investigate how to use stash commands from Git SCM. Now that your branch is clean, you can either push it to remote or merge directly into develop. If you are working on a branch that should take time, you can push it to remote a prototype version, so that other colleagues can merge it to their branches to keep adding their code.

If you want to keep going on that branch, you can use

If you haven’t pushed remote before, you will see that upstream error meaning there is no such branch on remote. Simply use the given code and push it to remote. Now that you can continue commiting changes into your local as long as it takes.

If you want to finish this feature for good, then without pushing you can directly merge it into develop branch. To do so, you should checkout to develop branch.

Now that you have the latest develop branch, you can merge your branch into develop and push it. Be sure that you are still on develop branch!

If there is no conflict between your changes and develop’s changes, it should directly merge. Otherwise, console will give you conflict error where you should edit conflicts. There are lots of different GUI merge tools to help you out there! I am using Meld on Windows, but if I was using MacOS I would definetely use Kaleidoscope. You can also use GUI Git Clients such as SourceTree and GitKraken, where they have conflict resolving GUI as well. Decide an app, and learn their approach how to resolve conflicts. Basicly, they have your code and the code on branch side-by-side. You can see who deleted what and added where, so you can add yours into final one. This final one will be the resolved file.


You are asking where is the collaboration part, right? Well, above is the general workflow working on branches actually. But consider this, if everyone minds the rules above, they should do the very same thing on different branches, just like you did above! So, to sum it up:

  • Create a branching rule. One of the most common approach is master, develop and features. Be sure to know what merges into where.
  • Don’t commit unnecessary changes. Commit often, when necessary.
  • Check your status before commiting and pushing.
  • Use clear commit messages, your colleagues needs to understand what you did from those messages.
  • Don’t leave your HEAD with uncommited changes, if you try to checkout you may conflict with existing ones. You can stash them, or revert them if unnecessary.
  • Whenever you checkout to a branch used by multiple collaborators, always fetch and see if you are behind the remote branch.
  • Solve conflicts and test them. Don’t be shy to ask your colleagues if a conflict is hard to solve (for instance, changing a method). When you are sure everything is in order, then push.

I hope these fundamentals series help you out! In my next post I will be explaining using LFS (Large File System).

Leave a Reply