Question

在某些设置中，我习惯在本地使用git，然后导出diff，然后使用详细说明进行提交。因此，当我在本地开发时，我会不断提交，并且在提交之前不要理会有意义的提交消息或完美测试。

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

实现这一目标的最佳方法是什么，如果我觉得自己已经探索了一条小路（但是未经证实的话）而没有改变我当地的工作流程？

Answer 1

如果你看“Trimming GIT Checkins/Squashing GIT History”，你可以：

git rebase --interactive --fixup用于压缩您在rebase --interactive，的提交编辑列表中手动重新排序的提交，同时忽略第二个提交消息，这将使消息编辑更快（你可以保存它：压扁的提交只有第一个提交消息）
git rebase --interactive --autosquash 自动为您执行提交重新排序过程。

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

在此过程中可以交织几个活动（一组微提交）。

所有留给你的是git rebase --interactive --autosquash所有那些微提交要重新排序然后压扁。

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

（另见：

）

alt text

我们为每个客户端库维护了3个分支：


master - 此分支机构正在进行主动开发。

release - 错误修复的开发在这里发生。我们还会破坏版本并更新此分支上的更改日志。

github_master - 我们将发布分支的提交压缩到此分支上的单个“release”提交以及标记版本。此分支跟踪github/master。


我们现在准备转移到github_master分支。

git checkout github_master

我们希望将发布中的更改合并到github_master分支中，但我们不希望看到每个单独的提交。
Git使用git merge --squash命令帮助我们。这将合并来自特定ref的所有更改，将它们压缩到一组更改中并使更改暂停。我们使用消息“1.0.0”提交阶段性更改并标记提交。

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

随着提交被压扁和标记，是时候推送到github了我们想将当前分支的HEAD推送到github remote上的主分支。

git push github HEAD:master

最后但并非最不重要的是，我们需要将这些更改推送到源上的分支，并将压缩的提交合并到release和master。

你可能会怀疑git会混淆将一个压缩的提交合并回包含非崩溃提交的分支，但这一切都按预期工作。 Git足够聪明，意识到在压缩提交中合并时不需要进行任何更改，但我们仍然应该合并以保持我们的分支同步。

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

Answer 2

查看interactive mode of git-rebase。基本上，您将继续使用许多小型提交的当前工作流程。当它向上游推进时，你会git rebase --interactive回到你向上游推送的最后一次提交。然后，Git会在编辑器中显示您的提交列表，允许您重新排序，删除，合并，拆分或重新提交您的提交。

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

2 个答案: