Gitマージは「すでに最新」と報告しますが、違いがあります
マスターとテストの2つのブランチを持つgitリポジトリがあります。
マスターブランチとテストブランチには違いがあります。
両方のブランチにすべての変更がコミットされています。
私が行った場合：
git checkout master
git diffテスト
違いを示す変更でいっぱいの画面が表示されます。テストブランチの変更をマージしたいので、そうします：
git mergeテスト
しかし、「すでに最新です」というメッセージを受け取ります
ただし、異なるブランチごとにファイルを調べると、明らかに違いがわかります。
ここでの問題は何ですか？どうすれば解決できますか？
「既に最新」というメッセージは、マージしようとしているブランチからのすべての変更が、現在使用しているブランチに既にマージされていることを意味します。具体的には、マージしようとしているブランチ現在のブランチの親を意味します。おめでとうございます、これがあなたがこれまでに行う最も簡単なマージです。 :)
gitkを使用して、リポジトリを確認します。 「テスト」ブランチのラベルは、「マスター」ブランチのラベルのどこかにあるはずです。
ブランチは、その親に関して最新です。マージによると、最後のマージ以降、親に新しい変更はありません。これは、ブランチが同じであるという意味ではありません。作業中のブランチに多くの変更を加えることができ、そのように聞こえます。
これは、リモートマスターに変更があることがわかっているときによく起こります。そのため、git merge masterを使用してそれらをマージしようとします。ただし、これはリモートマスターとはマージされず、ローカルマスターとマージされます。
したがって、マージを実行する前に、マスターをチェックアウトしてから、そこにgit pullを追加します。その後、新しい変更をブランチにマージできます。
次のコミット履歴を持つブランチmasterがあるとします：
A -- B -- C -- Dここで、ブランチテストを作成し、それに取り組み、4つのコミットを実行します。
E -- F -- G -- H
/
A -- B -- C -- D
masterの頭はDを指し、testの頭はHを指します。
マージしているブランチのHEADがマージしたいブランチのコミットのチェーンの親である場合、「Already-to-date」メッセージが表示されます。その場合は次のとおりです。DはEの親です。
testからmasterに変更するものは何もないので、masterからmasterにマージするものはありません。ここでやりたいことは、文字通りresetの頭がHを指すようにGitに伝えることです。そのため、マスターのブランチには次のコミット履歴があります。
A -- B -- C -- D -- E -- F -- G -- Hこれは、Gitコマンド[VARIABLE]のジョブです。また、作業ディレクトリにこの変更を反映させるため、hardリセットを実行します。
git reset --hard H私にとってうまくいくのは、あなたがbranch1を持っていて、それをbranch2にマージしたいとしましょう。
Gitコマンドラインを開いてbranch2のルートフォルダーに移動し、次のように入力します。
git checkout branch1
git pull branch1
git checkout branch2
git merge branch1
git Push
競合がある場合は、git Pushを実行する必要はありませんが、最初にconflitsを解決してからPushを実行します。
マージは常に、現在のHEADと1つ以上のコミット（通常、ブランチヘッドまたはタグ）の間で行われます。
およびインデックスファイルは、開始時にHEAD commit（つまり、最後のコミットの内容）のツリーと一致する必要があります。
つまり、git diff --cached HEADは変更を報告してはなりません。マージされたコミットはすでに
HEADに含まれています。これは、「すでに最新」と呼ばれる最も単純なケースです。
これは、テスト中のコミットがすでにマスターにマージされていることを意味するはずですが、他のコミットはマスター上で行われるため、git diff testはまだいくつかの違いをもたらします。
これは、マージするブランチのローカルコピーが古いために発生します。 MyBranchという名前のブランチがあり、それをProjectMasterにマージしたいと思います。
_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'Origin/MyBranch-Issue2'.
nothing to commit, working tree clean
_>git merge ProjectMaster
Already up-to-date.
しかし私は知っているマージする必要がある変更があること！
git merge ProjectMasterと入力すると、gitはこのブランチのローカルコピー、現在ではない可能性がありますを確認します。これに該当するかどうかを確認するには、まずGitに、ブランチが古くなっているかどうかを確認して確認し、そうであれば、fetchを使用して変更をフェッチするよう指示します。次に、マージするブランチに移動して、そこで何が起こっているのかを確認します...
_>git fetch Origin
_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'Origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
(use "git pull" to update your local branch)
ああ！私のローカルコピーは85のコミットによって古くなっています。ここで、不足している変更をPullダウンし、MyBranchにホップして、マージを再試行します。
_>git pull
Updating 669f825..5b49912
Fast-forward
_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'Origin/MyBranch-Issue2'.
_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1
Automatic merge failed; fix conflicts and then commit the result.
そして今、私は修正する別の問題があります...
奇妙なことに、GITはローカルブランチはリモートブランチとは異なると考えていたため、これは私に起こりました。これはブランチグラフに表示されていました。2つの異なるブランチremotes/Origin/branch_nameとbranch_nameが表示されていました。
解決策は、単にローカルリポジトリを削除し、リモートから複製することでした。これにより、GITはremotes/Origin/branch_name>とbranch_nameが実際に同じであることを理解し、git merge branch_nameを発行できます。
rm <my_repo>
git clone <my_repo>
cd <my_repo>
git checkout <branch_name>
git pull
git checkout master
git merge <branch_name>
私に起こって、このページに送られました。同じシナリオがあるかどうかはわかりませんが、私の「テスト」ブランチを「再マージ」しようとしていたのです。
そのため、以前にマージしましたが、そのマージ中に特定の変更を意図的に除外しているため、ブランチ間に明らかに違いがあります。私はそれを再マージしようとしましたが、それは以前に除外した特定の変更/ファイルを追加する必要があることを認識/忘れており、以前に除外したすべての変更が再びマージを行うと表示されることを望んでいました、しかし間違っていて、代わりに「Already-to-date」メッセージが表示されます。
@Bombeのコメント/回答を読んで、彼は正しいです、そしてgit私はそのように振る舞うと思うので、私はテストブランチ上のファイルのハードバックアップを作成し、マスターブランチをチェックアウトして手動でファイルを貼り付けてコミットしましたあたかもそれが新しい変更であるかのように。
これが正しい方法であるか、この同じ問題を抱えている他の人を助けることができるかどうかはわかりませんが、それは私の特定のケースの解決策を提供しました。
git merge Origin/master代わりにgit merge masterが機能しました。マスターを機能ブランチにマージするには、次を使用できます。
git checkout feature_branch
git merge Origin/master
Git Bashを使用してこのシナリオに直面しました。
リポジトリには複数のブランチがあり、各ブランチには異なるコミットサイクルがあり、マージは時々発生します。 Old_BranchはNew_Branchの親として使用されました
Old_Branchは、New_Branchとのマージが必要ないくつかの変更で更新されました
ブランチなしで以下のpullコマンドを使用して、すべてのブランチからすべてのソースを取得していました。
git pull Origin
奇妙なことに、これはすべてのブランチからすべてのコミットをプルするわけではありません。示されているようにほぼすべてのブランチとタグを示しているように考えていた。
これを修正するために、Old_Branchが最新の
git checkout Old_Branch
git pull Origin Old_Branch
New_Branchをチェックアウトしました
git checkout New_Branch
確実に引っ張った
git pull Origin New_Branch
git merge Old_Branch
そして、ヴィオラはOld_BranchからNew_Branchに修正するために競合を起こしました:)
ブランチAをブランチBにマージすると、「すでに最新」と報告された場合、逆は必ずしも当てはまりません。ブランチBがブランチAの子孫である場合にのみ当てはまります。そうでない場合、ブランチBはAにない変更を単に持つことができます。
例：
- マスターからブランチAとBを作成します
- Masterでいくつかの変更を行い、これらの変更をブランチBにのみマージします（ブランチAの更新や更新の忘れは行いません）。
- ブランチAでいくつかの変更を行い、AをBにマージします。
この時点で、AをBにマージすると「すでに最新」と報告されますが、ブランチBにはマスターからの更新があり、ブランチAにはないため、ブランチは異なります。
最初にマージするブランチをチェックアウトしてからプルしてください（ローカルバージョンがリモートバージョンと一致するように）。
次に、マージを実行するブランチにチェックアウトして、git mergeが機能するはずです。
同じことが私にも起こりました。しかし、シナリオは少し異なり、マスターブランチがあり、release_1（たとえば）を作成しました。 release_1ブランチにいくつかの変更を加え、Originにマージしました。それからsshを実行し、リモートサーバーでコマンドgit checkout -b release_1を使用してrelease_1を再度チェックアウトします。これにより、実際に新しいブランチrelease_が作成されます。 Originから既存のブランチrelease_1をチェックアウトするのではなく、マスターから。 「-b」スイッチを削除して問題を解決しました
同じ問題がありました。リモコンに変更がありましたが、「すでに最新」と表示されていました。リポジトリを再クローンすることで問題が解決しました。