2

假设我正在开发一个重要的功能分支，该分支遵循一个具有相当多活动的项目的“主”分支。这通常使我处于一种情况，为了保持理智，我必须稍微落后于“头脑”，以便弄清楚如何使某些事情发挥作用。

这通常会导致我的分支在 master 分支后面有几千次提交 - 伴随着所有有趣的事情，例如相关模块被重构或类似。一旦我决定开始“追赶”，这给我留下了一个棘手的任务：单片合并是不可能的，因为：

  1. 几乎不可能同时考虑所有“我的”更改乘以所有“主”更改。我尝试了几次，我犯了很多错误，最终不得不退出。

  2. 由此产生的合并将是如此巨大，以至于隐藏在其中的所有魔法都将是一场文档噩梦。

因此，我最终采用的方法是进行“分阶段”合并：不是直接与 master 合并，而是选择性地与 master 历史中的“有趣”点合并。这通常是关于可能有“棘手”冲突的模块的提交。这样做的最大好处是我有实际可构建的中间点，我可以推理和测试，因此使整个过程更易于管理。

然而，这种方法似乎有缺点......也就是说，如果合并中出现错误，我稍后才会注意到。我尝试使用git rebase -i -p以将修复压缩到历史中，但发现这似乎不是人们所设想的那种用法。再具体一点

  • 在合并之间插入更改似乎会导致变基过程因或多或少复杂的冲突而摆脱困境，并且

  • 将常规提交压缩为合并提交似乎会使新提交成为非合并，失去对合并提交的引用

现在我正在使用一些或多或少花哨的 shell 脚本来解决所有这些问题，但我很想知道我是否错过了一些可以帮助我处理这种情况的 Git 功能。到目前为止，我能想到的最好的想法是使用 rerere 手动重做所有合并。

4

3 回答 3

1

以更简单的方式，您不会git merge（或git cherry-pick）从 master 到您的功能分支进行任何更改。你总是git rebase在你的特性分支之后移动你的更改。

如果你经常保持 git rebase 并保持 git rebase 小，生活会更容易。

于 2013-08-23T02:31:38.833 回答
1

我发现将主题分支重新定位到 master 被证明是一个更容易/更易于管理的过程。

所以代替这个

A--B--C--D--E--F--M
       \         /
        X--Y--Z-

做这个

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

参考

于 2013-01-18T19:06:26.957 回答
0

git rebase如果操作得当，这是一个很棒的功能。

我不确定您是否尝试过您的情况，但我会做以下事情。

结帐主分支确保其与原点保持同步。签出您的功能分支 git rebase master

如果有任何冲突允许您随时解决冲突，并且如果您遇到任何奇怪的事情，您总是可以做，它几乎会指导您git rebase --abort

假设你确实遇到了问题，你修复了文件然后做git add <some file>，git rebase --continuerebase 将继续做它的工作。

请确保如果您的功能分支已被推送到远程并由其他人处理，则不要使用 rebase。

于 2013-01-18T19:18:33.213 回答