이미 푸시 된 지점을 로컬로 리베이스했습니다.
Git은 내 지점과 리모컨이 갈라졌고 다음과 같이 조언합니다.
“각각 109 개와 73 개 커밋이 있습니다.”
내 브랜치를 푸시하면이 문제가 해결됩니다. 즉, 리베이스 후에 예상되는 문제입니까?
답변
브랜치를 리베이스 할 때 리베이스하는 브랜치의 커밋 위에있는 커밋에 대해 커밋을 다시 작성해야합니다. 커밋의 속성 중 하나가 부모 (또는 부모)이기 때문입니다. 리베이스 할 때 브랜치에서 가장 오래된 로컬 커밋의 부모를 변경하고이 변경 사항이 커밋을 통해 전 이적으로 거품이 발생하므로 모든 로컬 커밋의 커밋 해시를 변경합니다.
이미 브랜치를 푸시 했으므로 소스 브랜치에 대해 리베이스하지 않고 병합해야합니다. ( -f플래그를 사용하여 ) 새 브랜치를 “강제 푸시”할 수 있지만 브랜치 히스토리의 무결성이 방해를 받기 때문에 정상적인 푸시는 작동하지 않습니다. 이 브랜치에서 다른 사람들과 공동 작업을하는 경우 강제 푸시는 나쁜 생각입니다. 다른 공동 작업자의 기록이 갑자기 일치하지 않을 때 매우 혼란스러워지기 때문입니다.
요약-공동 작업을하지 않는 경우 push -f를 사용하여 분기를 푸시합니다. 그렇다면 분기를 이전 상태로 재설정하고 대신 소스 분기에서 병합하십시오.
답변
모든 커밋이 ID를 변경 했으므로 전환이 진정한 분기 가 아닙니다 .
문제를 해결하려면 원격 지점을 덮어 써야합니다.
git push -f origin experiment
http://git-scm.com/book/ch3-6.html
설명:
이 이미지에서 C3가 rebase 이후에 C3로 배치되지 않고 C3 ‘로 배치되는 방법을 확인하십시오. 이것은 정확히 C3이 아니지만 모든 코드 변경 사항이 있기 때문입니다.
이 다른 이미지에서는 리모컨이 관련 될 때 리베이스가 무엇인지, 왜 전환이 있는지에 대한 그림을 볼 수 있습니다.
어쨌든 강제 푸시를 한 후에는 (강제 업데이트)했다고 알려줄 것입니다. 그 시점에서 괜찮을 것입니다.
상단의 링크를 확인하고 “git push –force”를 검색합니다. 더 자세한 설명이 표시됩니다.
답변
다음을 수행하여 푸시에 대한 리베이스 분기에 성공했습니다.
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
나는 이것이 아마도 강제 푸시가하는 일이라고 가정하고 있으며 확인하지 않았습니다.
다른 사람들이 말했듯이 이미 열린 풀 요청이 있다면 리베이스를 피하십시오. 이 예제는 저에게 효과적이었습니다.
답변
이는 대상 브랜치를 현재 로컬 브랜치로 리베이스하고 대상 브랜치로 전환 한 다음 로컬 브랜치를 대상으로 리베이스하여 강제 푸시없이 수정할 수 있습니다. 누락되었을 수있는 커밋이 추가되고 더 이상 생성 할 필요가 없기 때문에 이는 분기되지 않습니다. 더 쉬운 설명을위한 예 :
- 주요 지점은 개발입니다
- 새로운 브랜치 기능 / 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 명이 넘는 개발자로 구성된 팀에서 일하고 있기 때문에 제 테스트 브랜치 이외의 다른 것을 강제하는 것은 금지되어 있으므로 해결책을 찾아야했습니다.