マージした変更をすぐにコミットしないのはなぜですか？
私のオフィスでは、バージョン管理にGitとSourceTreeを使用しています。これは、私が参加したときにバージョン管理がなく、SourceTreeが今まで使用した唯一のシステムだったために起こりました。私は決してエキスパートではありませんが、同僚の中で最も経験豊富なので、Gitを適切に使用し、間違いを修正するように全員に教える事実上の専門家です。
私はGitとSourceTreeを通り、プロセスのすべてのステップを説明するチュートリアルドキュメントを作成しています。プルプロセスでは、SourceTreeダイアログで[マージされた変更をすぐにコミットする]オプションを選択できます。これが何をするのか、なぜそれが役立つのか理解しています。私が理解していないのは、誰もがnotがこの機能を使用したいと思う理由です。
マージされた変更を自動的にコミットさせたくない理由を誰かが説明できますか？私はその理由を理解して、機能の有用性をよりよく説明し、将来に注意すべき落とし穴を知ることができるようにしています。
編集：私の質問がリンクされた質問と重複しているとは思わない。リンクされた質問は、コミットする頻度を広く尋ねている。 SourceTree。
この機能を使いたくありません。
競合がなかったという事実は、私のブランチでマージされている変更が、私が行ったものとほぼ同じコード行にないことを意味します。これらの変更が私の変更と互換性があるという意味ではありません。これは、コードがコンパイルされること、コードが機能すること、またはテストに合格することを意味するものではありません。
言い換えると、このオプションを使用することにより、正常な状態ではない可能性があり、修正するために新しいコミットが必要となる誤ったコードのコミットが発生する可能性があります。私はとにかくこの作業を行っており、誤ってではなく、この偽のコミットを上流にプッシュするべきではないので（善意で禁止、誰かがthatを他のブランチにマージする可能性があります！）、理由はわかりません最初にこのコミットを作成します。
マージ後、ローカルリポジトリのファイルが変更される場合があります。 「マージされた変更をすぐにコミットする」を設定しない限り、これらの変更は自動的にローカルにコミットされません。
そのオプションを設定しない場合、ファイルはコミットされていない変更としてSourceTreeに表示されます。
これは、明示的に指示しない限り、Git自体はコミットしないためであり、SourceTreeはGit GUIです。 「すぐにマージされた変更をコミットする」オプションは、コマンドのショートカットであるため、それほどオプションではありません。
つまり、この機能を使用したいnotの理由は自明です。手動でコミットを実行するか、まったく実行しないかです。
マスターを機能ブランチにプルするとします。同僚が別の機能ブランチで作業しています。この同僚には、物事を壊した歴史があります。マージには、この同僚によって行われた共有共通コードへの変更が含まれています。したがって、あなたは-チームの他のメンバーと一緒に-しないでください作業に影響を与えるこの同僚による変更がないことが確認されるまで、マージされた変更をコミットします。
理論上、この機能を使用しない正当な理由がないからといって、実際には多くの正当な理由が考えられます。あなたのチュートリアルに関しては、「100のうち99倍、これはあなたが使いたいオプションです」とだけ言っておきます。特に他のユーザーがバージョン管理に不慣れな場合は、使用しないことについて詳細に説明する必要はないと思います。それはすべて、チュートリアルをどの程度深くするかによって異なります。
コミット後のフックを使用してコミットを自動プッシュする場合（ https://stackoverflow.com/a/7925891/6781678 のように）、が必要になる場合がありますこのオプションは、疑わしい品質のコミットのプッシュを回避します。
どちらも使用しません。