使 Git 功能分支保持最新的策略答案

【问题标题】：Strategy For Keeping Git Feature Branches Up to Date使 Git 功能分支保持最新的策略
【发布时间】：2012-01-15 04:18:49
【问题描述】：

我喜欢让我的功能分支与开发保持同步。经常做“git merge --no-ff develop”有什么问题吗？最后，运行“git flow feature finish feature1”。这些功能分支是共享的（这意味着其他人可能正在处理它，或者我正在家里的计算机上开发它），主要是因为我喜欢知道它们在其他地方备份。如果它们不被共享，是否会优先选择持续变基？

或者最好不要让你的功能分支保持最新，最后只合并所有内容？

【问题讨论】：

标签： git merge git-flow fast-forward

【解决方案1】：

是的，我认为持续变基将是首选方法。并且 git-flow 目前有一个用于此目的的命令（不确定在提出问题时是否存在此命令）：git flow feature rebase <featurename>。

【讨论】：

这并没有提供问题的答案。要批评或要求作者澄清，请在其帖子下方发表评论。
我不明白这不是问题的答案，只是因为它又短又甜。作者问：“如果它们不被共享，是否会首选持续变基？”我认为通过发布 git-flow 的专用命令，很明显我在说“是的，特别是这个命令”。但是好的，我会更新它以更明确。

【解决方案2】：

这就是我将 git-flow 改编为更强大版本的方式：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

ymmv 取决于您的工作的精细程度。

【讨论】：

谢谢。不过，我真的不明白这一点：“它们应该被集成到一个集成分支中，几乎就像你提交给它们的频率一样。”如果管理层决定取消您已经开发了一周的功能怎么办？集成分支会发生什么？还是集成分支与“Git Flow 一个成功的分支策略”中描述的“开发”分支完全分开？
集成和 qa “分支”是可以丢弃的。您将它们用于某个目的，而不是在那里跟踪历史。功能分支可以与您不希望排除的分支重新合并。这就是我写的重点。有人在 cmets 中询问过类似的事情。

【解决方案3】：

如果您的分支不是公开的，通过 rebase 更新是最好的方法。如果它们是公开的，最好只在最后合并它们（而不是始终将更改合并到它们中）。这两种策略都保持简单、干净的提交和合并历史记录。

【讨论】：

这样我就不会丢失别人所说的，关于频繁合并和脏合并历史，“如果你愿意，在你完成特性分支之前，你可以重新定位到开发人员。这将删除所有合并提交“。这会解决保持干净的提交和合并历史吗？
@RonGarrity：是的，你也可以这样做。
如果您有长期运行的分支，而没有使它们保持最新状态，则意味着灾难。话虽这么说，我没有更好的贡献......只要你发布你的工作，你就不能（不应该）重新设置它，然后丑陋的合并提交是唯一的方法。