리베이스 후 Git 분기가 분기되었습니다.

112

이미 푸시 된 지점을 로컬로 리베이스했습니다.

Git은 내 지점과 리모컨이 갈라졌고 다음과 같이 조언합니다.

"각각 109 개와 73 개 커밋이 있습니다."

내 브랜치를 푸시하면이 문제가 해결됩니다. 즉, 리베이스 후에 예상되는 문제입니까?

git

— 마티 월리스
소스

나는 같은 문제가 있습니다. "올바른 방법"은 로컬 브랜치를 리베이스 한 다음 푸시하는 것이라고 말할 수 있습니까?

— Mher Didaryan

154

브랜치를 리베이스 할 때 리베이스하는 브랜치의 커밋 위에있는 커밋에 대해 커밋을 다시 작성해야합니다. 커밋의 속성 중 하나가 부모 (또는 부모)이기 때문입니다. 리베이스 할 때 브랜치에서 가장 오래된 로컬 커밋의 부모를 변경하고이 변경 사항이 커밋을 통해 전 이적으로 거품이 발생하므로 모든 로컬 커밋의 커밋 해시를 변경합니다.

이미 브랜치를 푸시 했으므로 소스 브랜치에 대해 리베이스하지 않고 병합해야합니다. ( -f플래그를 사용하여 ) 새 브랜치를 "강제 푸시"할 수 있지만 브랜치 히스토리의 무결성이 방해를 받기 때문에 정상적인 푸시는 작동하지 않습니다. 이 브랜치에서 다른 사람들과 공동 작업을하는 경우 강제 푸시는 나쁜 생각입니다. 다른 공동 작업자의 기록이 갑자기 일치하지 않을 때 매우 혼란스러워지기 때문입니다.

요약-공동 작업을하지 않는 경우 push -f를 사용하여 분기를 푸시합니다. 그렇다면 분기를 이전 상태로 재설정하고 대신 소스 분기에서 병합하십시오.

— 제이슨 르 브런
소스

1

"이미 브랜치를 푸시 했으므로 소스 브랜치에서 병합 했어야합니다."-그 이유는 무엇입니까?

— hammett 2014 년

1

@HamiltonVerissimo Jason의 첫 번째 문장 : "브랜치를 리베이스 할 때 리베이스하는 브랜치의 커밋 위에있는 커밋에 대해 커밋을 다시 작성해야합니다." "위"커밋에서 캡처 된 변경 사항이 동일한 논리적 내용을 가지고 있어도 다른 기반에 적용되므로 해시가 다른 다른 커밋입니다. 다른 개발자가 사전 기반 브랜치에서 작업하는 경우 git push -f를 수행하면 워크 플로에 지장을 줄 수 있습니다. 따라서이 브랜치는 공개 소스로 푸시되었으므로 병합해야합니다.

— awolf

4

다른 사람이 이미 무언가를 푸시했는지 확실하지 않은 경우 push --force-with-lease를 사용할 수도 있습니다.

— 콘솔

1

@ jason-lebrun 경고없이 자신의 작업을 덮어 쓸 수있는 업스트림 변경 사항을 병합하는 단점이 아닙니까? 리베이스 할 때와 동일한 방식으로 병합 충돌이 감지됩니까? 예를 들어, 더 이상 필요하지 않기 때문에 브랜치의 파일에서 섹션을 제거했지만 다른 누군가가 업스트림의 동일한 섹션을 약간의 공백이나 전역 찾기 / 바꾸기 작업 제거와 같이 사소한 변경을 수행 한 경우에는 그렇지 않습니다. 내 브랜치 위에 병합하면 내 삭제가 사소하게 변경된 버전으로 대체됩니까?

— Chris Bloom

1

다른 브랜치를 귀하의 브랜치에 병합하는 것이 나쁜 생각이 아닙니까? 예를 들어 마스터를 기능 브랜치로 병합하면 새 커밋이 생성되지 않습니까? 나중에 마스터로 병합하면이 기능 분기가 추가 커밋되지 않습니까?

— Ross

55

모든 커밋이 ID를 변경 했으므로 전환이 진정한 분기 가 아닙니다 .

문제를 해결하려면 원격 지점을 덮어 써야합니다.

git push -f origin experiment

http://git-scm.com/book/ch3-6.html

설명:

이 이미지에서 C3가 rebase 이후에 C3로 배치되지 않고 C3 '로 배치되는 방법을 확인하십시오. 이것은 정확히 C3이 아니지만 모든 코드 변경 사항이 있기 때문입니다.

리베이스

이 다른 이미지에서는 리모컨이 관련 될 때 리베이스가 무엇인지, 왜 전환이 있는지에 대한 그림을 볼 수 있습니다.

분기 및 자식 푸시

어쨌든 강제 푸시를 한 후에는 (강제 업데이트)했다고 알려줄 것입니다. 그 시점에서 괜찮을 것입니다.

상단의 링크를 확인하고 "git push --force"를 검색합니다. 더 자세한 설명이 표시됩니다.

— Mimoralea
소스

3

예. 나는 이것이 문제를 해결한다고 생각합니다. 그러나 푸시가 다른 사람이 푸시 한 최근 작업을 덮어 쓸 수있는 팀에서 작업 할 때 강제 푸시가 작동하지 않을 수 있습니다. 내가 맞아?

— Hari Krishna Ganji 2014

원하는 효과가 없을 수 있습니다. 리베이스를 수행하기 전에 변경 사항을 '빨리 감기'로 병합하십시오.

— mimoralea 2014

1

다음을 수행하여 푸시에 대한 리베이스 분기에 성공했습니다.

git checkout mybranch
git pull
git push origin mybranch

당김으로 분기가 해결되었습니다.

당기기 전에

Your branch and 'origin/mybranch' have diverged,
and have 2 and 1 different commit(s) each, respectively.

PULL 출력

재귀로 병합합니다. mypath / myfile.py | 12 +++++++++++-파일 1 개 변경, 11 개 삽입 (+), 1 개 삭제 (-)

당기기 후

귀하의 브랜치는 3 커밋만큼 'origin / mybranch'보다 앞서 있습니다.

푸시 후

mybranch는 브랜치보다 3 앞서 있습니다. 여전히 커밋 기록에 추가 된 오픈 풀 요청 병합 메시지가 있습니다. Merge branch mybranch of remote to mybranch

나는 이것이 아마도 강제 푸시가하는 일이라고 가정하고 있으며 확인하지 않았습니다.

다른 사람들이 말했듯이 이미 열린 풀 요청이 있다면 리베이스를 피하십시오. 이 예제는 저에게 효과적이었습니다.

— 제로 코그
소스

1

이는 대상 브랜치를 현재 로컬 브랜치로 리베이스하고 대상 브랜치로 전환 한 다음 로컬 브랜치를 대상으로 리베이스하여 강제 푸시없이 수정할 수 있습니다. 누락되었을 수있는 커밋이 추가되고 더 이상 생성 할 필요가 없기 때문에 이는 분기되지 않습니다. 더 쉬운 설명을위한 예 :

주요 지점은 개발입니다
새로운 브랜치 기능 / doing_stuff를 체크 아웃했습니다.
팀원이 개발에 대한 새로운 약속을 추진합니다.

개발 브랜치를 업데이트하지 않은 경우 "git checkout develop"&& "git rebase feature / doing_stuff"는 체크 아웃 이후에 추가 된 커밋이 없기 때문에 올바르게 작동합니다. 그러나 개발을 체크 아웃하고 새 커밋을 풀다운 한 경우 새 커밋이 표시되어 리베이스를 시도하면 이러한 차이가 나타납니다. 강제 푸시 (일반적으로 팀 환경에서는 좋은 생각이 아님)없이 쉽게 해결할 수있는 방법은 다음과 같습니다.

git checkout feature / doing_stuff
자식 리베이스 개발
git checkout 개발
git rebase 기능 / doing_stuff

2 단계의 rebase는 누락 된 커밋을 feature / doing_stuff에 가져 오므로 4 단계가 진행되면 최신 상태이며 변경에 대한 새 커밋을 만들 필요가 없습니다.

이것은 내가이 문제를 만났고 위의 단계를 수행하여 강제없이 성공적으로 개발을 추진했기 때문에 작동한다는 것을 알고있는 솔루션입니다. 저는 50 명이 넘는 개발자로 구성된 팀에서 일하고 있기 때문에 제 테스트 브랜치 이외의 다른 것을 강제하는 것은 금지되어 있으므로 해결책을 찾아야했습니다.

— 크리스
소스