时间戳

首页 > 解决方案 > 如何实现简化的合并提交

git - 如何实现简化的合并提交

问题描述

理由：外部环境审查发生在此处表示为的分支上master>。我想将（更好：组合）提交压缩在一起，以便对某个开发步骤进行所有更改。因此：

我如何从左到右？

                                                   master> * C <feature  
                                                           |\
            * H <feature   - just local                    | * H     (merged)
            |                                              | |
            * G     - pushed to remote          =??=>      | * G     (merged)
master> B * |       - pushed to remote                   B * |
          | * F     - pushed to remote                     | * F     (merged)
          |/                                               |/
          *                                              A *

实际上，功能路径上的提交数量很大（10+），我想将它们全部压缩。其中一部分已发布到远程存储库（不应更改或更改）。但是我只想在主分支上创建一个提交。

git merge --squash显然执行此操作，但它不会将提交标记为合并。因此，如果我继续在<feature-Branch 上工作，下一次调用git merge将导致很多冲突。我在 stackoverflow 上找到了一个解释：git merge --squash导致一个与源提交无关的补丁。

所以，我想要实现的是从右到左的情况，并且 featurebranch ( 和 ) 上的所有提交都F将G被H标记为合并*) - 如果我继续在 Featurebranch 上工作，下一次合并不会导致与我的冲突自己的变化。如果 Featurebranch 上的所有更改都未发布到远程存储库，则此问题已解决（请参阅git merge --squash-Question）。

PS：当然，将提交单独标记为已合并就足够了，但我既不知道该怎么做，也不知道 git 如何管理它的合并信息。

PSS：正常合并可以，但如果 master 上没有提交，它会失败。

*)：“标记为合并”的意思是，在 gitk - 如果您选择提交，分支列表包括功能、遥控器/原点/功能、主控、遥控器/原点/主控。结果，这些提交将不会在随后的调用中被考虑git merge。

标签： gitmergegit-merge

解决方案

没有办法做你想做的事。

当 Git 进行合并时，它会计算合并基数，这大致是两个分支的共同祖先提交。在典型合并中考虑的三个（也是唯一的）三个点是合并基础和两个头部。如果您进行正常的合并，那么您将在主分支上产生一个新的提交，并且该提交或其后代之一通常将在未来用作合并基础，这意味着 Git 不会将您的更改视为第二次。

如果您进行 squash 合并，则合并基础是原始分叉点，因此后续合并会将您视为进行了具有相同更改的多次提交，从而导致您所看到的冲突。

除非您使用自定义合并驱动程序，否则您无法自定义合并基础检测，因此您需要采用另一种解决方案或学习处理冲突。

您可以做的是删除现有分支并在分支上重新创建它master（或将其重置为最新的提交 on master），这意味着未来的工作基于包含所有先前工作的提交。这将避免你的冲突。

您还可以使用标准合并而不是壁球合并，这将使合并基础检测做正确的事情。

最后，您可以编写一个自定义合并驱动程序，以某种方式直观地了解有关您的分支的信息。我不推荐这种方法，因为它涉及大量工作，而且很容易出错并弄乱所有数据。

但最终，鉴于您的工作流程限制，您可用的选项并不多。我个人建议采用一种不同的、更标准的、约束更少的工作流程；逻辑的、独立的提交；和标准的合并政策。

推荐阅读