在git/GitLab中管理长寿命分支

使用

git

我有两个长期存在的分支：

master

和

develope

。特征分支取自

develope

，完成后合并回

develope

。一旦我们满意了，我们就会将内容合并到

master

  B - C        E1 - F1  H1 - I1
 /     \      /      \ /      \
A ----- D - L ------ G1 ------ J1 [develop]
            [master]

我遇到的“问题”是，

master

现在比

develope

早一步提交。因此，从

develope

的技巧中获得的下一个分支是

master

之后的提交我应该担心这个吗？

我知道这可以通过执行快进合并到

master

（因此不创建额外的合并提交）来解决，但我真的需要关心这一点吗？我问这个问题的原因是，在每一个新的

功能

->

开发

->

主功能

合并后，感觉

开发

->

与
主功能
会越来越不同

编辑：我正在使用GitLab/GitHub。合并请求/拉取请求功能需要非快进合并。
我唯一关心的是为什么
master
需要与
develope
合并。这应该是一个快速前进。这表明
master
中有一些东西不在
develope
中，比如热补丁，因此您没有在生产中的所有东西之上进行开发

你应该遇到这样的情况：

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
        [master]

master
位于D处，之前已合并了一个功能分支（B、C、D）
develop
位于J，并合并了两个功能分支。当您
git checkout master时；git merge develop
它应该是一个简单的快进到J

如果您需要合并，这意味着
master
和
develope
已经分离。这可能意味着有人热补丁了
master
，而该补丁还没有回到
develope
。例如，热补丁是E

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
         \
          L [master]

现在当您
git checkout master；git merge develop
它需要合并

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
         \                \
          L -------------- K [master]

这将继续发生

这不仅仅是一件麻烦事。这意味着
develope
永远不会真正反映合并后将在
master
中运行的代码。您在一个与生产环境稍有不同的代码库上进行开发和测试。最终，您将一个经过充分测试的
develope
合并到
master
中，生产将中断


您可能希望查看
master
中是否有任何提交，这些提交不在
develope
中，并将它们放入
master

  B - C        E1 - F1  H1 - I1
 /     \      /      \ /      \
A ----- D - L ------ G1 ------ J1 [develop]
            [master]

或者，您可以使用
-p
来保留您的特征分支，而不是将
重设为
开发到master。然后合并（即快进）

那会是这样的，从热补丁大师开始

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
         \
          L [master]

然后
git校验开发；git rebase-p主控

  B - C        E1 - F1  H1 - I1
 /     \      /      \ /      \
A ----- D - L ------ G1 ------ J1 [develop]
            [master]

现在，您可以完全测试
开发
，知道它拥有“合并”到
主控
中后将拥有的所有功能
有趣且非常有用的响应-谢谢！。当需要非快进合并时（可能是由于GitLab/GitHub管理合并请求/拉取请求的机制），您的看法是什么？如果您使用GitHub PRs进行开发->主合并，这就解释了为什么您总是落后于提交。在这种情况下，这很好，但您可能不应该作为Github PR将合并到生产中，您需要更精细的控制。上述重基策略的另一种替代方法是合并开发、删除开发、标记位置（这样您就知道这是一个版本），并创建一个新的开发主版本。感谢您的澄清。我的问题应该说明这个GitLab/Github约束。我会编辑它，并投票给你答案。@TheHowlerGit（hub | lab）对你如何使用Git没有任何限制。您可以从命令行或任何Git工具对repo执行合并或任何您喜欢的操作。是的，明白。
  B - C        E1 - F1  H1 - I1
 /     \      /      \ /      \
A ----- D - L ------ G1 ------ J1 [develop]
            [master]