Collaborating on a project

As discussed in previous sections, the practical way to collaborate on a project is through a web platform, as Github or a Gitlab instance. There are two situations.

Without write access

If you do not know the owner of the project, you do not have write access to the repository on the hosting site, then you create a fork of the project on the hosting site, you make your modifications on your forked repository, and you send a "message" to the owner of the original repository, asking him to include your contribution. The message is not an email message! It is a request you make through the web interface and it is called a "pull request" or a "merge request". The web interface is designed to make this process very easy. See Forking Workflow.

With write access

On the other hand, if you are officially in the team developping the project, then you have write access to the original repository on the hosting site, you do not need to fork the project there.

Suppose you clone the project on your local computer and make some local commits. Then you try to push your commits. This will work only if no one else has pushed to the remote repository in the meantime. If there has been pushed commits by someone else then you will get an error message. You need to get the new commits from the remote repository with the command:

git fetch

This command does not modify your working directory, it just makes the commits from the remote repository available locally in a read-only branch called origin/master. You have to merge it with your local master branch:

git merge origin/master

As if you were merging local branches (see Branches), you may have conflicts to solve.1

Note that git pull is equivalent to chaining the two commands above.

Writing directly on the master branch, as suggested above, is the simplest policy for collaboration on a Git project. A collaboration policy is also called a "workflow". In a little more complicated workflow, one rebases commits instead of merging them. The command is:

git rebase origin/master

instead of git merge. See Centralized Workflow.

More elaborate policies are often used, involving work with several branches. Popular workflows are the Git flow, the Github flow and the Gitlab flow.

Useful introspection commands

To see branches existing on the remote repository:

git remote show origin

To show local branches, with their relation to remote branches:

git branch -vv

The information which is displayed dates from the last git fetch. To update information on all branches:

git fetch --all


  1. If you come from Subversion, it is interesting to note that Git forces you to merge locally, even if the modifications on the server are on other files than the files you modified locally. In the same situation, Subversion would accept your commit and just do the merge on the server.