git：合并经常更新的远程分支？
只是想知道合并回 master 的通常做法是什么，当 HEAD 可能自合并前的最后一次拉取以来再次更新时。为了说明这一点，在下图中，M 是预期的合并点，但由于在 M 提交并准备好推送时，主 HEAD 已更新为 A1，因此 M1 将成为新的预期合并点，换句话说，是一个新的合并点必须尝试。
master-----A----A1---...
\ \
M M1
/ /
local------B------
请注意，我不想合并 M 和 A1，因为可能会有 A2、A3，如果问题再次出现，那么对于我来说，由于额外的意外合并，它看起来太混乱了。如果 local 中的更改与 master 中的更改足够独立，有时我会在 master 之上进行 rebase，我发现这是一个更简单的解决方案。但有时我真的希望有某种方法可以“重用”我为 M、M1 所做的合并工作。
Just wondering what is the usual practice for merging back to the master, when the HEAD is likely to have been updated again since the last pull before the merge. To illustrate, in the following diagram, M is the intended merge point, but since master HEAD is updated to A1 by the time M is committed and ready to be pushed, M1 will become the new intended merge point, in other words a new merge has to be attempted.
master-----A----A1---...
\ \
M M1
/ /
local------B------
Note that I would prefer not to merge M and A1 because there might be A2, A3 down the line and if the problem recurs it just looks too messy to me with additional unintended merges. If the changes in local are sufficiently independent from those in master, sometimes I would just rebase on top of master which I find to be an easier solution. But at other times I am really hoping there is some way I can "re-use" the merging work I did for M, for M1.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
假设团队中的每个人都维护自己的存储库。团队中的一个人负责维护统称为
main存储库的内容。当团队成员工作时，他们可以从 main 拉取，但不能推送到 main。在拉取期间，如果存在合并冲突，该人将修复自己的代码。
现在，
main的所有者至少需要对每个成员存储库进行读取访问。然后，main的所有者依次从每个存储库中提取内容。如果没有合并冲突，就没有问题。如果存在冲突，则main的所有者将中止提交，并让拥有代码的人修复冲突。让我们详细回顾一下这部分main从bob中提取 - 好的；合并完成并发布main从tom拉取 - 冲突；合并被中止main的所有者告诉tom提取最新更改并修复冲突tom可以自己修复冲突，然后告诉 < code>main 再次尝试main从tom中提取 - 好的这个过程每天都会重复，或者无论您的集成周期有多频繁。
虽然这肯定会给一个人带来负担，但该人不必解决任何冲突，只要有正确的动机，这项工作就可以自动化。这就是 Linus 管理内核的方式。
Let's say each person on the team maintains their own repository. A single person on the team maintains what is collectively known as the
mainrepository.As team members work, they can pull from main but they do not push to main. During a pull, if there is a merge conflict that person will fix their own code.
Now the owner of
mainneeds at the very least read access to each members repository. The owner ofmainthen pulls from each repository in turn. If there are no merge conflicts, no problem. If there is a conflict then the owner ofmainaborts the commit, and let's the person who owns the code fix the conflict. Let's go over this part in detailmainpulls frombob- ok; the merge is completed and publishedmainpulls fromtom- conflict; the merge is abortedmaintellstomto pull the latest changes and fix the conflicttomcan fix the conflict himself, then tellmainto try againmainpulls fromtom- okThis process is just repeated each day, or however often your integration cycle is.
While it definitely puts the burden onto a single person, that person does not have to fix any of the conflicts, it's a job that could be automated given the right motivation. This is how Linus does it for managing the kernel.
我们使用签入令牌来协调此类问题。无论谁拥有它，都可以放心，在它被释放之前，没有其他人可以检查 master 。
如果您与其他开发人员一起检查头部，则使用物理令牌（大象/猴子/鸡 - 任何东西，越可爱越好）。
当我们进行分布式开发时，我们使用了一个带有表格的 wiki 页面，其中顶部是拥有“令牌”的人。
We use a check-in token to co-ordinate this kind of issue. Whoever has it, is assured that no-one else is checking into master until it is released.
If you're co-located with the other devs checking into head, then use a physical token (an elephant/monkey/chicken - anything really, the cuter the better).
When we've had distributed development, we've used a wiki page with a table where the top is the person with the "token".
它看起来像是 git rebase 的工作。
工作流程
您正在一个单独的分支（我们称之为
本地）上工作，并且进行了一些提交。当您准备好推送更改时，请签出
master分支并执行git pull。检查您的本地分支并执行git rebase master。此命令将：master和local发生分歧，因此搁置您的更改/提交（在local上），进行快进合并code>master分支，git rebase的含义由于提交哈希发生了变化，您只需要在本地分支上进行变基（即不推送到远程分支） ）。
It looks like a job for
git rebase.Workflow
You are working on a separate branch (let's call it
local) and you do a few commits.When you are ready to push your changes, checkout the
masterbranch and do agit pull. Checkout yourlocalbranch and do agit rebase master. This command will:local) sincemasterandlocalhave diverged,masterbranch,Implications of
git rebaseSince the commit hash changes, you need to do the rebase only on LOCAL branches (ie. that are NOT pushed to remote).
我终于准确地弄清楚了我的想法，解决方案就是简单地重新调整合并提交，如下所述： 重新确定 Git 合并提交的基础
I finally figured out what I had in mind exactly, and the solution is simply to rebase the merge commit as described here: Rebasing a Git merge commit