Git(2)

これはGitに対する2番目の宣伝です今日Gitについての授業が終わり、事前に知っていた知識以外にも知らないところがたくさんありました.
だからGitを軽蔑するんだ

checkout, switch, restore

以前のバージョンではcheckoutコマンドしかありませんでしたが、バージョンがアップグレードされるにつれてcheckoutはswitchコマンドとrestoreコマンドに分けられます.
checkoutコマンドはブランチを移動するほか、特定のポイントに復元できる機能もあるので、初めて知った事実です.

git checkout -- [filename]

ファイルを変更前に復元するには、次のようにします.

git restore [filename]

restoreも同様の機能を提供しています.

git switch -c [branch_name]

switchは以前ブランチを移動する際に使用したcheckoutと同じ使い方をしています.
ブランチを作成しながらブランチを移動する場合は-bオプションを使用し、switchは-cオプションを使用します.

Merge Conflict

異なるブランチで同じファイルを処理するときに競合が発生した場合?
一番いい答えは、最初からそんなことは起こらないということです.しかし、このような状況が発生しなければならない場合は、開発者は3つのシナリオのうち1つを選択する必要があります.
すべてクリアするか、どちらかを選択するか、両方をマージします.
Gitはファイルを行ごとに追跡するので、あるファイルが別のブランチで変更されると、必然的に衝突します.

次は、2つのブランチテストとtest 2で同じファイルをそれぞれ変更したときに発生する競合状況です.statusコマンドで確認すると、次の競合が検出され、どのファイルが競合しているかを示します.

HEADは現在のブランチ(このブランチの最新コミット)であり、分割線の下の内容は衝突した部分である.

競合が解決しadd、commitコマンドが発行されると、次のコミットメッセージが自動的に生成されます.commit時-mオプションが自制する必要がある理由が明らかになった.
-mオプションはその情報を上書きするからです.

UNDO

現在の作業ディレクトリ、stagingの変更、またはコミットされた内容を返すにはどうすればいいですか?
これも最善の方法で、最初はこのような状況を起こさせないが、人は完璧ではない.

restore, checkout

git checkout -- [filename]
git restore [filename]

前述したように、作業ディレクトリでの変更は簡単です.以上のコマンドは、変更前の状況に戻ることができます.

commit --amend, reset, revert

git commit --amend

commit以外のメッセージのみを変更する場合は、次のコマンドを使用します.
REVERTもRESETもCOMMITに戻るコマンドですが、REVERTの場合、以前のCOMMITは履歴に残り、RESETは履歴に初期化されます.
なぜcommitに戻ったのか分からないのでresetを避けて戻ったほうがいいです.
リストアとリセットに使用するオプションフラグは、さまざまです.このコマンドを使用すると、適切なオプションを設定できます.

リファレンス

ファイルの名前を変更
->ファイル名を変更すると、リーダーはrenameではなくファイルが削除されたと判断し、別のファイルが作成されます.

git mv [name] [rename]

このコマンドを使用すると、renameを使用して変更履歴を保持できます.

HEAD
HEADは現在のブランチの最新のコミットですが、commitのハッシュ値を使用して以前のコミットに移行できます.

このときHEADを分離HEADと呼び,ブランチを介さずに直接提出する場合を指す.
考えてみれば、HEADは必ずしも支路を指す必要はないようだ.ブランチは最終的にcommitへのポインタであり,HEAD->Branch->Commitは当然の結果である.