git - 将一系列小提交重新定义为逻辑单元提交

Question

在某些设置中，我习惯于在本地使用git，然后导出一个diff，然后提交并附上详细的描述。因此，当我在本地开发时，我会不断地提交，并且在提交之前不会为有意义的提交消息或完美的测试而烦恼。

但是，当使用 git 在 github 上发布代码时，我更愿意删除那些小提交的历史记录，只创建一个代表逻辑上经过良好测试的更改的提交。

实现这一目标的最佳方法是什么，而不改变我在探索了一条小路(但未经证实)时提交的本地工作流程？

Answer 1

如果您查看“Trimming GIT Checkins/Squashing GIT History”，您可以:

• git rebase --interactive --fixup 用于压缩您在 rebase --interactive 的提交编辑列表中手动重新排序的提交，而忽略第二个提交消息，这将使消息编辑步骤更快(您可以保存它:压缩的提交将只有第一个提交消息)
• git rebase --interactive --autosquash 用于为您自动进行提交重新排序过程。

这就是为什么我喜欢为每个事件所做的所有微提交选择一个标准评论。
第一个微提交将包含“我的事件”。
所有其他将包含“squash!我的事件”

几个事件(一组微提交)可以在此过程中交织在一起。

剩下的就是一个 git rebase --interactive --autosquash 用于重新排序然后压缩所有这些微提交。

---

OP namin提到博文Our Git Workflow: Private Development, Public Releases作为一个很好的例子，基于 git merge --squash:

(另见:

• In git, what is the difference between merge --squash and rebase?
• Git: after preparing a real merge commit, how to create a simple commit?

)

We maintain 3 branches for each of our client libraries:

• master — Active development occurs on this branch.
• release — Development for bug fixes happens here. We also bump versions and update the changelog on this branch.
• github_master — We squash commits from the release branch into single “release” commits on this branch as well as tagging releases. This branch tracks github/master.

We’re now ready to move to the github_master branch.

git checkout github_master

We want to merge the changes from release into the github_master branch but we don’t want to see each individual commit.
Git helps us out here with the git merge --squash command. This will merge all the changes from a specific ref, squash them into a single set of changes and leave the changes staged. We commit the staged changes with the message “1.0.0” and tag the commit.

git merge --squash release
git commit -m "1.0.0"
git tag 1.0.0 -m "1.0.0"

With the commits squashed and tagged, it’s time to push to github.
We want to push the current branch’s HEAD to the master branch on the github remote.

git push github HEAD:master

Last but not least, we need to push these changes to the branches on origin and merge the squashed commit back to release and master.

You may suspect that git would be confused merging a squashed commit back into branches containing the non-collapsed commits, but it all works just as expected. Git is smart enough to realize no changes need to be made when merging in the squashed commit, but we should still merge to keep our branches in sync.

git push origin github_master

git checkout release
git merge github_master
git push origin release

git checkout master
git merge release
git push origin master