主分支和'起源/主'分歧，如何“分支”分支？ [英] master branch and 'origin/master' have diverged, how to 'undiverge' branches'?
问题描述
您可以查看差异：
< pre $
git log HEAD..origin / master
before < （抓取+合并）（另请参阅如何让git总是从特定的分支中拉出来？ ）
当您有如下消息：
您的分支和'origin / master'已经分开，＃分别有1个和1个不同的提交。
，检查你是否需要更新 origin 。如果 origin 是最新的，那么当你做出你的提交时，一些提交已经从另一个repo推送到 origin 自己在本地提交。
... o ---- o ---- A ---- B origin / master （上游工作）
\
C大师（您的工作）
您因为这是你从上游取得的最新工作。
然而，在你试图推回原点之前，其他人推动提交B.
发展历史已经分化为不同的路径。
然后您可以合并或重新绑定。详情请参阅 Pro Git：Git Branching - Rebasing 。
$ b
合并
使用git merge命令：
$ git merge origin / master
告诉Git将来自 origin / master 的更改集成到您的工作中并创建合并提交。
历史图现在看起来像这样：
... o ---- o ---- A ---- B原点/主（上游工作）
\\
C ---- M master（您的工作）
新的合并提交M有两个父母，每个代表一个开发路径，导致存储在该提交中的内容。
请注意M背后的历史现在非线性的。
Rebase 使用git rebase命令： p>
$ git rebase origin / master
这会告诉Git重放提交C（您的工作）已将其基于提交B而不是A.
CVS和Subversion用户在提交之前更新上层工作时重新定位本地更改。
Git仅添加显式间隔提交和rebase的步骤。
历史图现在看起来像这样：
提交C'是由git rebase命令创建的新提交。
它不同从C有两种方式：
- 它具有不同的历史记录：B而不是A.
- 其内容包含B和C两方面的变化;它与合并示例中的M相同。
请注意，C'后面的历史记录仍然是线性的。
我们选择了（现在）允许只有 cmake.org/cmake.git 中的线性历史记录
此方法保留了以前使用的基于CVS的工作流程，并且可能会缓解转换过程。 >
尝试将C'推入我们的存储库将会工作（假设您有权限，并且在您重新绑定时没有人推送）。
git pull命令提供了一种简单的方式来从原点获取并重新绑定本地工作：
$ git pull --rebase
这将上面的提取和底座步骤组合成一个命令。
Somehow my master and my origin/master branch have diverged. I actually don't want them to be diverged. How can I view these differences and 'merge' them?
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 Pro Git: Git Branching - Rebasing for details.
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 that commit.
Note that the history behind M is now non-linear.
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:
- It has a different history: B instead of A.
- Its 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.
这篇关于主分支和'起源/主'分歧，如何“分支”分支？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
