一些背景知识:
目前,我的服务器上有一个中央裸存储库。每台计算机都会克隆并将更改推送到此存储库。我目前有分公司和分公司开发。所有工作都在dev分支中完成。 Master始终是当前稳定的生产代码。可以随时将更改应用于Master以及dev中正在进行的更改。
我的日常工作流程包括:
git checkout dev
//pull in changes from remote
git pull
//make and commit changes as need throughout the day
git add -u
git commit
//these steps only happens when I know master has changed
git checkout master
git pull
git checkout dev
git rebase master //to get changes to master into dev branch
//push changes to central remote at end of day
git push
我认为这对于单个开发人员来说应该是一个相当标准的工作流程。
现在把所有这些都放在一边,达到我的问题的目的。我最近遇到的情况是,我不确定如何正确处理以及如何在将来预防它。目前,我的dev分支是一个长期运行的dev分支,它是对网站的一部分进行重大改写。因此,它已经开发了几个月。虽然我一直在做这项工作,但我也一直在对Master进行小修改/错误修复。当我完成对Master的一个更改时,我将dev重新设置为Master来获取更改,然后将它们推送到中央仓库。这一直很好。
然而,几天前我改变了大师 - 大约一个月内第一次这样的改变。当我去修炼时,所有地狱似乎都松了一口气。我在Master中没有存在的文件上遇到合并冲突,我在同一个文件中反复出现相同的冲突。在花了一天的大部分时间试图解决所有冲突之后,我终于放弃了。
今天早上,我再次尝试,但在开始之前,我检查了项目提交历史,发现了一些奇怪的东西。我发现大约有15个提交被重复了。它显示了从2012年12月7日至2012年8月24日的所有提交。然后,我再次列出了相同的提交,所有提交都使用不同的SHA哈希。直到我看到提交的日期按时间顺序按照您的预期排列时,我才注意到它,但之后又突然又重新回到了过去。
要解决我做了另一个rebase,但跳过了重复的提交。当我这样做时,一切都按照我的预期完成,没有任何冲突。
所以,我向你们提出的问题是,这些承诺是如何完成两次的,我怎样才能防止这场噩梦再次发生呢?正如问题的标题所示,我认为问题与我使用rebaseing和推动重新分支有关。但我真的只是猜测那里。我只是需要一些帮助来弄清楚我做错了什么。
答案 0 :(得分:1)
我认为您的模型基本上与拥有三个开发人员相同,因为您有三台开发机器。所以,你的dev分支在这个意义上是共享的。我也读过SO,作为共享分支的重新定位导致问题,并且合并比rebase共享分支更好。在阅读之后,我开始只为私人分支使用rebase,效果很好。我建议创建一个测试存储库并尝试这两种方法来查看它们的比较方式。
如果我能找到其他问题,我会在这里添加一个链接。
编辑:
这是Rebasing remote branches in Git
当然,对此有很多不同的看法。 :)