1

我不喜欢 Git 的一件事是提交的数量。不要误会我的意思，这是一种非常方便的（安全地）存储您的工作的方法，但从长远来看，搜索的粒度太大。

让我在使用从develop分支的功能分支进行开发时描述以下场景。

  • Feature1是从开发分支出来的，有 5 个提交
  • Feature2是从开发分支出来的，有 3 个提交
  • Feature3是从Feature1分支出来的，有 5+2 次提交。

之所以有三个分支，是因为有一个团队在处理存储库。Feature3假设Feature1已经完成，等待合并到开发中。还有其他用例，但这是最简单的示例。

我的目标是在所有功能完成后对开发进行三个提交。

使用 git 合并/拉取

上述场景运行良好。因为本质上这两个命令都将提交移到了开发分支中。当Feature1被合并时，开发引用它是五个提交。当Feature3将被合并时，只有最后两个提交将被合并到develop中。

唯一不利的方面是开发获得了太多的提交。这意味着当合并到master时，所有“噪音”都会移动。因此我的目标没有实现。

使用 git merge 和 squash

当Feature1被合并时，develop得到一个新的提交，它是所有Feature1的聚合。这非常好，因为现在只需一次提交即可跟踪该功能。删除Feature1后，所有中间提交都不再可见，从而使跟踪更容易。这也与一个拉取请求和一个 github 问题等概念相匹配。

当Feature3将被合并时，会出现冲突，问题就开始了。要解决这个问题，您需要将develop合并回feature3。与冲突。这会导致一个新的提交，其中更改了零个文件。现在我们合并壁球Feature3来开发.

我的目标实现了，但牺牲了很多微观管理。

问题/备注

据我了解，这是 git 的现实。我读过的一个建议是创建一个兄弟功能分支来保存压缩的合并提交。将同级分支用于拉取请求，因此强制每个功能使用一个提交。这并不能解决在尝试合并其他分支时产生的冲突，尤其是从其他特性分支继承的那些。

  • 可以在同一个分支内做内部壁球吗？我不这么认为，但问也无妨。
  • 我错过了什么？
  • 这是壁球合并的权衡吗？解决可能零代码更改的冲突？
  • 是否值得追求“每个功能一次提交”的概念？
    • 如果不是，那么壁球的目的是什么？谁在使用这个？

我已经阅读了 rebase 的替代方案，并在合并后使用 reset 模拟了壁球，但据我所知，没有一个解决提到的合并feature3的开销。

4

2 回答 2

1

我真的认为变基是您的解决方案。

如果我理解，以下是您的 git 结构：

develop \ A - B - C [feature1] \ D - E [feature3]

您的问题是，一旦您将feature1压缩并合并到develop中，最初的三个提交feature3引用就不再存在了。除了feature1并不真正存在之外，您本质上如下所示。

develop — feature1Merge \ A - B - C [feature1] \ D - E [feature3]

因此，develop 中的feature1Merge提交与feature3历史中的提交不同。

在这种情况下，如果您尝试将rebase feature3重新设置为 development ，则提交并继续使用它，理论上这不会导致任何问题，因为更改已经在develop中，因此 git 应该快进这些提交。显然，这似乎并没有发生。A BC

我建议在这种情况下做的是rebase onto.

重新定位到

该--onto选项允许您重新设置特定提交，而不是整个分支。

因此，为了阻止 git 尝试使用提交A B，并且C在变基时，我们使用--onto，它需要 3 个参数：

  • 分公司的新基地

  • 分公司目前的基地

  • 要变基的分支的名称

在您的情况下，这将是：

git rebase --onto develop C feature3

这将检查开发，然后在feature3上应用所有提交，因为C：

develop — feature1Merge \ D - E [feature3]

希望这一切都有意义，并以尽可能少的麻烦实现您想要的！

于 2017-02-06T10:13:23.473 回答
0

是的，具有如此多提交的 git 的目的是使每个更改都可跟踪。如果某些提交不重要，或者可以在一个提交中记录所有更改以供您查看历史记录，那么您可以压缩这些提交。

对于您的问题：

1.是的，你可以做一个内部壁球。假设您的 git 提交历史如下图所示：

                K---L---M        Feature2
              /
A---B---…---C---…                develop
     \         
      D---E---F---G---H          Feature1
                        \
                          I---J  Feature3

您可以使用以下步骤来压缩每个分支：

git checkout Feature1
git rebase -i HEAD~5

输入i

pick D
squash E
squash F
squash G
squash H

按 Esc 键，然后输入:wq

git checkout Feature3
git rebase -i HEAD~7

pick D
squash E
squash F
squash G
squash H
squash I
squash J

git rebase Feature1
git checkout Feature2
git rebase -i HEAD~3

pick K
squash L
squash M
  1. 你的过程没问题。
  2. 要压缩提交，第一个（最旧的）应该使用 pick，其他人可以使用 squash，这样它就会显示只有一个提交的分支。如果有冲突，可以修改并保存冲突文件，然后使用git add .and git rebase --continue。
  3. 这不是必需的，这取决于您的喜好。壁球的主要目的是使历史看起来更加整洁和清晰。
于 2017-02-06T14:01:05.787 回答