为什么不立即提交合并的更改？

我的办公室使用Git和SourceTree进行版本控制。之所以如此，是因为当我加入时，版本控制为零，而SourceTree是我曾经使用过的唯一系统。我绝对不是专家，但是我是同事中经验最丰富的人，因此我是事实上的专家，负责教会每个人正确使用Git并纠正他们犯的任何错误。

我正在制作一个教程文档，其中涉及Git和SourceTree，并解释了该过程的每个步骤。在“拉”过程中，“ SourceTree”对话框允许您选择“立即提交合并的更改”选项。我了解它的作用以及为什么有用。我不明白的是为什么会有人不希望使用此功能。

有人可以解释为什么您永远不想自动提交合并的更改吗？我试图理解其原因，以便可以更好地解释该功能的用途，并了解将来需要注意的陷阱。

编辑：我不认为我的问题是链接的问题的重复。链接的问题广泛地询问多久提交一次。我在问为什么不选择不使用与在SourceTree中提交合并有关的特定功能。

我不想使用此功能。

没有冲突这一事实实际上意味着，在我的分支中合并的更改与我所做的代码大致不在同一行中。这并不意味着这些更改与我的更改兼容。这并不意味着代码可以编译，也不意味着代码可以工作，或者测试将通过。

换句话说，通过使用此选项，我可能最终会收到伪造的代码提交，这些代码可能未处于良好状态，并且需要修复新的提交。由于我做这个工作，反正，和我永远不会推这种虚假的承诺上游，甚至没有错误（善良禁止，那么有人可能合并是到一些其他分支！），我认为没有理由创建此承诺在第一地点。

合并后，本地存储库中的文件可能会发生更改。除非您设置“立即提交合并的更改”，否则这些更改不会自动提交给本地。

如果未设置该选项，则文件将以未提交的更改形式出现在SourceTree中。

这是因为除非您明确告知Git，否则Git本身不会提交，并且SourceTree是Git GUI。“立即提交合并的更改” 选项不是一个选项，而是命令快捷方式。

因此，对于其原因不想要使用此功能是不言而喻的：要执行提交手动，或根本没有。

假设您将master拖到功能分支。一位同事正在不同的功能分支上。这个同事有打破事物的历史。合并包含此同事对共享通用代码所做的更改。因此，您-与团队其他成员- 请勿提交合并的更改，直到您确定此同事所做的任何更改都不会影响您的工作。

仅仅因为没有充分的理由-从理论上讲-不使用此功能，实际上，可以有许多充分的理由。关于您的教程，我只想说“ 100的99倍，这是您要使用的选项”。我认为您真的不需要详细介绍不使用它的情况，尤其是在其他人对版本控制不熟悉的情况下。这一切都取决于您打算对本教程进行的深入研究。

如果您使用发布后提交挂钩自动推送您的提交（如/programming//a/7925891/6781678），则可能需要此选项以避免推送一些可疑的提交。

我永远不会使用。