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