Gitステージング：いつステージングするか？その後変更が発生した場合の対処
私はGitの広い世界にかなり慣れていません。マニュアルを読んで練習してきましたが、いくつかの点で混乱しており、検索してもわかりませんでした。
不思議なんだけど：
プロジェクト（最初のコミット後）で、ソースファイルをステージングする適切なタイミングはいつですか？コミットする直前？追加/削除または変更した直後ですか？
ファイルが2つのコミットの中間でステージングされ、その後変更された場合、Gitはどうなりますか？それが述べられたときのコンテンツの変更とそれ以降の内容について注意する必要がありますか？
新しいファイルを作成し、それをステージングしてから削除したい場合、Gitが「-f」フラグを使用するように求め、単純な「git -rm file.ext」が機能しないのはなぜですか？
「ステージの意味」や、Gitのマニュアルやその他のチュートリアルのさまざまな主題を読みましたが、前述のように、まだ上記の問題を理解していません。
ですので、できれば、自分の言葉と例を使って質問に答えてください。そうすれば、理解しやすくなります。
ありがとうございました。
ステージング領域の目的は、コミット用に柔軟なスペースを確保することです。これは、gitをSubversionなどの一元化されたバージョン管理システムと対比すると明らかになると思います。
Subversion
Subversionでは、作業コピーの特定のファイルをコミットすることを選択できます。ただし、完全なファイルのみ。さて：ファイルAではなくファイルBをステージングしたい場合、およびファイルCに関連するファイルAの部分がまだパートではない場合ファイルBの変更に依存します（それ以降は、コミットの整合性に問題が発生します）。
Git
Gitは、ステージングを2番目の作業コピーとして提供することでこれを解決します。ステージング領域内で、（大まかに）コミットするスナップショットをまとめます。
したがって、ステージング領域内で、Aへの変更と、Cの変更のみを反映するファイルAのバージョンを含むスナップショットを作成できます。
特定の質問について
好きなときにステージングできます。個人的には、コミットを開始する直前にステージングすることを好みます。
ステージングされたファイルに変更を加えた後、作業コピーでそのファイルを変更した場合、ステージングされたファイルはもちろん変更されていません。これらもステージングするか、変更をステージングしないかを決定できます。つまり
git gui citoolを実行すると、ステージされたバージョンとステージされていないバージョンの差分が表示されます（行ごとのステージングとコミットのための素敵でシンプルなツール）。Gitはここで慎重であり、これはおそらく良いことです。
一般的なコミット戦略：きめ細かなコミット
「いつステージングすべきか」という質問をするときは、コミットの習慣についても話し合うべきだと思います。
集中型VCS
中央サーバーにコミットする集中型バージョン管理システムでは、コミットが完全で十分にテストされていることが同僚にとって重要でした。したがって、人々はあまり頻繁にコミットせず、エラーの可能性を最小限に抑えるために完全なファイルの状態をコミットしようとします。したがって、コミットは多くの変更を含む非常に大きなチャンクになる傾向があります（単純な修正でない場合）。コミットの変更は、まったく無関係である可能性があります。
Git
Gitではコミットがローカルで実行され、サーバーにプッシュするだけでパブリックになります。したがって、コミットはある意味で安いです。 Subversionの意味でのコミットは、いくつかのgit commitとそれに続くgit Pushに相当します。この違いは重要です。
Gitでは、同じファイルの他の行も変更した場合でも、コードの1行をコミットできます。たとえば、新しい機能を導入する300〜350行目を変更しながら、100行目にセキュリティバグ修正をコミットできるため、これには多くの利点があります。
- さまざまなコミットでさまざまな変更を分離できます。これにより、バージョン履歴でそれらを適切に分離し、一方を元に戻して他方を元に戻すこともできます。
- あなたのコミットは必ずしもあなたの作業コピーの「コンパイル中」の状態を反映する必要はありません（私はそのようにしておくようにしていますが）。
では、Subversionユーザーが期待するコミットの「品質管理」とビルド保証はどこにあるのでしょうか。 gitでは他のアクションに移行しています。それでも、プログラムの機能状態をパブリックリポジトリにプッシュする必要があります。したがって、変更が適用される前に、テストが成功し、プログラムが機能することを確認します。
また、ブランチを最大限に活用してみてください。小さな変更をたくさんコミットすると、かなり大きなバージョン履歴ができてしまいます。ブランチで作業している場合、ブランチ名でこれらの細かいコミットを分類してから、それらをマージして戻すことができます（オプション--no-ffもそれを保持しますこれらの機能は独自のブランチにありました）。
つまりブランチがgood状態である場合にのみ、masterブランチにマージする習慣を保つことができます。タグを使用して、マイルストーンとリリースを追跡することもできます。
ステージングに戻ります：コミットごとに数行をコミットすると、コミットする前に直接ステージングします。 （少なくともそれが私が行う方法です）。
真面目すぎると思います。ステージングは、次のコミットに含めたいものを選択するだけです。ステージングをいつ、どのように行うかは非常にまれです。また、ステージングされた変更とステージングされていない変更が多数ある場合は、おそらく開発プロセスを修正する必要があります。
プロジェクト（最初のコミット後）で、ソースファイルをステージングする適切なタイミングはいつですか？コミットする直前？追加/削除または変更した直後ですか？
私は通常、コミットする直前にそれを行います（タイプミスに気付かない限り、最後の瞬間の修正を行い、それもステージングする必要があります）。プロセスは次のとおりです。編集、テストの実行、ステージング、コミット。テストの前にステージングすると、テストが失敗し、変更を加えてステージングする必要がある可能性が高いので、コミット時までそのままにしないでください。
ファイルが2つのコミットの中間でステージングされ、その後変更された場合、Gitはどうなりますか？それが述べられたときのコンテンツの変更とそれ以降の内容に注意する必要がありますか？
リポジトリの現在の状態と（最後のコミット+段階的な変更）の違いが表示されます。新しい変更の一部をステージングすると、（最後のコミット+ステージングされた変更）状態が再計算されます。
新しいファイルを作成し、それをステージングしてから削除したい場合、Gitが「-f」フラグを使用するように求め、単純な「git -rm file.ext」が機能しないのはなぜですか？
今私はここで推測していますが、おそらくステージングされた情報が重要である可能性があるためです（そうでない場合はステージングしません）が、まだバージョン管理されていません（git -rmで削除できるファイルのように）。したがって、gitは、自分が何をしているかを確実に把握したいと考えています。