压缩提交到一个最佳实践（针对此特定工作流程）？

Question

我有以下git工作流程：

1. 创建新功能分支
2. 处理功能分支
3. 经常提交
4. 功能完成后，合并到master分支
5. 冲洗并重复

但是，有时候，我需要从master恢复整个功能。这可能涉及大量的revert。 （需要恢复功能的原因是我有一个网站可以使用一个仓库。从那里，我们使用一个脚本将网站部署到我们的生产站点或临时站点。两者都是从我们的主站完成的不要问，这就是我给予的工作。有时候，我正在研究我上演的东西，但是需要立即做出改变，所以我需要一些方法来改变为了清理回购。）

我认为最简单的方法是每个功能分支只有一个提交。然后我可以revert提交。很自然地，我想把一个功能分支的所有提交压缩成一个，然后再合并到master。

所以现在我的工作流程看起来像：

1. 创建新功能分支
2. 处理功能分支
3. 经常提交
4. 功能完成后 git rebase -i HEAD~number_of_commits （或者如果远程分支可用， origin / feature_branch ）

这个逻辑有什么问题吗？它违背了任何最佳做法吗？我自己做了一些测试，整个工作流程似乎顺利运行并解决了我的问题，但我想让其他（更聪明的）Git-ers运行这个想法，看看它是否有任何问题。

谢谢！

Answer 1

你应该考虑利用git的壁球合并功能，即git merge --squash，这样你就不会不必要地重写历史。

git merge --squash和git rebase --interactive都可用于生成具有相同结果工作树的压缩提交，但它们旨在用于两个完全不同的目的。在这两种情况下，你的树最终看起来都不同了。

初始树：

a -- b -- c -- d    master
      \
       \-- e -- f   feature1

git checkout master; git merge --squash feature1; git commit之后：

a -- b -- c -- d -- F    master
      \
       \-- e -- f   feature1

git checkout master; git rebase -i feature1后选择pick c和squash d：

a -- b            /-- F  master
      \          /
       \-- e -- f   feature1

从差异中可以看出，在使用git merge --squash时，您不会重写任何分支的历史记录，但在使用master时，您最终会重写git rebase -i的历史记录。

另请注意，实际提交（对于被压扁的提交）将在两种情况下都存在于您的git历史记录中，只要您有一些分支或标记引用，通过这些引用可以访问这些提交。

换句话说，在上面的示例中，如果您在执行feature1后删除merge --squash，则无法实际查看提交e或f未来（特别是在90天的reflog期间）。这同样适用于c示例中的提交d和rebase。

Answer 2

您的方法的一个具体缺点是，它严重降低了git bisect在跟踪代码中的错误方面的效用。

也就是说，如果您发现自己经常将整个功能恢复到正在寻找优化该流程的方法，那么您可能想问问自己是否正在合并{{ 1}}太快了。您可能需要考虑使用多个长期运行的分支来设置更适合您项目的工作流程。