Git add -p: 特定の行をステージングし、焦点を当てたコミットを行う

ファイルの一部のみをコミットするには、`git add -p -- path/to/file` で必要な変更をステージングし、`git diff --cached` で確認してからコミットします。 残りの編集内容は作業ファイルに残ります。 GitTree で、ファイル diff を開き、変更された行を選択し、Stage Lines を選択して、同じ種類のフォーカスされたコミットを準備します。

チェックアウト検証のバグを修正し、同じコンポーネントの再編成を開始したとします。レビュー担当者は、未完成のリファクタリングを読まなくてもバグ修正を理解できる必要があります。このガイドでは、それらの変更が歴史になる前に分けて説明します。アニメーション化された例では、macOS、Windows、および Linux 用に作成したクライアントである GitTree を使用します。部分的なステージングは​​無料プランに属します。現在の公式ビルドにはサインインが必要です。

作業ツリー、ステージング領域、コミット: 何が保存されますか?

ステージングは選択ステップであり、コミットやプッシュではありません。ファイルは部分的にステージングできます。インデックスには 1 つのバージョンが保持され、エディタにはすべての編集内容が表示されます。ステージング後に再度編集した場合、ステージングされたバージョンはサイレントに更新されません。コミットする前にもう一度見直してください。 ビジュアルコミットグラフ は、コミットが存在する場合の履歴を検査するのに役立ちます。

1 つのファイルで git add -p を使用する方法

git status から始めて、すでにステージングされているものを検査します。パッチ モードでは、選択した変更を既存のインデックスに追加します。以前の選択内容は削除されません。この例では、src/checkout.ts を追跡されたテキスト ファイルに置き換え、Git が各ブロックについて尋ねたときに検証修正のみを受け入れます。

git status
git diff --cached
git diff -- src/checkout.ts
git add -p -- src/checkout.ts
git diff --cached
git diff -- src/checkout.ts
git commit -m "fix: validate checkout input"

段階的な差分を確認し、意図した変更をテストした後でのみ、最終コミットを実行します。 git diff --cached はコミットが記録する内容を示します。 plain git diff は、コミットされないままになるものを示します。このワークフローでは、git commit -a を使用したり、ファイル パスを git commit に指定したりしないでください。これらのフォームは、準備したばかりの部分選択をバイパスする可能性があります。

修正とリファクタリングが近くにある場合はハンクを分割する

ハンクは、コンテキストを含む、近くで変更された行のブロックです。パッチ モードでは、修正とリファクタリングをグループ化できます。 s を使用して、Git にブロックの分割を依頼します。編集内容を自動的に分離できない場合は、e でパッチ エディターが開くか、視覚的なライン セレクターを使用して、目的の追加と削除を選択できます。

置換の場合は、削除された行とその置換の両方を 1 つの論理的な変更として考慮してください。半分だけを選択すると、エディターでは見たことのないコードが生成される可能性があります。高度なパッチ編集はオプションです。ステージングされた結果を説明できない場合は、ステージングを解除して、より明確な境界を選択してください。集中的なコミットは、単に小さいだけではなく、それ自体で動作する必要があります。

GitTree をダウンロード を使用して混合差分を確認し、焦点を当てたコミットを視覚的に構築します。ターミナルと一緒に既存のリポジトリで使用できます。どちらも同じ Git ステージング領域を読み取ります。

編集内容を破棄せずに変更をステージング解除します

git restore --staged -- src/checkout.ts
# Or choose which staged blocks to remove:
git restore --staged -p -- src/checkout.ts

これらは代替コマンドです。 --staged を使用すると、復元では作業ファイルではなくインデックスが変更されます。コミットのあるリポジトリの場合、通常はステージングされたコンテンツを HEAD に向けてリセットします。 --staged を指定しないと、復元によって作業中の編集内容が上書きされる可能性があるため、区別を明確にしてください。次のコミットに含まれる内容のみを変更する場合は、GitTree で、破棄ではなくステージ解除を選択します。

ファイルが 2 回表示される、または行がステージングできない理由

ステージング ファイルとステージングされていないファイルの両方にあるファイルは、通常、重複ファイルではなく、部分的なステージングまたは後の編集を意味します。新しい追跡されていないテキスト ファイルは、パッチ モードでそのコンテンツを提供する前に、git add -N -- path/to/new-file が必要な場合があります。バイナリ ファイルには通常のテキスト ハンクはありません。 GitTree は、名前変更、LFS ポインター、サブモジュールの変更をファイル全体の操作としてステージングします。空白が非表示の場合は、空白のみの変更を選択する前に空白を表示してください。

差分を開いた後にエディターまたはフォーマッタがファイルを変更すると、GitTree は古い行の選択を拒否する可能性があります。差分を更新して、再度選択します。行数を減らすためだけに、密結合した変更を分割することは避けてください。タスクの中断の場合は、未完了の作業を隠します;すでにコミットされている混合履歴については、インタラクティブ リベース ガイド を参照してください。

エディターのファイルだけでなく、準備中のコミットをテストします

通常のテスト コマンドは、ステージングされていない編集を含む作業ファイルに対して実行されます。そこでのテストに合格しても、部分的なコミットが完了したことは証明されません。重要な分割の場合は、最初のローカル コミットを作成し、そのコミットされたスナップショットを別のクリーン チェックアウトまたはワークツリーで検査してテストします。ブランチを共有する前に失敗した場合は、不足している依存関係を追加します。 ワークツリー ガイド では、別々のフォルダーがこれらのバージョンを区別するのにどのように役立つかについて説明しています。