この記事は、Git の概念、整理およびマップを行うための一般的なコマンドとワークフローの紹介に続いています。TranSad のブログ - CSDN ブログ

いくつかの補足は後で、追加の Git 操作でより一般的に使用される操作のいくつかを要約する方法を学習します。したがって、この記事ではすでに以前の基礎ができていることを前提として、言及されていない部分について直接話します。

デタッチドヘッド

Git では通常、HEAD を現在のブランチへのポインターとして考えますが、ローカルブランチではない参照 (タグ、リモートブランチ、SHA-1 ID、または相対ブランチなど) をチェックアウト (チェックアウト) する場合は、 main~3 などの参照) を実行すると、「切り離されたヘッドポインター」状態と呼ばれる特別な状態に入ります。

「デタッチされたヘッドポインター」状態では、HEAD はブランチを指さず、直接コミットを指します。この状態は「匿名ブランチ」と考えることができます。この状態では、通常どおりコミットを行うことができますが、それらのコミットは名前付きブランチを更新しません。この状態は、コミット履歴をナビゲートするのに役立ちます。たとえば、コードの特定のバージョンをチェックアウトし、コンパイルしてインストールし、master ブランチに戻すことができます。

「ヘッド分離」状態でコミットを行った後、別のブランチ (例: main) に切り替えると、「ヘッド分離」状態で行ったコミットが失われる可能性があります。「デタッチヘッド」状態で作成されたコミットを保存したい場合は、ブランチを切り替える前に、それらのコミットを参照する新しいブランチを作成する必要があります。git checkout -b nameコマンドを使用して、新しいブランチを作成したり、新しいブランチに切り替えることができます。このコマンドは、新しいブランチを作成し、HEAD ポインターをこの新しいブランチに切り替えます。これにより、「切り離されたヘッドポインター」状態で行ったコミットが失われることはありません。

メインブランチに直接チェックアウトして戻すと、レコードは失われます。これは、Git では、コミットがブランチやタグによって参照されていない場合、一定期間後に Git のガベージコレクションメカニズムによって削除される可能性があるためです。

キツネ

リベースの基本の簡単な要約: フィーチャーブランチで git rebase main を使用する場合、このコマンドはフィーチャーブランチ上のすべてのコミットをプルし、メインブランチからの最新のコミットの上にそれらを再適用します。

元のコミットがどのブランチまたはラベルからも参照されなくなった場合、それらは一定期間後に Git のガベージコレクションメカニズムによって削除される可能性があります (つまり、図の奇数のコミットの部分)。したがって、元のコミットを保持する必要がある場合は、それらを参照しているブランチが存在する限り削除されないため、事前に新しいブランチを作成してrebaseこれらのコミットを参照 (または保存) する必要があります。git checkout -b name命令

初期状態に戻り、コマンドを逆にすると、つまり git checkout main git rebase feature となり、main ブランチのコミットを feature ブランチの後ろに置くことになります。

現時点で、複数人で開発を行っている場合、ローカルウェアハウスはリモートウェアハウスのメインブランチとは異なり、他の人のメインブランチがまだそこにあるため、一連の問題が発生するため、使用しないでください。リベースが間違っている 2 番目に、複数人による開発にはマージを使用する方が適切です。マージを使用した通常のワークフローは次のとおりです。

まず、ローカルリポジトリで、マスターブランチ ( ) からmain新しいブランチ ( など) をチェックアウトし、この新しいブランチ上で開発します。feature
開発作業が完了したら、メインブランチに戻り、git merge featureコマンドを使用して作業をメインブランチにマージできます。この操作により、新しいマージコミットが作成されます。
次に、master ブランチをリモートリポジトリにプッシュし、リモートリポジトリでプルリクエスト (プルリクエスト) を作成できます。このプルリクエストは変更内容を示し、プロジェクトの他のメンバーにコードをレビューして変更内容をプロジェクトの master ブランチにマージするように依頼します。

ここで、リベースに戻り、他の高度な操作について話しましょう。

git rebase --interactive

git rebase --interactive は、コミットの圧縮 ( squashing )、分割 ( splitting )、コミットの削除 ( deleting ) など、コミット履歴に対してより複雑な操作を対話的に実行できるようにするコマンドです。

簡単な例から始めましょう。git rebase -i main(featureブランチ上で) 実行されると、Git はmain移動される (つまりブランチに適用される) すべてのコミットをリストするテキストエディターを開きます。

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

各 commit の前にpick、そのコミットがこのリベースで使用されます。これらの行の順序を調整することで、コミットが実行される順序を変更できます。これらのコミットは上から下に (ログに示されているように逆の順序で) 実行されるため、コミットは最初にブランチ33d5b7aに追加されます。mainここで行を削除すると、対応するコミットは破棄されます。すべての行を削除すると、リベース操作は中止されます。ファイルを保存して閉じると、Git は指示に従ってリベース操作を実行します。

潰す圧縮

コミットを「潰す」とは、一連のコミットを 1 つのコミットに結合することです。これは、機能ブランチを開発ブランチにマージするときに非常に役立ちます。小規模なコミットが多数あり、develop ブランチにマージすると、他の開発者が読むのがわかりにくくなる可能性があります。コード例を次に示します。 2 番目と 3 番目のコミットで最初のコミットの軽微な問題が修正されると仮定すると、コマンドを使用してsquashそれらを 1 つのコミットにマージできます。

pick 33d5b7a Message for commit #1
squash 9480b3d Message for commit #2
squash 5c67e61 Message for commit #3

squashコミットを選択すると、Git はそのコミットからの変更を前の (つまり上記の) コミットに組み込みます。この例では、両方のコミット9480b3dからの変更がこのコミット5c67e61にマージされます。33d5b7aこれは、3 つのコミットすべてからの変更が新しいコミットにまとめられることを意味します。Git はエディターを開き、新しくマージされたコミットに対する新しいコミットメッセージを作成できるようにします。このメッセージは通常、デフォルトですべての圧縮されたコミットメッセージのコレクションになりますが、必要に応じて編集できます。最後に、エディターを保存して閉じると、Git はリベース操作を完了します。コミット履歴にはすべての変更を含む新しいコミットが 1 つだけ存在し、元の 3 つのコミットは存在しなくなります。

分割する

コミットを「分割」するとは、コミットを別々のコミットに分割することです。これは、1 つのコミットで行われた変更が多すぎる場合に便利です。そのコミットを 1 つ以上の個別のコミットに分割すると、バージョン履歴がより詳細になり、読み取りと変更が容易になります。コード例を次に示します。 2 番目のコミットを 2 つの別々のコミットに分割したいとします。spliteditコマンドを使用できます。

pick 33d5b7a Message for commit #1
edit 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Git は最初に最初のコミット (33d5b7a) を実行し、次に 2 番目のコミット (9480b3d) を適用します。2 番目のコミットで edit が使用されたことが判明すると、git はコンソールを表示します。そこから、git reset HEAD~そのコミットの混合リセットを使用できます。これにより、基本的にそのコミットが取り消され、変更されたファイルがステージングされないままになります。ファイルを複数のコミットに分けてステージングしてコミットできるようになりました。例えば：

$ git add file_for_first_commit
$ git commit -m ‘first commit message’
$ git add file_for_second_commit
$ git commit -m ‘second commit message’
$ git rebase --continue

編集コマンドの処理が完了すると、git は最後のコミット (5c67e61) を処理します。

削除削除

コミットを「削除」するとは、コミット履歴からコミットを削除することです。3 番目のコミットに問題がある場合は、次のdropコマンドを使用して削除できます。

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
drop 5c67e61 Message for commit #3

ファイルを保存して閉じると、Git によって変更が適用され、エディターに戻ってコミットメッセージをマージします。保存後、Git は指示に従ってリベースを実行します。

Git がコミットオブジェクトを構築する方法により、コミットを削除または変更すると、それに続くすべてのコミットが書き換えられることに注意することが重要です。リポジトリ履歴を遡るほど、より多くのコミットを再構築する必要があります。削除したばかりのコミットに依存するコミットがシーケンスの後半に多数ある場合、これにより多くのマージ競合が発生する可能性があります。上の例では、最後のコミットを削除しただけなので、問題ありません。

その他の git rebase --interactive コマンド:

p、<コミット> を選択 = コミットを使用
r、reword <commit> = コミットを使用しますが、コミットメッセージを編集します
e、edit <commit> = コミットを使用しますが、修正のために停止します
s, squash <commit> = コミットを使用しますが、前のコミットに結合します
f, fixup <commit> = "squash" と同様ですが、このコミットのログメッセージを破棄します
x, exec <command> = シェルを使用してコマンド (行の残りの部分) を実行します。
b, Break = ここで停止 (「git rebase-- continue」で後でリベースを続行)
d、drop <commit> = コミットを削除します
l, label <label> = 現在の HEAD に名前を付ける
t、reset <label> = HEAD をラベルにリセットします
m、マージ [-C <コミット> | -c <commit>] <label> [# <oneline>] = 元のマージコミットのメッセージ (元のマージコミットが指定されていない場合は 1 行) を使用してマージコミットを作成します。コミットメッセージを言い換えるには、-c <commit> を使用します。

Git commit --amend

最後に、amend を追加します。amend キーワードも非常に便利です。おそらく、最後の提出を更新したい場合は、このgit commit --amend -m “message for updated commit”コマンドを使用できます。このコマンドは、最後のコミットに変更を追加し、コミットメッセージを更新します。

Git の高度な高度な操作