GIT：我可以在合并到 master 的同时维护一个正在进行的开发分支吗？

Question

这看起来应该是一个简单的问题，但我整个早上都在寻找答案，但我就是找不到令我满意的答案。我能找到的最接近的东西是这个问题，Git merge squashrepeated，但这个问题是 11 年前的问题，所以希望“除非你创建临时分支，否则你根本无法做到这一点”的共识已经改变。

我正在从事一个长期项目，我基本上是唯一的贡献者。理想情况下，我希望有一个长期持续的development分支，我可以继续一点一点地修补和工作，并master在我达到稳定的可发布状态时定期对分支进行压缩合并。我不想让完整的提交历史记录可用/可见master，因为我希望能够轻松地向后浏览稳定的官方版本的历史记录。但是，我确实希望完整的提交历史记录可以在某个地方可用，以便它变得相关。

问题是，如果我尝试以直觉上认为应该有效的方式做到这一点，那就行不通。南瓜合并提交创建了一个与master中的任何内容都不匹配的提交development，因此下次我尝试执行南瓜合并时，它会说存在冲突，我需要从合并master到development...并且当我越来越多地重复这个过程，这个问题不断增长，我有六个提交在两个分支之间来回跳动，这些提交实际上并没有更改任何文件，但我似乎无法摆脱。

我想要制作的图形看起来像这样，如果这有意义的话：

      B-------------------G-----------J master
     /                   /           /
a---b---c---d---e---f---g---h---i---j development

到目前为止我一直在使用的解决方案非常丑陋：我使用版本号创建一个新分支，例如development_601，然后当我再次稳定时，我从该分支向 master 发出拉取请求，并压缩合并提交，然后我在挤压合并后创建另一个新development_602分支master。development_601被封存。这看起来很混乱、烦人，而且是错误的，特别是因为 Git 似乎暗示我应该在合并拉取请求后删除我的分支，但就像我说的，我想在某个地方记录我完整的混乱历史，我只是不这样做不希望它（轻易）从外部可见。

我一直在使用 Github Desktop 应用程序和 Github 网站；我一直试图避免将控制台命令放入我的工作流程中。

这是一种奇怪的行为吗？development我觉得“拥有一个带有master/分支的长期release分支，定期但不完全地反映它”是一种非常常见的系统，但不知何故，我找不到任何地方可以解释如何实现它。

Answer 1

这个问题在Git FAQ中得到了解答，您遇到的问题是一个常见问题：

\n

\n

一般来说，使用挤压合并多次合并两个分支时可能会出现各种问题。这些可能包括使用 GUI 在 git log 输出中看到额外的提交，或者使用...符号来表达范围时，以及需要一次又一次重新解决冲突的可能性。

\n

当 Git 在两个分支之间进行正常合并时，它会考虑三点：两个分支和第三个提交，称为合并基础，它通常是提交的共同祖先。合并的结果是合并基和每个头之间的变化之和。当您使用常规合并提交合并两个分支时，这会产生一个新的提交，当它们再次合并时，它将最终作为合并基础，因为现在有一个新的共同祖先。Git 不必考虑合并基础之前发生的更改，因此您不必重新解决之前解决的任何冲突。

\n

当您执行挤压合并时，会创建一个合并提交\xe2\x80\x99t；相反，一侧的更改将作为常规提交应用到另一侧。这意味着这些分支的合并基础不会改变，因此当 Git 执行下一次合并时，它会考虑上次考虑的所有更改以及新的更改。这意味着任何冲突都可能需要重新解决。同样，...在 git diff、git log 或 GUI 中使用符号的任何内容都将导致显示自原始合并基础以来的所有更改。

\n

\n

这种方法总是会导致问题。如果您有两个长时间运行的分支，则需要使用常规合并提交。否则，您可以创建短期分支，并将其分别合并到每个长期运行的分支中，或者使用变基策略。如果您像 Git 鼓励您那样花时间创建具有良好提交消息的独立、逻辑提交，那么所有这些方法都会更有吸引力。

\n

作为 Git 开发人员，我个人的建议是编写合理的提交，然后使用常规的合并提交。如果你的历史很好，那么就没有理由隐藏它。

\n

然而，Git 和合并工作的基本原理并没有随着时间的推移而改变，因此对于长期运行的分支和压缩合并的答案“不要这样做”也没有改变。

\n