典型的な Git ワークフローは、(作業ツリー内のファイルを変更) -> (インデックスを で変更git add/rm/etc) -> (実行git commit) の 3 ステップのプロセスであることを理解しています。
しかし、なぜ Git は作業ツリーをステージング領域として扱わないのでしょうか? たとえば、ファイルを変更すると、特にステージングしないように git に指示しない限り、コミットのために自動的に「ステージング」されます。これは、「オプトイン」ではなく「オプトアウト」のアプローチです。作業ツリー内のファイルの 99% がコミットされるため、これは理にかなっています。また、後でスタッシュするgit stashのではなく、作業ツリーから一時的なブランチを作成するだけで済むため、メカニズム全体が冗長になります。saveapply
作業ツリーとインデックスを分離する正当な理由がある場合は、それを聞いてみたいです... おそらく、まだ Git について十分に理解していないという事実から、私の混乱が生じているのでしょう。
実際、Gitサイトには、ステージング領域とは何か、それが存在する理由、提供される利点、およびコミット時にステージング領域を回避する方法についての適切な説明があります。
http://git-scm.com/about/staging-areaから取得
ステージングエリア
他のシステムとは異なり、Git には「ステージング エリア」または「インデックス」と呼ばれるものがあります。これは、コミットを完了する前にコミットをフォーマットおよびレビューできる中間領域です。
Git が他のツールと異なる点の 1 つは、ファイルの一部をすばやくステージングしてコミットできることです。作業ディレクトリ内の他の変更されたすべてのファイルをコミットしたり、コミット中にコマンド ラインでそれらをリストしたりする必要はありません。
これにより、変更されたファイルの一部のみをステージングできます。論理的に無関係な 2 つの変更をファイルに加えて、そのうちの 1 つをコミットするのを忘れていたことに気付く時代は終わりました。これで、現在のコミットに必要な変更をステージングし、次のコミットのために他の変更をステージングすることができます。この機能は、必要に応じてファイルにさまざまな変更を加えることができます。
もちろん、Git では、そのような制御が必要ない場合は、この機能を簡単に無視できます。すべてのファイルに対するすべての変更をステージング領域に追加するには、コミット コマンドに「-a」を追加するだけです。
お役に立てれば。乾杯！