2

有一段时间，我以这种不同寻常的方式使用 Git：

  1. git checkout -b feature123
  2. 微小的编辑、提交、重复
  3. git checkout master
  4. git merge --squash feature123
  5. 使用输出git log --oneline来填充提交消息，如下所示：
实现功能 123，对 brob 进行处理

长而详细的描述在这里。
    
         f5d1b77 重构：提取方法
         1c1346e 重构：将“A”重命名为“B”
         63457de等
         884fga1 浮球

我特别喜欢重构的工作模式，直到我想要创建的行为改变微不足道。在任何时候，如果我卡住了，我可以回滚到我最后一次好的提交。阅读我的提交历史很容易，因为行为更改和重构是分开的，并且行为更改简单明了。

我在微软的 Source Depot 工作时养成了这个习惯。我可以对一个分支进行一系列微小的提交，并将上游的分支合并为一个提交。我们有一个 gui 工具（类似于 gitk），它可以显示合并提交及其+旁边的 a。如果需要，我可以扩展并查看详细信息。非常好。我试图在 Git 中复制它。

如果我想深入了解细节，GitHub 会将这些提交 SHA 放入到各个提交的链接中。但是，它只对一些提交执行此操作，其余的不会成为链接。

在此处输入图像描述

这显然是在 Git 中一种不同寻常的工作方式。这些工具不太可能围绕它进行改进，其他程序员看到它时可能会感到困惑。

通常，在合并 Git 功能分支后，您可以将其删除 - 没有太多理由保留它。但是在这种情况下，如果我删除分支，单个提交将消失，并且您无法在 GitHub 中单击它们。所以那些旧的分支把东西弄得乱七八糟，即使它们没有用。我怎样才能摆脱它们？

也许一些变基的魔法咒语？

4

1 回答 1

4

据我了解你的意图，你的意思是有一个简单的历史和需要的细节。

如果您进行压缩合并，则（除非您添加一些明确的参考）没有直接的方式来访问原始提交，并且 git 将（最终）清理所有那些无法访问的提交。

因此，您需要一种方法来存储原始分支的 ref。最自然的地方就是合并提交本身，这会导致未取消的合并。

因此，我的建议是在显示您的历史记录时进行定期合并并过滤重要的提交，例如在gitk --first-parent. 这只会向您显示主分支上的提交，而忽略任何侧分支。（即在第一种方法中取消合并时您将摆脱的那个。）

于 2013-03-15T06:14:47.837 回答