10

開始状況 (プッシュされていない変更はなく>、現在のブランチを示します):

o C [> master][origin/master]
|
o B
|
o A
|
...

git fetchログ構造の後、多くの場合、次のようになります

o E [origin/master]
|
o C'
|
o B'
|
o D
|
| o C [>master]
| |
| o B
|/
o A
|
...

今git rebase origin/master masterではしばしば衝突を引き起こします。git pull --rebaseよりスマートで、最初にif ==を指すようgit resetにするだけですか?masterEmasterorigin/master

4

3 に答える 3

18

マージの代わりにリベースを使用してプルできます。これが私のチームのやり方であり、非常にうまく機能しています。

「あなたが知らなかったいくつかのgitのヒント」から：

git のブランチ マージはマージ コミットで記録されるため、機能がいつリリース ブランチにマージされたかを示すなど、意味のあるものになるはずです。ただし、複数のチーム メンバーが 1 つのブランチを頻繁に同期する通常の毎日のワークフローでは、通常の git pull でタイムラインが不要なマイクロマージで汚染されます。リベースにより、コミットが常に再適用されるため、履歴が線形のままになります。

--rebase フラグを使用せずに、特定のブランチを常にこれを行うように構成できます。

#make 'git pull' on master always use rebase
$ git config branch.master.rebase true

グローバル オプションを設定して、すべての新しい追跡ブランチの最後のプロパティを設定することもできます。

# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always

于 2011-10-07T01:29:28.740 に答える
17

git pull --rebaseと同じではありませんgit fetch; git rebase。残念ながら、git-pullマニュアルページは違いについてかなり不可解です:

   --rebase
       Rebase the current branch on top of the upstream branch
       after fetching. If there is a remote-tracking branch
       corresponding to the upstream branch and the upstream branch
       was rebased since last fetched, the rebase uses that
       information to avoid rebasing non-local changes.

元の投稿者が推測したように、違いには関係がないことがわかりgit resetました。実際には、reflogが関係しています (その用語に遭遇したことがない場合は、こちらを参照してください)。

のエクストラ マジックに関する完全なストーリーについては、次のgit pull --rebase回答を参照してください。

https://stackoverflow.com/a/11531502/179332

于 2012-07-17T22:06:52.487 に答える
7

git pull --rebase次のようにします。

git fetch
git rebase

したがって、あなたの場合、次のようにリポジトリを離れます。

o C [> master]
|
o B
|
o E [origin/master]
|
o C'
|
o B'
|
o D
|
o A
|
...

originあなたが持っている2つのコミットは、コミットEの上に再作成された場所とは異なることに注意してください.

于 2011-05-02T18:53:56.393 に答える