git commit的做法更好吗？

Question

我真的相信，在一个问题上做出一个承诺是一个很好的做法。我确信我在“最佳实践”这样的文章中的某个地方阅读过它。

因此，我的工作流程一直是以下几点：

• 对于一个新的问题，我创建git checkout -b new-issue新的本地分支。
• 将所有更改提交给它。有时这涉及提交的批次。
• 完成后，我将squash的提交和rebase它们转换为当前的专题分支。
• 如果出现问题，我可以git revert提交，找到bug，修复它，然后在专题分支中提交新补丁。我不会更改远程存储库的历史记录。今天

不过，我很惊讶地听到下面的工作流程：

• 新问题，创建新的分支。
• 承诺一切。
• 使用merge --no-ff合并问题分支与专题分支（所以我们将有“合并承诺”，我们可以revert）。
• 如果出现问题，我们可以使用git bisect来查找错误。

---

如第一的方针，我们将有一个干净的git的历史，并没有关于开发过程中使用开销分支机构的想法。

根据第二种方法，我们将有一个非常混乱的历史，有很多丑陋的，不必要的合并和提交只是一个问题。但是，我们可以使用git bisect来查找错误。 （也许这是重构更好？）

---

• 你看到这两种方法有什么利弊？

• 您使用哪种方法，为什么？

• 实际上，您是否真的使用过git bisect来查找错误？ （我没有...）

Answer 1

最后，它在很大程度上是一种个人品位的问题......只能说明我的口味（并给出一个有点理由吧）。

我倾向于保持个人承诺，即使他们只是“修复愚蠢的错别字”。任何“历史重写”都会创建前所未有的提交，因此保证永远不会被测试。此外，稍后的提交使得git bisect非常有用。最好能够将其缩小到几个变化的线条，而不是一个星期的工作，并压扁在一起。

如果开发分支弄乱了历史，我会清理它（最低限度地，回复的提交只是从未发生过，一般修复如空白或可变更新可能会早些时候应用，一些重新排序以将相关更改放在一起）。承诺仍然很小，很少被压扁。这个清理我主要是增量式的。然后，我将清理过的分支与“官方”分支合并（或重新分配）。

Answer 2

第二种方法不必进行大量丑陋和不必要的合并和提交。这是我喜欢做的事：

1. 创建一个新的话题分支
2. 刚刚合并回父分支之前做了一堆提交
3. ，清理提交：
   • 底垫到父分支的最新版本
   • 壁球错字修复承诺
   • 拆分的提交一次到单独提交
   做多件事情
   • 重新排序提交，使其更容易的评论者了解变化
   • 等
4. 合并与--no-ff到父分支的序列

上述步骤导致的历史，看起来像这样：

* 354b644 Merge branch 'topic3' 
|\ 
| * 54527e0 remove foo now that it is no longer used 
| * 1ef3dad stop linking against foo 
| * 7dfc7e5 wrap lines longer than 80 characters, no other changes 
| * b45fbcf delete end-of-line whitespace, fix indendataion 
|/ 
* db13612 Merge branch 'topic2' 
|\ 
| * 961eebf unbreak build by adding a missing semicolon 
|/ 
* a5b6b16 Merge branch 'topic1' 
|\ 
... (more history not shown) 

上述图具有的方法＃1中的所有相同的优点：

• 可以使用--first-parent参数git log得到一个简明的总结，类似于你会用的方法＃1得到什么：

  * 354b644 Merge branch 'topic3' 
  * db13612 Merge branch 'topic2' 
  * a5b6b16 Merge branch 'topic1' 
  ... (more history not shown) 
  

• ，您仍然可以轻松地检查主题中所做的更改的整体科。例如，git diff 354b644^..354b644将向您显示针对主题＃3更改的内容。

但你得到接近＃1的好处不能给你：

• 历史是多容易审查：犯下b45fbcf和7dfc7e5（用于topic3分支）引进了很多噪音，但没有实际的逻辑变化。有人试图回答这个问题，“专题＃3做了什么逻辑改变？”如果所有这些提交都被压缩为一个，可能很难挖掘噪音。
• 合并提交可以很好地标识合并分支上的一系列提交的上下文（例如，这组提交用于解决主题＃3）。
• 提交的更精细的粒度使得更容易找出为什么进行了特定的更改，这可以帮助区分意外但非常细微的意外更改。
• 如果多个人在分支机构合作，您可以看到他们是谁，每个人贡献了多少。
• 合并主题分支上的提交数量可以让您大致了解已更改了多少。
• 提交的时间范围可以提供有用的上下文。
• 您可以轻松地选择在不同分支上进行的特定更改（例如，选择修复发布分支所需的最小更改）。

我可以想到一个缺点：可能很难将软件开发工具配置为仅遵循第一条父路径并忽略所有这些中间提交。例如，there is no --first-parent argument to git bisect。另外，我对Jenkins并不熟悉，知道如何配置它以优先构建和测试所有其他提交的第一条父路径的优先顺序。