为什么 git 默认在合并后提交？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5164418/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why does git commit after a merge by default?
提问by Will
I'm curious about this behavior and maybe its just because I've come from using SVN and bazaar mostly. (I'm learning git to interface with the excellent github.)
我对这种行为很好奇，也许只是因为我主要使用 SVN 和 bazaar。（我正在学习 git 来与优秀的 github 交互。）
It seems counter intuitive to me and as if it would be better for
这对我来说似乎违反直觉，好像它更适合
git merge [branch] --no-commit
git merge [branch] --no-commit
to be the default to encourage people to make sure the merge went the way they wanted it to before committing.
作为默认设置，鼓励人们在提交之前确保合并按照他们想要的方式进行。
回答by VonC
The goal set by Linus Torvalds when creating Git was to make all the merges that could be automatically solved... FAST. See his 2007 Google Tech Talk: Linus Torvalds on Git (transcript)
I.e. hundreds of merges in less than a few seconds.
Linus Torvalds 在创建 Git 时设定的目标是使所有可以自动解决的合并...... FAST。参见他的2007 年 Google 技术演讲：Linus Torvalds on Git（成绩单），
即在不到几秒钟的时间内完成数百次合并。
So a "--no-commit" by default would pretty much defeat that purpose.
因此--no-commit，默认情况下“ ”几乎会破坏该目的。
With
--no-commitperform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing.
随着
--no-commit执行合并，但假装失败的合并，不自动提交，给用户提供一个机会来检查和进一步提交之前调整合并结果。
Extract from Linus's talk (video):
The only thing that matters is how fast can you merge.
In git, you can merge... I merge 22,000 files several times a day, and I get unhappy if a merge takes more than 5 seconds, and all of those 5 seconds is just downloading all the diffs, well not the diffs but its the deltas between two trees, the merge itself takes less than half a second.
And I do not have to think about it.
[...]That's the kind of performance that actually changes how you work.
唯一重要的是合并的速度。
在 git 中，你可以合并……我一天合并 22,000 个文件，如果合并时间超过 5 秒，我会很不高兴，而这 5 秒只是下载所有差异，而不是差异，而是它的两棵树之间的增量，合并本身不到半秒。
我不必考虑它。
[...]这种表现实际上会改变您的工作方式。
