예를 들어 master
과 develop
라는 두 개의 브랜치가 있습니다. 1.txt
파일의 경우
master分支
:
222
3333 66
555
develop分支
:
222
4444 77
888
먼저 마스터가 있고 그 다음 개발 브랜치를 생성한 다음 개발 브랜치 아래에서 1.txt를 수정한 다음 추가하고 커밋한 다음 다시 마스터 브랜치로 전환한 다음 병합했는데 66개와 77개의 충돌만 보고되었습니다. 및 기타 두 장소 간에 충돌이 보고되지 않았습니다
66명과 77명만 있다면 왜 갈등이 생기겠습니까? 그리고 4444와 3333, 555와 888은 충돌하지 않나요? 이해가 안 돼요
위 사진을 보면 마스터 브랜치가 555555인데 5445에서 dev로 변경하고 커밋을 추가한 뒤 다시 마스터 브랜치로 전환해서 병합하고 충돌이 없어서 최종적으로 5445로 병합이 되네요. 뭐라고 했어?
커밋 수정 순서에 따라 충돌 발생 여부가 달라집니다.
위층의 내 친구가 자동 병합을 언급했는데, 이는 충돌이 없음을 의미합니다. 예:
인 커밋이 있습니다.위 마스터, 콘텐츠가 "1234"
이번에 라는 마스터
develop
를 기반으로 하는 새 브랜치를 만들었고 이develop
브랜치에도 "1234" 콘텐츠가 포함된 커밋이 있습니다그런 다음 새 커밋을 제출하고 "1234"를 "1234 666"으로 변경하면
merge
이때 충돌이 발생하지 않습니다갈등 상황의 또 다른 예:
콘텐츠가 포함된 첫 번째 커밋이 있습니다.master
내부에 커밋이 있고 내용은 "1234"입니다.이 커밋 후에 라는 새 브랜치
develop
를 만들었습니다. 그러면 이때 귀하의develop
브랜치에는 "1234"그러면
develop
에 커밋을 제출했는데 콘텐츠는 "1234 777"입니다이 기간 동안 귀하의
master
가 업데이트되었고 동료나 친구 또는 자신이master
에 새로운 커밋을 제출했습니다. 이를 "1234 666"으로 업데이트하세요.이때 다시 병합하면 충돌이 발생합니다. 왜냐하면 git은 두 브랜치에 "1234"라는 공통 조상(조상)이 있음을 발견하지만 git은 지금 병합할지 여부와 병합을 원하는지 알 수 없기 때문입니다. "666" " 그래도 "777"
귀하의 질문으로 돌아가서, 먼저 두 브랜치의 커밋 기록을 살펴보고 비교해 보시기 바랍니다. 이와 같은 상황을 찾을 수 있는지 확인하세요. 즉, 두 브랜치가 시작점(조상)으로 공통 커밋을 가지고 있지만 후속 커밋이 분기(pert)됩니다
아직도 문제를 설명할 수 없다면 편하신 경우 Github 주소를 보내주세요
자동 병합이 있기 때문이죠. 브랜치를 수동으로 병합할 때 충돌이 발생하는 것을 보셨나요?
해본 결과 작동하지 않는 것으로 나타났습니다. 원래 답변은 다음과 같습니다.
모두 제 추측입니다.
처음에는 마스터의 모습이 다음과 같습니다.
으아아아그런 다음 개발을 포크하고 다음과 같이 수정합니다.
으아아아이때, 개발은 마스터를 거쳐 마스터로 수정하는 것이기 때문에 충돌 없이 마스터와 직접 병합할 수 있습니다.
개발을 병합하지 않고 마스터를 변경했습니다:
으아아아이때 66세와 77세 사이에 갈등이 일어나고 있습니다. git은 개발 중인 4444가 3333에서 변경되고 888이 555에서 변경되었음을 알고 있으므로 현재 마스터 위치에는 여전히 3333과 555가 있습니다. 그런데 77은 원래 22에서 변경되었으나 이제 마스터의 22가 66이 되었습니다. 두 가지 충돌하는 수정 사항이 있으며 git은 77을 66으로 병합할 수 없습니다.
즉, 마스터와 디벨롭은 원래 같은 라인에 있었는데, 마스터를 바꾸면 새로운 마스터가 원래 개발과 같은 라인에 있지 않게 됩니다.