git merge、git rebase、git restart、git revert、git fetch、git pull、git reflog... これらの git コマンドがどのようなタスクを実行するかご存知ですか?まだ混乱している場合は、この記事をお見逃しなく。この記事では、JavaScript、TypeScript、GraphQL、サーバーレス、AWS、Docker、Golang に精通した 21 歳のソフトウェア コンサルタントである Lydia Hallie が、これらの一般的に使用される git コマンドの作業プロセスをアニメーションの形式で直感的に紹介します。決して忘れないようにします。
Git は非常に強力なツールですが、Git を使うのは悪夢だと私が言うと、ほとんどの人も私の意見に同意するでしょう。声明。 Git を使って作業するときに、それを頭の中で視覚化すると非常に役立ちます。特定のコマンドを実行すると、これらのブランチがどのように相互作用し、履歴にどのような影響を与えるか?私がマスターでハードリブートを実行し、元のブランチに強制プッシュし、.git フォルダーをリムラフすると、同僚が泣くのはなぜですか? 最も一般的に使用され、便利な Git コマンドのいくつかの視覚的な例を作成することは、完璧なユースケースだと思いました。以下で説明するコマンドの多くにはオプションのパラメータがあります。これらのパラメータを使用して、対応するコマンドの動作を変更できます。また、私の例ではコマンドのデフォルトの動作のみを取り上げており、オプションの構成は追加しません (または過剰に追加しません)。 ##複数のブランチがあると非常に便利ですこれにより、さまざまな新しい変更が相互に分離され、承認されていないコード変更や破損したコード変更が誤って運用コードにプッシュされることがなくなります。ただし、これらの変更が承認されたら、本番ブランチにデプロイする必要があります。
あるブランチから別のブランチに変更を組み込む 1 つの方法は、git merge を実行することです。 Git は、早送りと非早送りという 2 種類のマージを実行できます。今は違いがわからないかもしれませんが、すぐに違いを見てみましょう。
早送りマージは、現在のブランチにマージしたいブランチと比較して追加のコミットがない場合に実行できます。 Git は怠惰なので、最初に最も単純なオプションである早送りを試します。このタイプのマージでは、新しいコミットは作成されませんが、マージしているブランチ上のコミットが現在のブランチに直接マージされます。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃完璧！これで、dev ブランチで行ったすべての変更が master ブランチにマージされます。では、早送り禁止とはどういう意味でしょうか? ##マージ先のブランチと比較して現在のブランチにコミットがなければ良いのですが、残念ながらそのようなことはほとんどありません。マージしたいブランチにない変更を現在のブランチにコミットすると、git は非早送りマージを実行します。 no-fast-forward を使用してマージする場合、Git は現在アクティブなブランチに新しいマージ コミットを作成します。このコミットの親コミットは、このアクティブなブランチをポイントしており、マージしたいブランチもポイントしています。 #
大したことはありません。完璧にマージできます。これで、dev ブランチで行ったすべての変更が master ブランチにマージされます。 ただしGit は、ブランチをマージしてファイルに変更を追加する方法を決定するのが非常に得意ですが、常に完全に単独で決定を下すわけではありません。マージしたい 2 つのブランチが、同じファイル内の同じコード行に異なる変更を加えている場合、または一方のブランチがファイルを削除し、もう一方のブランチがファイルを変更している場合、Git は何を選択すればよいかわかりません。 この場合、Git はどのオプションを保持するかを尋ねます。両方のブランチで README.md の最初の行を編集すると仮定します。 dev を master にマージしたい場合、マージ競合が発生します。タイトルは次のとおりです。こんにちは! または Hey!?
これらのブランチをマージしようとすると、Git は競合が発生している場所を表示します。保持したくない変更を手動で削除し、変更を保存し、変更したファイルを再度追加して、変更をコミットできます。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃仕上げる！マージ競合は煩わしいことが多いですが、これには意味があります。Git は、どの変更を保持したいかを推測する必要がありません。 先ほど確認しました。変更を適用できますgit merge を実行して、あるブランチから別のブランチに移動します。あるブランチから別のブランチに変更を組み込むもう 1 つの方法は、git rebase を実行することです。 git rebase は、現在のブランチのコミットを指定されたブランチにコピーします。 完璧です。これで、dev ブランチの master ブランチにすべての変更が反映されました。 リベースとマージには大きな違いが 1 つあります。それは、Git はどのファイルを保持するかどうかを判断しようとしないことです。リベースするブランチには、保持したい最新の変更が常に含まれています。こうすることで、マージ競合が発生せず、良好で直線的な Git 履歴が維持されます。 上記の例は、master ブランチでのリベースを示しています。ただし、大規模なプロジェクトでは、通常、これを行う必要はありません。 git rebase は、コピーされたコミットの新しいハッシュを作成するときにプロジェクトの履歴を変更します。 feature ブランチを開発していて、master ブランチが更新されている場合は、リベースが便利です。ブランチ上のすべての更新を取得できるため、将来のマージ競合を防ぐことができます。 ## 実行する前にこれらを変更できます。コミットのためにリベースしてください!インタラクティブなリベースを使用して、このタスクを実行できます。対話型リベースは、現在開発中のブランチ上で特定のコミットを変更する場合に便利です。
リベースしているコミットでは、次の 6 つのアクションを実行できます:
- reword: 提出情報を変更します;
- edit: この提出を変更します;
squash: 提出物を前の提出物にマージします。
fixup: 提出物を前の提出物にマージします。そのコミットのログ メッセージを保持しません;
exec: 各コミットでリベースするコマンドを実行します;
-
drop: コミットを削除します。
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃素晴らしい！これにより、コミットを完全に制御できるようになります。コミットを削除したい場合は、ドロップするだけです。
#複数のコミットをマージして取得する場合明確なコミット履歴があれば問題ありません。
インタラクティブなリベースを使用すると、現在アクティブなブランチ上であっても、リベース時にさまざまな制御が可能になります。
以前に送信された変更が不要な場合は、このコマンドを使用します。 。おそらくこれは WIP コミットであるか、バグを導入したコミットである可能性があります。その場合は git リセットを実行する必要があります。
git reset を使用すると、現在のデスクトップ上のファイルを使用できなくなり、HEAD が指す場所を制御できるようになります。
#ソフト リセット
ソフト リセットは、HEAD を指定されたコミットに移動します (またはコミットの HEAD インデックスと比較します) ）そのコミット後に追加された変更を削除せずに！
style.css ファイルを追加するコミット 9e78i と、index.js ファイルを追加するコミット 035cc を保持したくないとします。ただし、新しく追加された style.css ファイルとindex.js ファイルは保持しておきたいと考えています。これはソフト リセットに最適な使用例です。
#
git status に入ると、以前のコミットで行われたすべての変更に引き続きアクセスできることがわかります。これは素晴らしいことです。これは、これらのファイルの内容を修正して、後で再送信できることを意味します。
##ハード リセット
ハード リセットをしたくない場合もあります特定のコミットによって導入された変更を保存します。ソフト リセットとは異なり、それらに再度アクセスする必要はありません。 Git は全体の状態を特定のコミット前の状態に単純にリセットする必要があります。これには、作業ディレクトリやステージング ファイルに加えた変更も含まれます。
#
Git は 9e78i および 035cc によって導入された変更を破棄し、状態を ec5be の状態にリセットしました。
変更を元に戻すもう 1 つの方法は、git revert を実行することです。特定のコミットに対して元に戻す操作を実行すると、元に戻された変更を含む新しいコミットが作成されます。
ec5be がindex.js ファイルを追加するとします。しかしその後、このコミットによって導入された変更はもう必要ないことがわかりました。次に、ec5be の送信を復元してください。
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃完璧！ commit 9e78i は、 commit ec5be によって導入された変更を元に戻します。 git revert は、ブランチの履歴を変更せずに特定のコミットを元に戻す場合に便利です。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃さくらんぼ狩り＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ ＃＃＃＃ 特定のブランチに、アクティブなブランチが必要とする特定のコミットが含まれている場合、そのコミットに対してチェリーピックを実行します。コミットをチェリーピックすると、選択されたコミットによって導入された変更を含む新しいコミットがアクティブなブランチに作成されます。 
dev ブランチのコミット 76d12 により、index.js ファイルに変更が追加され、それを master ブランチに統合するとします。 dev ブランチ全体が必要ではなく、このコミットだけが必要です。 master ブランチには、76d12 で導入された変更が含まれています。
#
GitHub 上のブランチなど、リモート Git ブランチがある場合は、現在のブランチにないコミットがリモート ブランチに含まれている場合に取得を使用できます。別のブランチがマージされたときや、同僚がクイックフィックスをプッシュしたときなどです。
このリモート ブランチで git fetch を実行すると、これらの変更をローカルで取得できます。これはローカル ブランチにはまったく影響しません。fetch は単に新しいデータをダウンロードするだけです。
#これで、前回のすべての変更以降のことがわかります。プッシュが含まれているため。新しいデータはローカルに保存され、それをどう扱うかを決めることができます。
git fetch を使用してリモート情報を取得することもできますが、特定のブランチに対してですが、git pull を実行することもできます。 git pull は実際には、git fetch と git merge という 2 つのコマンドが 1 つに結合されたものです。ソースから変更をプルするときは、まず git fetch のようにすべてのデータを取得し、次に最新の変更が自動的にローカル ブランチにマージされます。
素晴らしいです。現在、リモート ブランチと完全に同期しており、最新の変更がすべて反映されています。
誰もが間違いを犯しますが、間違いをしても大丈夫です。場合によっては、Git リポジトリが完全に破損しているように感じて、完全に削除したくなることがあります。
git reflog は、実行されたすべてのアクションのログを表示できる非常に便利なコマンドです。これには、マージ、リセット、元に戻す、基本的にブランチに加えたすべての変更が含まれます。
#間違った場合は、reflog によって提供される情報に基づいて HEAD をリセットすることで簡単にやり直すことができます。 ！
実際に元のブランチをマージする必要がないと仮定します。 git reflog コマンドを実行すると、マージ前はこのリポジトリのステータスが HEAD@{1} であったことがわかります。次に、git restart を実行し、HEAD を HEAD@{1} の場所にリダイレクトします。
#最新のアクションは次のとおりであることがわかります。 reflog にプッシュされました。 以上が数十のアニメーション画像で Git の仕組みを説明しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
