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

问题描述

这似乎应该是一个很容易找到答案的问题，但是我整个上午都在寻找并拉扯我的头发，但找不到让我满意的答案。我能找到的最接近的是这个问题，Git merge squash repeatedly，但这个问题是 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 桌面应用程序和 Github 网站；我一直在努力避免将控制台命令放入我的工作流程中。

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

解决方法

此问题已在 Git FAQ 中回答，您遇到的问题很常见：​​

一般情况下，使用squash merges多次合并两个分支时可能会出现各种问题。这些可能包括在 git 日志输出中、使用 GUI 或使用 ... 表示法表示范围时查看额外提交，以及需要一次又一次重新解决冲突的可能性。

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

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

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

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

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