master 分支和 'origin/master' 有分歧，如何“undiverge"分支? [英] master branch and 'origin/master' have diverged, how to 'undiverge' branches'?
问题描述
不知何故，我的 master 和我的 origin/master 分支出现了分歧.
我其实不想让他们分道扬镳.
Somehow my master and my origin/master branch have diverged.
I actually don't want them to diverge.
如何查看这些差异并合并它们?
How can I view these differences and merge them?
推荐答案
您可以查看差异 使用:
git log HEAD..origin/master
在拉取它之前(获取+合并)(另见如何让 git 始终从特定分支拉取?")
before pulling it (fetch + merge) (see also "How do you get git to always pull from a specific branch?")
当您收到以下消息时:
你的分支和‘origin/master’已经不同，#并且分别有 1 个和 1 个不同的提交."
"Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively."
，检查您是否需要更新origin.如果 origin 是最新的，那么当您在本地进行自己的提交时，一些提交已从另一个存储库推送到 origin.
, 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)
您将提交 C 基于提交 A，因为这是您当时从上游获取的最新工作.
You based commit C on commit A because that was the latest work you had fetched from upstream at the time.
然而，在你尝试推回原点之前，其他人推了提交 B.
发展历史已分为不同的路径.
However, before you tried to push back to origin, someone else pushed commit B.
Development history has diverged into separate paths.
然后您可以合并或变基.有关详细信息，请参阅 Pro Git:Git 分支 - 重新定位.
You can then merge or rebase. See Pro Git: Git Branching - Rebasing for details.
合并
使用 git merge 命令:
Use the git merge command:
$ git merge origin/master
这告诉 Git 将来自 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)
新的合并提交 M 有两个父项，每个父项代表一条开发路径，导致存储在该提交中的内容.
The new merge, commit M, has two parents, each representing one path of development that led to the content stored in that commit.
请注意，M 背后的历史现在是非线性的.
Note that the history behind M is now non-linear.
重新定位
使用 git rebase 命令:
Use the git rebase command:
$ git rebase origin/master
这告诉 Git 重放提交 C(你的工作)，就像你基于提交 B 而不是 A 一样.
CVS 和 Subversion 用户在提交之前更新时，通常会根据上游工作重新调整本地更改.
Git 只是在 commit 和 rebase 步骤之间添加了明确的分离.
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' 是由 git rebase 命令创建的新提交.
它在两个方面与 C 不同:
Commit C' is a new commit created by the git rebase command.
It is different from C in two ways:
- 它有不同的历史:B 而不是 A.
- 它的内容说明了 B 和 C 的变化；它与合并示例中的 M 相同.
请注意，C' 背后的历史仍然是线性的.
我们选择(目前)在 cmake.org/cmake.git 中只允许线性历史.
这种方法保留了以前使用的基于 CVS 的工作流程，并且可以简化转换.
尝试将 C' 推送到我们的存储库中是可行的(假设您有权限并且在您变基时没有人推送).
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).
git pull 命令提供了一种从原点获取并在其上重新定位本地工作的速记方式:
The git pull command provides a shorthand way to fetch from origin and rebase local work on it:
$ git pull --rebase
这将上述 fetch 和 rebase 步骤合并为一个命令.
This combines the above fetch and rebase steps into one command.
这篇关于master 分支和 'origin/master' 有分歧，如何“undiverge"分支?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
