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
-
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. ↩