Git push: Three modes of pushing local changes to a remote repository

Abstract: Because No-fast-forward push is rejected during git push, how to resolve the problem of Git push failure. There are three methods that will form the merge form of the commit history, the linear form of the commit history, covering the original commit history.

This article source: Three modes of Git push

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

Now, the latest server-side version is x, User A and the user has clone code, and then to develop; User A completes version a, and commits, when the server-side version history becomes:

X------A

The version submission history on the user's machine is x--------B

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

Both the remote and local refs are stored under the local. Git directory, and there is 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

Recalling the storage model created by the branch we have previously learned, the essence of push is the creation of a commit object in the remote and the updating of the pointer. In other words, if User B is push at this point, then X descendants will point to B,b's parent and point to X, and then our X descendants have pointed to a, so it will fail.

2. Programme I: Mandatory coverage

In some cases, you need to make mandatory overrides for someone else's submission (and possibly your own). For example, the following is the case:

There is another common situation where the encounter non-fast-forward rejection when you try to push, and it is poss Ible even when you are pushing to a repository nobody else pushes into. After your push commit A yourself (in the first picture in this section), replace it with "git commit--amend" to produce C Ommit B, and you try-to-push it out, because forgot, which has pushed A out already.

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

3. Programme II: Submission history in the form of a merge

This is the most common situation if you do not want to lose your job and do not want to lose someone else's work (you need to save from X to A and B and commit history) before each push, we first pull the latest version from the server (thus updating the local storage refs/remotes/ Origin/master), handle conflicts, and then push, there is no problem. At this point, the resulting commit history is as follows:

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

4. Scenario Three: Forming a linear commit history

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

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

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