Multi-person collaboration in git branch management

Posted by chrisC on Wed, 17 Jul 2019 20:48:43 +0200

When you clone from a remote warehouse, Git actually automatically maps the local master branch to the remote master branch, and the default name of the remote warehouse is origin.

To view information about remote libraries, use git remote:

$ git remote
origin

Or, display more detailed information with git remote-v:

$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

The origin address that can be crawled and pushed is shown above. If you do not have push permission, you will not see the address of push.

Push branch

Push branch is to push all local submissions on that branch to remote libraries. When pushing, you specify a local branch so that Git pushes the branch to the remote branch corresponding to the remote library:

$ git push origin master

If you want to push other branches, such as dev, change to:

$ git push origin dev

However, it is not necessary to push local branches to remote locations, so which branches need to be pushed and which do not need to be pushed?

  • The master branch is the main branch, so it should be synchronized with the remote at all times.

  • The dev branch is a development branch. All members of the team need to work on it, so they also need to synchronize with the remote.

  • The bug branch is only used to fix bugs locally, so there's no need to push it remotely unless the boss wants to see how many bugs you fix each week.

  • Whether feature branches are pushed remotely depends on whether you work with your small partners to develop them.

In short, in Git, branches can be hidden and played locally. Whether they are pushed or not depends on your mood.

Grab branch

When multiple people collaborate, everyone pushes their changes to the master and dev branches.

Now, simulate one of your buddies and clone it on another computer (note that SSH Key should be added to GitHub) or in another directory of the same computer:

$ git clone git@github.com:michaelliao/learngit.git
Cloning into 'learngit'...
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 46 (delta 16), reused 45 (delta 15)
Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.
Resolving deltas: 100% (16/16), done.

By default, when your partner is from a remote library clone, your partner can only see the local master branch. Believe it or not, you can use the git branch command to see:

$ git branch
* master

Now, to develop on the dev branch, your buddy has to create the dev branch of the remote origin to the local, so he uses this command to create the local dev branch:

$ git checkout -b dev origin/dev

Now, he can continue to modify it on dev, and then push the dev branch to remote from time to time:

$ git commit -m "add /usr/bin/env"
[dev 291bea8] add /usr/bin/env
 1 file changed, 1 insertion(+)
$ git push origin dev
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 349 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
   fc38031..291bea8  dev -> dev

Your buddy has pushed his submission to the origin/dev branch, and you happen to have modified the same file and tried to push:

$ git add hello.py 
$ git commit -m "add coding: utf-8"
[dev bd6ae48] add coding: utf-8
 1 file changed, 1 insertion(+)
$ git push origin dev
To git@github.com:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Push fails because your partner's latest submission conflicts with the submission you're trying to push, and the solution is simple. Git has prompted us to grab the latest Submission from origin/dev with git pull, then merge locally, resolve the conflict, and then push:

$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
   fc38031..291bea8  dev        -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream dev origin/<branch>

git pull also failed because no link was specified between the local dev branch and the remote origin/dev branch. According to the prompt, set the link between Dev and origin/dev:

$ git branch --set-upstream dev origin/dev
Branch dev set up to track remote branch dev from origin.

pull again:

$ git pull
Auto-merging hello.py
CONFLICT (content): Merge conflict in hello.py
Automatic merge failed; fix conflicts and then commit the result.

This time git pull was successful, but there was a conflict in the merger, which needed to be solved manually, in the solution and in the branch management. Conflict resolution It's exactly the same. After resolving, submit and push:

$ git commit -m "merge & fix hello.py"
[dev adca45d] merge & fix hello.py
$ git push origin dev
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 747 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
   291bea8..adca45d  dev -> dev

Therefore, the working mode of multi-person collaboration is usually as follows:

  1. First, you can try to push your own modifications with git push origin branch-name.

  2. If the push fails, because the remote branch is newer than your local branch, you need to use git pull to try to merge first.

  3. If there is a conflict in the merger, the conflict will be resolved and submitted locally.

  4. No conflict or conflict resolution, then git push origin branch-name push can succeed!

If git pull prompts "no tracking information", then the link relationship between the local branch and the remote branch is not created. Use the command git branch --set-upstream branch-name origin/branch-name.

This is the working mode of multi-person collaboration, once familiar with it, it is very simple.

Summary

  • View the remote library information, using git remote-v;

  • Locally built branches are invisible to others if they are not pushed to remote locations.

  • From the local push branch, use git push origin branch-name. If the push fails, use git pull to grab the remote new submission first.

  • Create branches corresponding to remote branches locally, and use git checkout-b branch-name origin/branch-name, the names of local and remote branches are best consistent;

  • Establish the relationship between local branch and remote branch, using git branch --set-upstream branch-name origin/branch-name;

  • Grab branches remotely and use git pull. If there is a conflict, handle the conflict first.

Topics: git github ssh