차이가 있지만 Git merge에서“이미 최신”보고

차이가 있지만 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가 병합하려는 지점의 커밋 체인의 상위 항목 인 경우 "이미 최신"메시지가 표시됩니다. 그렇습니다. 여기는 D의 부모입니다 E.

에서 병합에 아무것도 없습니다 test로는 master아무것도에 변경되지 않았기 때문에, master그 이후. 여기서 당신이하고 싶은 것은 문자 그대로 Git master에게 H를 가리 키도록 지시하는 것이므로 마스터의 지점에는 다음과 같은 커밋 기록이 있습니다.

A -- B -- C -- D -- E -- F -- G -- H

이것은 Git 명령의 작업입니다 reset. 작업 디렉토리에이 변경 사항이 반영되기를 원하므로 하드 리셋을 수행해야합니다 .

git reset --hard H

---

나를 위해 작동하는 것은 branch1이 있고 branch2에 병합하고 싶다고 가정 해 봅시다.

git 명령 줄을 열고 branch2의 루트 폴더로 이동하여 다음을 입력하십시오.

git checkout branch1
git pull branch1
git checkout branch2
git merge branch1
git push

충돌이있는 경우 git push를 수행 할 필요는 없지만 먼저 충돌을 해결 한 다음 푸시하십시오.

---

병합은 항상 현재 HEAD와 하나 이상의 커밋 (일반적으로 분기 헤드 또는 태그) 사이에
있으며 인덱스 파일은 시작할 때 HEAD 커밋 트리 (즉, 마지막 커밋의 내용)와 일치해야합니다.
즉, 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 ProjectMastergit 은이 분기의 로컬 사본을 확인합니다 . 현재가 아닐 수도 있습니다 . 이것이 사실인지 확인하기 위해 먼저 Git에게 분기가 오래되었는지 확인하고 uh,를 사용하여 변경 사항을 가져 오도록 지시 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는 로컬 지점이 원격 지점과 다르다고 생각했기 때문에 이런 일이 일어났습니다. 이것은 분기 그래프에서 볼 수 있습니다. 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>

---

같은 시나리오가 있는지 확실하지 않지만이 "테스트"브랜치를 "다시 병합"하려고했습니다.

그래서 이전에 병합했지만 병합 중에 일부 특정 변경 사항을 의도적으로 제외하므로 분 기간에 분명히 차이가 있습니다. 그런 다음 이전에 제외 한 특정 변경 / 파일을 추가하고 싶다는 것을 알고 잊어 버리기 때문에 다시 병합하려고했습니다. 병합을 다시 수행하면 이전에 제외 된 모든 변경 내용이 표시되기를 바랐습니다. , 그러나 나는 틀렸고 대신 "이미 최신"메시지가 대신 나타납니다.

@ Bonbe의 의견 / 답변을 읽었을 때, 그는 맞습니다 .git은 그렇게 행동한다고 ​​생각합니다. 그래서 테스트 브랜치에서 파일을 하드 백업 한 다음 마스터 브랜치를 체크 아웃하고 수동으로 파일을 붙여 넣고 커밋하는 것이 었습니다 마치 새로운 변화 인 것처럼 말입니다.

이것이 올바른 방법인지 확실하지 않거나 다른 사람들 이이 같은 문제를 겪을 수 있도록 도울 수는 있지만 내 특정 사례에 대한 해결책을 제공했습니다.

---

git merge origin/master대신 git merge master나를 위해 일했습니다. 따라서 마스터를 기능 분기로 병합하려면 다음을 사용할 수 있습니다.

git checkout feature_branch
git merge origin/master

---

병합하려는 지점을 먼저 체크 아웃 한 다음 당겨서 로컬 버전이 원격 버전과 일치하는지 확인하십시오.

그런 다음 병합하려는 분기로 다시 체크 아웃하면 git merge가 작동합니다.

---

분기 A를 분기 B에 병합하면 "이미 최신 상태"라고보고되는 ​​경우 항상 반대가 아닙니다. 분기 B가 분기 A의 후손 인 경우에만 해당되며 그렇지 않으면 분기 B는 단순히 A에없는 변경 사항을 가질 수 있습니다.

예:

1. 마스터 A에서 B 지점을 생성합니다
2. 마스터에서 일부 변경을 수행하고 이러한 변경을 분기 B에만 병합합니다 (분기 A를 업데이트하거나 업데이트하지 않는 것).
3. 분기 A에서 일부를 변경하고 A를 B로 병합합니다.

이 시점에서 A에서 B로 병합하면 "이미 최신 상태"로보고되지만 분기 B는 마스터의 업데이트가 있고 분기 A는 그렇지 않으므로 분기가 다릅니다.

---

Git Bash를 사용하여이 시나리오에 직면했습니다.

우리 저장소에는 여러 개의 브랜치가 있으며 각 브랜치는 다른 커밋주기를 가지며 병합은 가끔씩 발생합니다. Old_Branch는 New_Branch의 부모로 사용되었습니다.

Old_Branch는 New_Branch와 병합해야하는 일부 변경 사항으로 업데이트되었습니다.

모든 분기에서 모든 소스를 가져 오기 위해 분기없이 pull 명령을 사용하고있었습니다.

자식 풀 원점

이상하게도 모든 분기에서 모든 커밋을 가져 오는 것은 아닙니다. 표시된 거의 모든 지점과 태그를 표시하는 것으로 생각했습니다.

그래서이 문제를 해결하기 위해 Old_Branch가

git checkout Old_Branch

자식 풀 원점 Old_Branch

이제 New_Branch를 확인했습니다

git checkout New_Branch

확실하게 당겨

git pull origin New_ 브랜치

자식 병합 Old_Branch

그리고 viola는 Old_Branch에서 New_Branch로 수정해야 할 충돌을 얻었습니다.

---

나도 마찬가지였다. 그러나 시나리오는 약간 달랐고 마스터 지점이 있었고 release_1 (예 :)을 조각했습니다. release_1 브랜치를 약간 변경하여 원점으로 병합했습니다. 그런 다음 ssh를하고 원격 서버에서 git checkout -b release_1 명령을 사용하여 release_1을 다시 체크 아웃합니다. 실제로 새로운 분기 release_! 원점에서 이미 존재하는 브랜치 release_1을 체크 아웃하는 대신 마스터에서. "-b"스위치를 제거하여 문제 해결

---

나는 같은 문제가 있었다. 리모컨에 변경 사항이 있는데 여전히 "이미 최신"으로 표시되었습니다. 저장소를 다시 복제하면 문제가 해결되었습니다.

참고 URL : https://stackoverflow.com/questions/634546/git-merge-reports-already-up-to-date-though-there-is-a-difference