Gitのステージング領域の用途は何ですか？
ステージング領域に追加するためのgit add .またはgit add <filename>のポイントは何ですか？なぜgit commit -m "blabla"だけではないのですか？
ステージングエリアの価値がわかりません。
Gitのステージングには多くの用途があります。いくつかは以下にリストされています：-
ステージングは、1つの大きな変更を複数のコミットに分割するのに役立ちます-多くのファイルとかなりの数の異なるサブタスクを含む、大規模な変更に取り組んだとしましょう。実際にはこれらのいずれもコミットしていません-彼らが言うように、あなたは「ゾーン内」にいたので、コミットを適切な方法で分割することについて考えたくありませんでした。 （そしてあなたは大きなコミットを警戒することですべてを行わないほど賢いです！）変更はすべてテストされて機能しているため、コード変更の1つの側面に焦点を当てたいくつかのクリーンコミットで、これらすべてを適切にコミットする必要があります。インデックスを使用して、各変更セットをステージングし、保留中の変更がなくなるまでコミットします。あなたがそれに夢中なら、本当にgit guiでもうまく機能します。または、git add -pを使用することも、新しいgitsではgit add -eを使用することもできます。
ステージングは変更のレビューに役立ちます-ステージングは、複雑なコミットをレビューするときに個々の変更を「チェックオフ」し、まだレビューに合格していないものに集中するのに役立ちます。説明させてください。コミットする前に、おそらくgit diffを使用して変更全体を確認します。確認しながら各変更をステージングすると、まだステージングされていない変更に集中できることがわかります。 git guiは素晴らしいです。左側の2つのペインには、ステージングされていない変更とステージングされた変更がそれぞれ表示され、ファイル名の左側にあるアイコンをクリックするだけで、2つのペイン間（ステージ/アンステージング）にファイルを移動できます。さらに、ファイルへの部分的な変更をステージングすることもできます。 git guiの右側のペインで、承認する変更を右クリックし、「stage hunk」を選択します。 （ファイル全体ではなく）その変更だけがステージングされます。実際、同じファイルにステージングされていない他の変更がある場合、ファイルは左上と左下の両方のペインに表示されます。
ステージングは、マージに競合がある場合に役立ちます-マージが発生すると、ステージング領域と作業ツリーの両方で、クリーンにマージされる変更が更新されます。 git diffを実行するとき、またはgit guiの左上のペインに表示されるのは、完全にマージされなかった（つまり、競合を引き起こした）変更のみです。ここでも、注意が必要なもの、つまりマージの競合に集中できます。
ステージングは、余分なローカルファイルをぶら下げておくのに役立ちます-通常、コミットしてはならないファイルは、.gitignoreまたはローカルバリアントの.git/info/excludeに入ります。ただし、除外できないファイルのローカル変更が必要な場合があります（これはお勧めできませんが、場合によっては発生する可能性があります）。たとえば、ビルド環境をアップグレードし、互換性のために追加のフラグまたはオプションが必要になったとしますが、Makefileへの変更をコミットすると、他の開発者に問題が発生します。もちろん、チームと話し合ってより恒久的な解決策を考え出す必要がありますが、今のところ、作業を行うには作業ツリーでその変更が必要です！別の状況としては、一時的な新しいローカルファイルが必要で、無視メカニズムに煩わされたくない場合があります。これは、いくつかのテストデータ、ログファイルまたはトレースファイル、またはいくつかのテストを自動化する一時的なシェルスクリプトなどです。 gitでは、そのファイルやその変更をステージングする必要はありません。それでおしまい。
ステージングは小さな変更をこなすのに役立ちます-やや大規模な変更の真っ只中にいて、できるだけ早く修正する必要がある非常に重要なバグについて通知されたとします。通常の推奨事項は別のブランチでこれを行うことですが、この修正は実際には1行または2行であり、現在の作業に影響を与えずに簡単にテストできるとしましょう。 gitを使用すると、作業中の他のすべてのものをコミットすることなく、その変更のみをすばやく作成してコミットできます。繰り返しになりますが、git guiを使用すると、左下のペインにあるものがコミットされます。そのため、その変更だけがそこに到達してコミットされることを確認してから、Push！
Gitがこれを処理する方法（Gitがステージング領域について知って使用するようにする）とMercurialがこれを処理する方法を比較する価値があります。 Mercurialでは、あなたが提案したとおりに機能します。hg commitを実行するだけで、Mercurialは変更内容を把握してコミットします。 newファイルをhg addする必要がありますが、既存のファイルを変更するだけの場合は、特別なことはありません。 、コミットすると、完了です。
Mercurialの動作は、はるかに新しいユーザーフレンドリーであるように見えます（私の観察では、ずっとそうでした）。 Gitは実際にgit commit -aを使用して同じ効果のほとんどを得ることができます。つまり、使用する他のオプションに-aを追加するだけで、GitはMercurialとほとんど同じことを行います。しかし、これは一種の松葉杖です。ステージングエリアについて知らない限り、最終的にはGitが実行した何かを説明できないためです。
Hidd3Nの回答 は、Gitのステージング領域を使用できるいくつかの方法を示しています。しかし、少し後戻りしてMercurialとGitを比較すると、実際に何が起こっているのかをより多く見ることができると思います。
バージョン管理システム（VCS）の仕事は、everyコミットされたバージョンever。 （そして、GitとMercurialは両方ともシステム全体のスナップショットのスナップショットに基づいて動作するため、ここで比較するのは簡単です。動作するはるかに古いVCSがいくつかあります。一度に1つのファイルに：各ファイルを個別にチェックイン/コミットする必要があります。GitとMercurialは、すべて一度にすべてのスナップショットを作成します。）これらのコミットされたスナップショットは永久に持続し、まったく変更されません。つまり、それらはread-onlyです。
ただし、読み取り専用のファイルは作業に適していません。したがって、VCSは必ず、何らかの理由で/どこかで、2つの別個のものが必要です：
- ファイルで作業する場所：これはwork-tree;そして
- スナップショットが保存される場所：これはバージョンデータベース、リポジトリ、またはその他のWordです。Gitはこれらのものobjectsを呼び出しますが、Mercurialはより複雑です構造のセットなので、ここではそれらobjectsと呼びましょう。
Gitのオブジェクトストレージ領域には、読み取り専用オブジェクトの束があります。実際、すべてのファイルに1つ、すべてのコミットに1つ、というように続きます。 newオブジェクトはいつでも追加できますが、既存のオブジェクトを変更することはできません。
Mercurialが示すように、個別のステージング領域に要件はありません。VCSはwork-tree提案されたコミットとして。 hg commitを実行すると、Mercurialは作業ツリーをパッケージ化し、そこからコミットします。作業ツリーを変更すると、提案された次のコミットが変更されます。 hg statusコマンドは、コミットすることを提案しているものを示します。つまり、現在のコミットと作業ツリーの間で異なるものは何でもあります。
ただし、Gitは、読み取り専用コミットと読み取り/書き込み作業ツリーの中間に、この中間領域を挿入することを選択します。この中間領域、ステージング領域またはindexまたはcache、提案された次のコミットが含まれます。
まず、いくつかのコミットをチェックアウトします。この時点で、すべてのファイルのコピーが3つあります。
- 1つは現在のコミットにあります（Gitは常に
HEADという名前で見つけることができます）。これは読み取り専用です。変更することはできません。これは特別な、圧縮された（ときどきvery圧縮された）Git専用の形式です。 - 1つはインデックス/ステージング領域にあります。これは
HEADと一致しますが、変更できます。 nextコミットに進むことが提案されたものです。これも、Git専用の特別な形式です。 - 最後の1つは作業ツリーにあり、通常の形式で作業できます。
git addが行うことは、作業ツリーからステージング領域にファイルをコピーすることです上書きHEADコミット。
git statusを実行するときは、2つの個別の比較を行う必要があります。1つはHEADコミットをインデックス/ステージングに比較します-エリア、次のコミットで何が違うのかを確認します。これがto be committedです。 2番目の比較では、インデックス/ステージング領域と作業ツリーの違いがわかります。これがnot staged for commitです。
git commit -aを実行すると、Gitは2番目の比較に基づいてステージング領域へのコピーを実行します。より正確には、git add -uに相当するものを実行します。 （コミットが何らかの理由で失敗した場合に備えて、temporarystaging-areaで密かにこれを行うため、通常のstaging-area/indexは影響を受けませんコミットの期間中。これの一部は、追加のgit commit引数にも依存します。通常、これは、少なくとも複雑なコミットフックの書き込みを開始するまで、非表示になる傾向があります。）
ステージングが役に立たないと思うなら、gitとソフトウェア開発の全力にも気づいているかもしれません。ステージングとは、それらのファイルを現在のブランチにコミットすることを意味します。一部のファイルをコミットしたくないために、それらのファイルがコミット用にステージングされない場合があります。
例：-システムに固有のいくつかのデフォルト設定。これらの設定ファイルを、誰もが使用しているブランチにコミットしたくない場合があります。それがあなたの疑いを晴らしてくれることを願っています！ :-)
staging area はラフドラフトスペースのようなもので、ファイルのバージョンをgit addすることができます次のコミットに保存する複数のファイル（つまり、プロジェクトの次のバージョン）。
ファイルのバージョンをステージング領域にコピーし、コミットする前にそれらを ステージング領域から で取り込めることに注意してください。これが、私がラフドラフトスペースと呼んだ理由です。
git add コマンドが実際に行うことは、ファイルのそのバージョンを作業ディレクトリからステージング領域にコピーすることです。
（これはよくある誤解です。人々はメンタルモデルでファイルが移動されたと思っているかもしれませんが、実際にはコピーされています）。
ファイルの更新バージョンがリポジトリに追加されるまでの経路：
- 1️⃣あなたのworking directoryで編集されます。作業ディレクトリは、ファイルの編集、新しいファイルの追加、ファイルの削除を行うワークベンチのようなものです。
- 2️⃣次に、
git addコマンドを使用して、ファイルがステージング領域に追加されます - 3️⃣最後に、
git commitコマンドを使用すると、次のコミットに含まれます
ステージング領域に追加してコミットに含めるファイルを選択できることの良い点は、この方法で作業を整理できることです。
1つの作業に関連するすべての更新されたファイルを追加できます。また、コミットするときに、その作業について言及するメッセージを追加できます。 。
これにより、コミットをより適切に整理できます。
この動画 ????上記すべてを非常にシンプルで視覚的に説明しているので、役立つかもしれません。
pSステージングエリアが実際に.gitディレクトリにあることに興味がある場合に備えて、もう1つの小さなヒントです。 .gitディレクトリのindex fileで表されます！