マージした変更をすぐにコミットしないのはなぜですか？

私のオフィスでは、バージョン管理にGitとSourceTreeを使用しています。これは、私が参加したときにバージョン管理がゼロであり、SourceTreeしか使用したことがなかったためです。私は決して専門家ではありませんが、同僚の中で最も経験豊富なので、Gitを適切に使用し、間違いを修正するように全員に教える責任がある事実上の専門家です。

GitとSourceTreeを経て、プロセスのすべてのステップを説明するチュートリアルドキュメントを作成しています。プルプロセスでは、SourceTreeダイアログで[マージされた変更をすぐにコミットする]オプションを選択できます。私はこれが何をするのか、なぜそれが役立つのかを理解しています。私が理解していないのは、なぜこの機能を使用したくないのかということです。

マージした変更を自動的にコミットしたくない理由を誰かが説明できますか？私はこの機能の有用性をよりよく説明し、将来どのような落とし穴に注意すべきかを理解できるように、理由を理解しようとしています。

編集：私の質問がリンクされた質問の複製だとは思わない。リンクされた質問は広くコミットする頻度を尋ねています。SourceTreeでのマージのコミットに関連する特定の機能を使用しないことを選択する理由について質問しています。

この機能は使いたくありません。

競合がなかったという事実は、ブランチでマージされる変更が、私が行ったものとほぼ同じコード行にないことを意味します。これらの変更が私の変更と互換性があるという意味ではありません。コードがコンパイルされる、コードが機能する、またはテストに合格するという意味ではありません。

言い換えると、このオプションを使用することにより、コードが誤った状態でコミットされてしまい、正常な状態ではない可能性があり、修正するには新しいコミットが必要になる可能性があります。私はとにかくこの作業を行っているので、誤ってでもこの偽のコミットを上流にプッシュしてはいけないので（幸いなことに、誰かがそれを他のブランチにマージするかもしれません！）、このコミットを最初に作成する理由はありません場所。

マージ後、ローカルリポジトリのファイルが変更される場合があります。「マージされた変更をすぐにコミット」を設定しない限り、これらの変更は自動的にローカルにコミットされません。

このオプションを設定しない場合、ファイルは未確定の変更としてSourceTreeに表示されます。

これは、明示的に指示しない限りGit自体がコミットせず、SourceTreeがGit GUIであるためです。「マージされた変更をすぐにコミット」オプションは、コマンドのショートカットであるため、それほど多くのオプションではありません。

したがって、この機能を使用したくない理由は自明です。コミットを手動で実行するか、まったく実行しないかです。

masterを機能ブランチにプルするとします。同僚が別の機能ブランチに取り組んでいます。この同僚には、物事を壊した歴史があります。マージには、この同僚が行った共有共通コードへの変更が含まれます。そのため、チームの他のメンバーと一緒に、この同僚によって行われた作業に影響する変更がないことを確認するまで、マージされた変更をコミットしないでください。

理論上、この機能を使用しない正当な理由がないという理由だけで、実際には、多くの正当な理由があります。あなたのチュートリアルに関しては、「100回のうち99回、これはあなたが使いたいオプションです」とだけ言っておきます。特に他の人がバージョン管理に慣れていない場合は、使用しないことについて詳しく説明する必要はないと思います。それはすべて、チュートリアルの詳細度に依存します。

コミット後のフックを使用してコミットを自動プッシュする場合（/programming//a/7925891/6781678など）、必要になる場合があります疑わしい品質のコミットのプッシュを回避するためにこのオプションます。

どちらも使用しません。