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

Question

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

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

问题是，如果我尝试按照直觉上认为应该有效的方式执行此操作，但事实并非如此。 squash-merge-commit 在 master 上创建了一个与 development 中的任何内容都不匹配的提交，因此下次我尝试执行 squash-merge 时，它​​会说是一个冲突，我需要从 master merge 到 development...并且随着我越来越多地重复这个过程，这个问题不断增长，我已经有一半了十几个提交在两个分支之间来回跳动，实际上并没有更改任何文件，但我似乎无法摆脱。

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

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

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

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

这是一种奇怪的行为吗？我觉得“拥有一个长期的开发分支和一个定期但不完全镜像它的主分支/发布分支​​”是一种非常常见的系统，但不知怎的，我就是找不到任何地方解释如何实现它。

Answer 1

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

In general, there are a variety of problems that can occur when using squash merges to merge two branches multiple times. These can include seeing extra commits in git log output, with a GUI, or when using the ... notation to express a range, as well as the possibility of needing to re-resolve conflicts again and again.

When Git does a normal merge between two branches, it considers exactly three points: the two branches and a third commit, called the merge base, which is usually the common ancestor of the commits. The result of the merge is the sum of the changes between the merge base and each head. When you merge two branches with a regular merge commit, this results in a new commit which will end up as a merge base when they’re merged again, because there is now a new common ancestor. Git doesn’t have to consider changes that occurred before the merge base, so you don’t have to re-resolve any conflicts you resolved before.

When you perform a squash merge, a merge commit isn’t created; instead, the changes from one side are applied as a regular commit to the other side. This means that the merge base for these branches won’t have changed, and so when Git goes to perform its next merge, it considers all of the changes that it considered the last time plus the new changes. That means any conflicts may need to be re-resolved. Similarly, anything using the ... notation in git diff, git log, or a GUI will result in showing all of the changes since the original merge base.

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

作为 Git 开发人员，我个人的建议是编写合理的提交，然后使用常规的 merge 提交。如果您的历史记录不错，那么就没有理由 stash 它。

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