マスターブランチと「オリジン/マスター」が分岐しました。ブランチを「分岐解除」するにはどうすればよいですか？

どういうわけか私のマスターと私のオリジン/マスターブランチは分岐しています。
実際に発散させたくありません。

これらの違いを表示して「マージ」するにはどうすればよいですか？

次の方法で違いを確認できます。

git log HEAD..origin/master

プルする前に（フェッチ+マージ）（「どのようにしてgitが常に特定のブランチからプルするようにするのですか？」も参照してください）

次のようなメッセージがある場合：

「あなたのブランチと 'origin / master'は分岐し、それぞれ＃と1つの異なるコミットを持っています。」

、更新originする必要があるかどうかを確認します。場合はorigin最新で、その後、いくつかのコミットはにプッシュされていoriginますが、ローカルで独自のコミットを作っている間、別のレポから。

... o ---- o ---- A ---- B  origin/master (upstream work)
                   \
                    C  master (your work)

コミットAに基づいてコミットCを作成しました。これは、当時アップストリームからフェッチした最新の作業だったからです。

ただし、元に戻そうとする前に、誰かがコミットBをプッシュしました。
開発履歴は別のパスに分岐しています。

その後、マージまたはリベースできます。詳細については、Pro Git：Git Branching-Rebasingを参照してください。

マージ

git mergeコマンドを使用します。

$ git merge origin/master

これは、Gitにからの変更をorigin/master作業に統合し、マージコミットを作成するように指示します。
履歴のグラフは次のようになります。

... o ---- o ---- A ---- B  origin/master (upstream work)
                   \      \
                    C ---- M  master (your work)

新しいマージであるコミットMには2つの親があり、それぞれがそのコミットに格納されているコンテンツにつながる開発の1つのパスを表しています。

Mの背後にある履歴が非線形になっていることに注意してください。

リベース

git rebaseコマンドを使用します。

$ git rebase origin/master

これは、A
ではなくコミットBに基づいているかのように、コミットC（作業）をリプレイするようにGitに指示します。CVSおよびSubversionユーザーは、コミット前に更新すると、アップストリーム作業に加えてローカルの変更を定期的にリベースします。
Gitは、コミットとリベースのステップの間に明確な分離を追加するだけです。

履歴のグラフは次のようになります。

... o ---- o ---- A ---- B  origin/master (upstream work)
                          \
                           C'  master (your work)

コミットC 'は、git rebaseコマンドによって作成された新しいコミットです。
2つの点でCとは異なります。

1. 履歴が異なります。AではなくBです。
2. その内容は、BとCの両方の変更を説明しています。マージの例のMと同じです。

C 'の背後にある歴史はまだ線形であることに注意してください。
（今のところ）では、線形履歴のみを許可するように選択していcmake.org/cmake.gitます。
このアプローチは、以前に使用されたCVSベースのワークフローを保持し、移行を容易にする可能性があります。
C 'をリポジトリーにプッシュする試みは機能します（ユーザーに権限があり、リベース中に誰もプッシュしなかった場合）。

git pullコマンドは、オリジンからフェッチしてローカル作業をリベースする簡単な方法を提供します。

$ git pull --rebase

これは、上記のフェッチとリベースの手順を1つのコマンドに結合します。

私はこれを持っていて、上記の応答を読んだ後でも、それを引き起こしている原因について不思議に思っています。私の解決策は

git reset --hard origin/master

次に、（リモートの）origin / masterで表されるように、マスターの（ローカルの）コピー（ねじ込まれていると思います）を正しいポイントにリセットします。

警告：にプッシュされていないすべての変更が失われorigin/masterます。

git pull --rebase origin/master 

ほとんどの場合に役立つ単一のコマンドです。

編集：オリジン/マスターからコミットをプルし、新しくプルされたブランチ履歴に変更を適用します。

私がしようとしたとき、私はこのような状況で自分自身を発見したリベースリモートブランチを追跡していた枝を、私はマスターでそれをリベースしようとしていました。このシナリオでは、リベースしようとすると、ブランチが分岐している可能性が高く、git nubees以外の混乱が発生する可能性があります。

マスターから分岐したmy_remote_tracking_branchブランチにいるとします。

$ git status

＃ブランチmy_remote_tracking_branch

コミットするものは何もありません（作業ディレクトリはクリーンです）

そして今、あなたはマスターから次のようにリベースしようとしています：

git rebase master

今すぐやめて、トラブルを解消してください！代わりに、次のようにマージを使用します。

gitマージマスター

はい、ブランチで余分なコミットが発生します。しかし、「分岐しない」ブランチを使用するのでない限り、これはリベースよりもはるかにスムーズなワークフローになります。詳細については、このブログを参照してください。

一方、ブランチが ローカルブランチ（つまり、リモートにまだプッシュされていない場合）、必ずリベースする必要があります（この場合、ブランチは分岐しません）。

あなたがすでにこれを読んでいるなら、あなたはすでに ようなリベースの「分岐」シナリオになっいる、次のコマンドを使用して、オリジンから最後のコミットに戻ることができます（分岐していない状態）。

git reset --hard origin / my_remote_tracking_branch

私の場合、ここに私が分岐したメッセージを引き起こすためにしたことです：私はしましたgit pushがgit commit --amend、コミットメッセージに何かを追加しました。それから私はまた別のコミットをしました。

したがって、私の場合、単にオリジン/マスターが古くなっていることを意味します。他の誰もオリジン/マスターに触れていないことを知っていたので、修正は簡単でした：（力git push -f は-f意味します）

私の場合、変更をプッシュしました origin/master、そうすべきではないことに気づきました:-(これは、ローカルの変更がサブツリーにあるという事実によって複雑になりました。 （SourceTreeを使用して）変更すると、「分岐メッセージ」が表示されました。

ローカルで混乱を修正した後（詳細はここでは重要ではありません）、リモートorigin/masterブランチを「過去にさかのぼって」、ローカルとmaster再び同期するようにしました。私の場合の解決策は：

git push origin master -f

-f（強制）スイッチに注意してください。これorigin/masterにより、誤ってプッシュされた「悪い変更」が削除され、ローカルブランチとリモートブランチが同期します。

これは破壊的な操作になる可能性があることに注意してください。リモートマスターを時間内に「戻す」ことが100％確実である場合にのみ実行してください。

私はここにたくさんの答えがあることを知っていますが、発散状態を解決する間git reset --soft HEAD~1、最後のローカル（プッシュされていない）コミットの変更を維持できるので、いくらかの注意に値すると思います。これはプルよりも用途が広いソリューションだと思いますrebaseローカルコミットを確認したり、別のブランチに移動したりできるため、。

キーは--soft厳しいのではなく、を使用してい--hardます。複数のコミットがある場合は、のバリエーションが機能するHEAD~xはずです。だからここに私の状況を解決したすべてのステップがあります（私はリモートで1つのローカルコミットと8つのコミットを持っていました）：

1） git reset --soft HEAD~1ローカルコミットを元に戻す。次の手順では、SourceTreeのインターフェイスを使用しましたが、次のコマンドも機能するはずです。

2） git stash 1）からの変更を隠しておきます。これで、すべての変更が安全になり、相違がなくなります。

3） git pullリモートの変更を取得します。

4） git stash popまたはgit stash apply、最後に隠された変更を適用し、必要に応じて新しいコミットを適用します。ローカルコミットで変更を破棄する場合、このステップは2）とともにオプションです。また、別のブランチにコミットする場合は、目的のブランチに切り替えてからこの手順を実行する必要があります。

違いを表示するには：

git difftool --dir-diff master origin/master

これにより、2つのブランチ間の変更または差異が表示されます。araxis（私のお気に入り）では、それをフォルダーのdiffスタイルで表示します。変更された各ファイルを表示しています。次に、ファイルをクリックして、ファイル内の変更の詳細を表示できます。

私の場合、これは私の紛争解決を行わなかったことが原因でした。

git pullコマンドの実行が原因で問題が発生しました。起点の変更により、ローカルリポジトリとの競合が発生しましたが、解決しました。しかし、私はそれらをコミットしませんでした。この時点での解決策は、変更をコミットすることです（git commitすることです解決されたファイル）

競合の解決後にいくつかのファイルも変更した場合、git statusコマンドはローカルの変更をステージングされていないローカルの変更として表示し、解決をステージングされたローカルの変更として表示します。これは、マージによる変更を最初にgit commitでコミットしてから、ステージングされていない変更を通常どおり（たとえばでgit commit -a）追加してコミットすることで、適切に解決できます。

最後のコミットメッセージを編集しようとしたときに、すでにプッシュされたコミットの同じメッセージが表示され ました。git commit --amend -m "New message" 使用して変更をプッシュしたところ、git push --force-with-lease repo_name branch_name問題はありませんでした。

私がブランチAに基づいてブランチを作成したときにこの問題に会った

git checkout -b a

それから私はブランチaの上流を元のブランチBに設定しました

git branch -u origin/B

次に、上記のエラーメッセージが表示されました。

この問題を解決する1つの方法は、

• ブランチを削除する
• 新しいブランチbを作成する

git checkout -b b origin/B