Git push: Three modes of push local change to remote warehouse

Absrtact: As the No-fast-forward push is rejected during git push, how to solve the problem of git push failure. There are three ways to form the submission history of the merge form, the linear form of submission history, covering the original submission history.

This article comes from: three modes of Git push

Address: http://blog.csdn.net/trochiluses/article/details/14517379 1.git Push generation conflict formation process

Now, the latest version of the server side is x; User A and the user has the clone code separately and then developed; User A completes version A and submits, at which point the server-side version history becomes:

X------A

User has the version submitted on the machine history is x--------B

The result of Git push is this: Update remote refs along with associated objects

Where both the remote and local refs are stored under the local. Git directory and have only one refs:

Remote refs:

Hyk@hyk-linux:~/xfstests/.git (Master)
$ cat Refs/remotes/origin/master
56a3959a96f1b5e046b3760778fd34b4911d0516

Local refs:

Hyk@hyk-linux:~/xfstests/.git (Master)
$ cat Refs/heads/master
2c13da0b38b794581790ed0122a674d6ad6113ba

Looking back at the storage model created by the branch we have learned, the essence of the push is the creation of a commit object in the remote and the updating of the pointer. That is, if User B is pushed at this point, then the X descendant will point to B,b's parent and point to X, and then our X descendants are already pointing to a, so we fail.

2. Programme I: Mandatory coverage

In some cases, you need to impose a mandatory overlay on someone else's submission (and possibly your own). For example, the following scenario:

There is another common situation where/may encounter non-fast-forward if you try to push, and it is rejection Ible even when you are are pushing into a repository else nobody. After your push commit A yourself (in the the "the" the "I"), replace it with "Git commits--amend" to produce C Ommit B, and you try to push it out, because forgot that you have pushed A out already.

At this point, we just need to execute the command; git push--force

3. Programme II: The submission History of the form of a merge

This is the most common scenario, if you don't want to lose your job and don't want to lose someone else's work (you need to save both from X to A and B and submit history) before each push, we first pull the latest version from the server (this updates the local storage refs/remotes/ Origin/master), dealing with conflicts, and then push, will not cause problems. At this time, the formation of the history of submission is as follows:

B---C
/     /
---X---A

4. Programme III: Form a linear submission history

In many cases, in order to maintain the cleanliness of the submission history, we need to form a linear submission history. Still in this example: we can extract the diff between x and b, apply this diff to a, and form the following history of submission:

------x-------A--------D (the diff of X and B)

At this point, the command you need is: Git push--rebase