170

私はこれを理解することはできません。私はウェブや本でたくさん読んでいて、何かが頭の中にとどまっていないだけです。誰かが私に次のダミーバージョンを教えてもらえますか？

  • git fetch vs pull
  • gitマージとリベース
4

4 に答える 4

439

フェッチとプル

fetchリモート* ブランチから変更をダウンロードし、リポジトリ データを更新しますが、ローカル* ブランチは変更しません。

pullfetchさらにmerge、ローカルブランチへの変更を実行します。

違いは何ですか？ pullプルされたブランチからの変更でローカル ブランチを更新します。Afetchはあなたのローカル ブランチを進めません。

マージとリベース

以下の歴史を考えると：

          C---D---Eローカル
         /
    A---B---F---Gリモート

merge2 つの開発履歴を結合します。これは、ローカル ブランチがリモート ブランチ上で分岐した後にローカル ブランチで発生した変更を再生し、その結果を新しいコミットに記録することによって行われます。この操作により、各コミットの祖先が保持されます。

a の効果は次のmergeようになります。

          C---D---Eローカル
         / \
    A---B---F---G---Hリモート

rebaseローカル ブランチに存在するコミットを受け取り、それらをリモート ブランチの上に再適用します。この操作は、ローカル コミットの先祖を書き換えます。

a の効果は次のrebaseようになります。

                  C'--D'--E' ローカル
                 /
    A---B---F---Gリモート

違いは何ですか？Amergeはコミットの祖先を変更しません。Arebase は、ローカル コミットの祖先を書き換えます。

*この説明は、現在のブランチがローカル ブランチであり、fetch、pull、merge、またはの引数として指定されたブランチrebaseがリモート ブランチであることを前提としています。これは通常のケースです。pullたとえば、指定されたブランチから変更をダウンロードし、リポジトリとmerge変更を現在のブランチに更新します。

于 2013-02-15T13:14:49.153 に答える
29

フェッチとプル

Git fetch はリポジトリ データを更新するだけですが、git pull は基本的にフェッチを実行し、プルされたブランチをマージします

「git pull」と「git fetch」の違いは何ですか?

マージとリベース

Atlassian SourceTree ブログ、Merge または Rebaseから:

マージは、各コミット履歴の祖先を保持しながら、2 つの開発ラインをまとめます。

対照的に、リベースは、ソース ブランチからの変更を書き直して、宛先ブランチの子として表示されるようにすることで、開発のラインを統一します。

また、 HackerNews (投稿へのリンク) に投稿されたばかりの素敵なゲームであるLearn Git Branchingをチェックして、多くの分岐とマージのトリックを教えてください。私はそれがこの問題で非常に役立つと信じています.

于 2013-02-15T12:38:12.580 に答える
11

プルvsフェッチ：

私がこれを理解する方法は、それgit pullは単に後にgit fetch続くということgit mergeです。つまり、リモートブランチから変更をフェッチしてから、現在のブランチにマージします。

マージvsリベース：

コマンドが言うように、マージは実行されます。現在のブランチと指定されたブランチの違いを（現在のブランチに）マージします。つまり、コマンドは現在のブランチgit merge another_branchにマージされます。another_branch

リベースの動作は少し異なり、ちょっとクールです。コマンドを実行するとしますgit rebase another_branch。Gitはまず、現在のブランチとの間の最新の共通バージョンを見つけますanother_branch。つまり、枝が分岐する前のポイントです。次に、gitはこの分岐点をの先頭に移動しanother_branchます。最後に、元の分岐点以降の現在のブランチのすべてのコミットが、新しい分岐点から再生されます。これにより、ブランチとマージが少なくなり、非常にクリーンな履歴が作成されます。

ただし、落とし穴がないわけではありません。バージョン履歴は「書き換えられている」ため、コミットがローカルのgitリポジトリにのみ存在する場合にのみこれを行う必要があります。つまり、コミットをリモートリポジトリにプッシュした場合は、これを行わないでください。

このオンラインブックでのリベースの説明は非常によく、わかりやすいイラストが付いています。

マージではなくリベースでプル

私は実際にリベースをかなり頻繁に使用していますが、通常はプルと組み合わせています。

git pull --rebase

リモートの変更をフェッチしてから、マージする代わりにリベースします。つまり、最後にプルを実行したときからのすべてのローカルコミットが再生されます。これは、マージで通常のプルを実行するよりもはるかにクリーンであることがわかります。これにより、マージで余分なコミットが作成されます。

于 2013-02-15T13:17:09.837 に答える
0

Merge - HEAD branch will generate a new commit, preserving the ancestry of each commit history. History can become polluted if merge commits are made by multiple people who work on the same branch in parallel.

Rebase - Re-writes the changes of one branch onto another without creating a new commit. The code history is simplified, linear and readable but it doesn't work with pull requests, because you can't see what minor changes someone made.

I would use git merge when dealing with feature-based workflow or if I am not familiar with rebase. But, if I want a more a clean, linear history then git rebase is more appropriate. For more details be sure to check out this merge or rebase article.

于 2018-05-31T09:31:45.057 に答える