只是想知道合并回主人的惯常做法是什么,当HEAD很可能在合并之前的最后一次拉动后再次更新。为了说明,在下图中,M是预期的合并点,但由于主HEAD在提交M并且准备推送时更新为A1,因此M1将成为新的预期合并点,换句话说是新的合并必须尝试。
master-----A----A1---...
\ \
M M1
/ /
local------B------
请注意,我宁愿不合并M和A1,因为可能有A2,A3线,如果问题再次发生,它对我来说看起来太乱了,还有其他非预期的合并。如果local中的更改与master中的更改完全独立,有时我会在master之上重新定义,我发现这是一个更容易的解决方案。但在其他时候我真的希望有一些方法可以“重复使用”我为M做的合并工作,对于M1。
答案 0 :(得分:2)
假设团队中的每个人都拥有自己的存储库。团队中的一个人维护着统称为main
存储库的内容。
随着团队成员的工作,他们可以从主要部门撤离,但他们不会推向主要部门。在拉动期间,如果存在合并冲突 人将修复自己的代码。
现在main
的所有者至少需要对每个成员存储库的读访问权限。然后main
的所有者依次从每个存储库中提取。如果没有合并冲突,没问题。如果 发生冲突,那么main
的所有者将中止提交,让拥有该代码的人解决冲突。让我们详细讨论这部分
main
来自bob
- 确定;合并完成并发布main
来自tom
- 冲突;合并中止main
的所有者告诉tom
提取最新更改并解决冲突tom
可以自行解决冲突,然后告诉main
再试一次main
来自tom
- 确定此过程每天重复一次,或者通常是您的整合周期。
虽然它肯定会给单个人带来负担,但是那个人不必须解决任何冲突,这是一项可以在给定正确动机的情况下自动完成的工作。这就是Linus管理内核的方式。
答案 1 :(得分:1)
它似乎是git rebase
的工作。
您正在处理一个单独的分支(让我们称之为local
)并且您做了一些提交。
当您准备推送更改时,请检查master
分支并执行git pull
。检查您的local
分支并执行git rebase master
。该命令将:
local
)放在一边,因为master
和local
已分歧,master
分支进行快进合并,git rebase
由于提交哈希更改,您只需要在 LOCAL分支(即 NOT 推送到远程)上进行rebase。
答案 2 :(得分:1)
我们使用登记令牌来协调这类问题。无论谁拥有它,都可以确保在发布之前没有其他人正在检查主人。
如果你与其他开发人员共同检查头部,那么使用一个物理标记(大象/猴子/鸡肉 - 任何真的,更可爱的)。
当我们进行分布式开发时,我们使用了一个带有表的wiki页面,其中top是具有“token”的人。
答案 3 :(得分:0)
我终于弄明白了我的想法,解决方案就是按照此处的描述重新定义合并提交:Rebasing a Git merge commit