git-rebase と git-merge は何をしますか?違いは何ですか?

git-rebase と git-merge は何をしますか? git-rebase と git-merge の違いは何ですか? git-rebaseとgit-mergeの違いについては以下の記事で紹介していますので、ご参考になれば幸いです。

バージョン管理に Git を使用することは、ほとんどのエンジニアが毎日遭遇するワークフローの 1 つであるはずですが、私が使用しているのは push, # にすぎません。 ##pull、merge、checkout または log およびその他の指示。さらに詳しく調べると、それについては何もわかりません。インタビュー中に次の質問がされました: 「Git のマージとリベースの違いを知っていますか?」

私はそれを聞いてすぐに混乱しました。私にとって、リベースはコミットを整理するために使用されるツールであり、実際に機能します。マージと比較しますか? [推奨学習: "

Git チュートリアル "]

git-rebase

まず、私が普段 rebase コマンドを使用する目的について話します。新しい単体テストを追加して

commit を実行すると、log には commit:

## という追加のレコードが含まれます。

##しかし、コミット後に別のテストケースを書き忘れていたことが判明したので、それを補って再度コミットしました。

# この時点では、レコードには別の commit

がありますが、私にとって、これら 2 つの

commit は実際には同じことを行っているため、リモートにプッシュする前に、最初にコミットを整理する必要があります。そして 2 つのレコードをマージします。 これら 2 つのレコードをマージするには 2 つの方法があります。1 つ目は、最初のテスト ケースを追加する前に reset

し、その後直接

commit を実行することです。 2 番目の方法は、rebase を使用してこれを処理することです。 まず現在のログを見てみましょう:

私の目的は、9dc67ff

と

87af945# を結合することです。 ## 1 つに編成されるため、調整されるコミットは init からのもの、つまりコミット ID が 7eb57cb 以降のすべてのコミットです。rebase コマンドと組み合わせると、次のようになります: <pre class="brush:php;toolbar:false">git rebase -i 7eb57cb</pre> 入力後、vim 編集画面にジャンプします:

7eb57cb 以降のすべてのコミットが表示されます。 (現在は

9dc67ff

と 87af945 のみ)、次に 9dc67ff の pick を squash に変更します。これはマージを意味します。それを前のコミットと一緒にします。まず i をクリックしてから、vim でコンテンツの編集を開始します。

編集後、esc をクリックして

:wq と入力して保存できます。興味があるだけなので、Play にアクセスして見てください。保存したくない場合は、「

:q!

」と入力してください。上記の処理が完了した後、再度ログを確認すると、2 つのコミットが 1 つになっていることがわかります。保存後、コミットメッセージ画面にジャンプします。ここでマージされたコミットメッセージを入力できますが、変更せずに直接保存します。プロセスを確認し、ログを再度確認すると、2 つのコミットが 1 つになっていることがわかります。

まず、上記の操作は、git rebase のリベースの対話モードです。後で入力した -i は、実際には

interactive の省略形です。

git-merge

新しい機能を実行するときは、通常、ブランチを取り出してから

merge# するため、誰もがマージ コマンドに精通している必要があります。 ## masterやdevelopなどのメインブランチに戻ります。操作プロセスは次のとおりです。

在 merge 的时候会有两种情况，第一种是  fast-forward，会把被合并分支的 HEAD 的 reference 移到要合併分支内最新的 commit 上，上方操作的 merge 结果就是 fast-forward，master 的 HEAD 被移到 string-library 的最新 commit，画成图的话就是这样子：

但是如果在执行 merge 的时候产生冲突，那分支的合并行为就会和 fast-forward 有点不同了。举例来说，我分别在 master 和 string-library 的同一个文件添加内容，那当我执行 merge 的时候就会要求先修复冲突：

修复完后，再执行 commit 完成合并，而这一次合并时，会再多一个 commit 是有关 merge 了 string-library 分支的纪录：

这个情况画成图就会像这样子：

git-rebase 与 git-merge 的差异

看完上方对 rebase 和 merge 的介绍后，你也许会想说：

「咦？那这两个不是完全不同的东西吗？」

对的，原本我也是这麽认为，一直到我去看了 git-rebase 的文档，才发现原来我一直误会它了。在 git book 的 rebase 篇章，第一段就说明了，在 Git 里有两种方法可以用来整合两个分支，而这两个在上方都有提到，分别为 merge 和 rebase：

从上方的 merge 例子已经知道了，merge 在合并的时候会有 fast-forward，和冲突时用一个 commit 记录合并变更的两种情形。而 rebase 的整合方式非常有趣，依照关于 rebase 的另一段说明，它可以「把某个分支中所有 commit 的过程，以另一个分支的 commit 为基础重播一遍」：

这是什麽意思呢？首先让我们回到上述的例子，并在 master 分支上用 reset，让 master 的版本回到合并 string-library 之前：

现在我们要用 rebase 指令，将 string-library 所有的 commit 修改，以 master 的 commit 为基础跑一次。使用 rebase 合并的第一步，要先切到想重播 commit 的分支：

git checkout string-library

然后再输入 git rebase 指令，并于后方指定要在哪个分支上重播：

git rebase master

执行结果：

在 rebase 重播 commit 的过程中，和 merge 相似的地方在于，如果有冲突的话还是需要解决，但在解决后，并不是使用 commit 指令进行合并，而是要输入 git rebase --continue，让 rebase 可以继续重播接下来的 commit：

重播完成时，会显示目前重播到哪个 commit，以 string-library 来说就是最新的add string unit test D。这时候的分支关系，画成图就会变成：

上图在经过 rebase 之后，string-library 里 07e38fb 修改，会以 master 的 commit 为基底再重播一次。

需要注意的是，重播后的 commit id 会和原本的不一样，这等于完全改写了分支内所有的 commit 历史纪录。

さらに、リベースの実行後、string-library は実際にはマスター ブランチにマージされて戻っていないため、マージを完了するにはマスターに切り替えてマージを実行する必要があります。

リベースは再生中のコミット競合の処理に使用されているため、マージは直接早送りマージに移行し、別のコミット レコードは存在しません。マージ。

git-rebase を使用してマージする利点と欠点

利点

• マージ中に冗長なコミットは生成されません。

• 競合は、再生中にコミット単位で処理できます。

• マージの際、ブランチのコミットに合わせて配置されるため、レビュー課題や機能の処理プロセスが明確に理解できます。マージを使用すると、マージ後に 2 つのブランチのコミットが時系列に並べられます。

• オープンソース プロジェクトに貢献する場合、プッシュする前にリベースすると、作成者は競合を個別に解決することなく、早送り方式で直接マージできます。

欠点

最大の欠点は上記の欠点です。リベースを使用するとコミットの履歴が変更されます。コミットやブランチをローカルで整理する場合は問題ありません。誤ってリモート ブランチを変更し、誤って git Push -f を使用した場合、同僚から嫌われるか、純粋に北方のエンジニアに提出される可能性があります。

git-rebase または git-merge を使用する必要がありますか?

いくつかの情報を確認したところ、リベースとマージの両方に独自の支持者がいることがわかりました。最初に彼らの考えを説明し、次に主観的に私自身の意見を述べます。

git-merge Pai

サポートgit-merge Pai のエンジニアは、バージョン レコードの価値はプロジェクトのコミットにあると信じています。つまり、"このプロジェクトの歴史の中で実際に何が起こったのか。これらの歴史的記録を変更すると、非常に悪いことになります。したがって、マージ後にさまざまなブランチの内容が混在しても、プロジェクトの歴史を示しています。

git-rebase 送信

supportgit-rebase 送信されたエンジニアは、コミットがプロジェクトの「進化プロセス」について話していると感じました。何が起こったのかが重要です。コミット履歴を変更しても、何が起こったのかは変わりません。より明確で簡潔な記録を使用して、将来の世代が読むことができるため、そうする必要があります。

個人的な主観的な意見

私は個人的に、履歴レコードをよりシンプルで読みやすくするためにコミットを変更するために今でも git-rebase を使用していますが、用途はプッシュに限定されています。リモート 以前は、今日レコードをリモートにプッシュしていたら、どんなに汚くても変更しませんでした。結局、リモートのレコードは全員で共有されていました。私が勝手に変更しなければ、他のメンバーを尊重するでしょう。チームの。

[関連ビデオチュートリアルの推奨事項: Web フロントエンド ]

以上がgit-rebase と git-merge は何をしますか?違いは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。