Your branch and 'origin/master' have diverged, and have # and # different commits each, respectively


當你的分支打算push到master遠端分支的時候,會經常出現上述的提示。

這個問題遇到過好多次了,以至於再不寫日記我都要崩潰了,其實原因很簡單,就是到了該merge或者rebase的時候了

下面的文章是轉載的,我覺得寫的很好,雖然是英文版,但是不難理解。原文地址:http://blog.chinaunix.net/uid-25885064-id-3362631.html

You can review the differences with a:

$ git log HEAD..origin/master

before pulling it (fetch + merge) (see also "How do you get git to always pull from a specific branch?")

When you have a message like:

"Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively."

, check if you need to update origin. If origin is up-to-date, then some commits have been pushed to origin from another repo while you made your own commits locally.

... o ---- o ---- A ---- B origin/master (upstream work) 
                         \ 
                            C master (your work)

You based commit C on commit A because that was the latest work you had fetched from upstream at the time.
However, before you tried to push back to origin someone else pushed commit B.
Development history has diverged into separate paths.

You can then merge or rebase. See this FAQ for instance:

Merge

Use the git merge command:

$ git merge origin/master

This tells Git to integrate the changes from origin/master into your work and create a merge commit.
The graph of history now looks like this:

... o ---- o ---- A ---- B origin/master (upstream work) 
                         \        \
                            C ---- M master (your work)

The new merge commit M has two parents, each representing one path of development that led to the content stored in the commit.

Note that the history behind M is now non-linear.
We have chosen (for now) to disallow non-linear history in cmake.org/cmake.git so an attempt to push M into our repository will fail.
Until this restriction is lifted, please rebase your work instead.

Rebase

Use the git rebase command:

$ git rebase origin/master

This tells Git to replay commit C (your work) as if you had based it on commit B instead of A.
CVS and Subversion users routinely rebase their local changes on top of upstream work when they update before commit.
Git just adds explicit separation between the commit and rebase steps.

The graph of history now looks like this:

... o ---- o ---- A ---- B origin/master (upstream work) 
                                  \
                                      C' master (your work)

Commit C' is a new commit created by the git rebase command.
It is different from C in two ways:

  1. It has a different history: B instead of A.
  2. It's content accounts for changes in both B and C: it is the same as M from the merge example.

Note that the history behind C' is still linear.
We have chosen (for now) to allow only linear history in cmake.org/cmake.git.
This approach preserves the CVS-based workflow used previously and may ease the transition.
An attempt to push C' into our repository will work (assuming you have permissions and no one has pushed while you were rebasing).

The git pull command provides a shorthand way to fetch from origin and rebase local work on it:

$ git pull --rebase

This combines the above fetch and rebase steps into one command.


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM