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

Question

我有以下git工作流程:

1. 创建新功能分支
2. 在功能分支上工作
3. 经常提交
4. 功能完成后,合并到master分支
5. 冲洗并重复

但是,有时候,我需要从master中恢复整个功能.这可能涉及很多revert.(需要恢复功能的原因是我有一个网站可以使用一个仓库.从那里,我们使用一个脚本将网站部署到我们的生产站点或临时站点.两者都是从我们的主分支完成的.Don不要问,这就是我给予的工作.有时候,我正在研究我上演的东西,但是需要立即做出改变,所以我需要一些方法来拉动我的变化以便清理回购.)

我认为最简单的方法是每个功能分支只有一个提交.然后我可以revert提交.很自然地,我想在将一个功能分支的所有提交压缩成一个之前将其压缩为一个master.

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

1. 创建新功能分支
2. 在功能分支上工作
3. 经常提交
4. 一旦功能完成git rebase -i HEAD~number_of_commits(或者如果远程分支可用,origin/feature_branch)

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

谢谢!

Answer 1

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

无论git merge --squash和git rebase --interactive可用于生产具有相同的最终工作树压扁的承诺,但他们的用意是2个完全不同的目的.在这两种情况下,你的树最终会看起来不同.

初始树:

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例子.