git rebase --skip은 정확히 무엇을합니까?

107

방금했는데 git pull --rebase origin master충돌이있었습니다.

첫째,이 충돌은 내가 건드리지 않은 파일에 있었으며 약 10 번의 커밋이었습니다. 왜 이런 일이 발생합니까?

그런 다음 실수로을 입력 git rebase --skip했고 '해당 패치를 건너 뛰었습니다'.

커밋을 건너 뛰는 것이 걱정이되어 마스터 브랜치의 새 버전을 확인하고 리베이스를 수행 한 브랜치와 새 마스터 브랜치를 비교했습니다. diff에 표시되는 유일한 변경 사항은 최신 커밋이며 로그를 보면 '건너 뛴'패치가 커밋 기록에 표시됩니다.

아무도 여기서 무슨 일이 일어나고 있는지 설명 할 수 있습니까?

git

— 미스터 우스터
소스

실수로 git rebase --skip. 아마 잘못? :)

— manojlds 2012 년

하아! --abort를 입력하려고했지만 알 수없는 이유로 --skip으로 나왔습니다. 정말 생각하지 않았습니다. :)

— mrwooster 2012 년

쉘 히스토리는 이것에 능숙합니다 (원하지 않은 것을 실행하게 만들기 위해).

— Florian Klein

말한대로 하고 커밋을 건너 뜁니다 . 당신이 실행하는 경우 rebase --abort같은 REBASE 동안 나중에 충돌에서의도 물론 복구됩니다 커밋 건너 뜁니다.

변경 사항이 이미 업스트림에있는 경우 Git은 커밋을 적용 할 수 없습니다 (하지만 패치가 정확히 동일한 경우 일반적으로 자동으로 건너 뛰어야합니다). 자신의 커밋은 건너 뛰지 만 이미 업스트림에 적용 되었기 때문에 현재 HEAD에 변경 사항이 여전히 존재합니다.

중요한 변경 사항을 제거하지 않았는지 확인해야합니다.) (rebase 이전 상태로 돌아가려면 reflog를 사용하십시오)

— 니트
소스

그렇다면 커밋이 여전히 로그에 나타나는 이유는 무엇입니까? 그리고 누락 된 커밋이 이제 diff에 표시되는 이유는 무엇입니까?

— mrwooster 2012 년

예, 충돌은 이미 업스트림에서 해결되었습니다 ... 어떤 이유로 git rebase가 오래된 병합 충돌을 가져옵니다 ... 나를 혼란스럽게하는 또 다른 것은? ... 이것은 충돌을 건너 뛰었지만 문제를 해결 한 패치를 적용했음을 의미합니까? 충돌?

— mrwooster 2012 년

업스트림 커밋과 동일한 변경 사항이있는 자신의 커밋을 건너 뛰었습니다. 커밋을 건너 뛰었지만 여전히 변경되었습니다 (이미 업스트림에 존재했기 때문에)

— knittl

@mittal 아니요, --skip갈 길이 아닌 것 같습니다 . Skip은 커밋을 완전히 건너 뛰고이 커밋의 모든 변경 사항을 삭제합니다.

— knittl

@mittal : 한 분기에서 다른 분기로 커밋을 복사 하는 git rebase것으로 생각하십시오 . 따라서 커밋을 건너 뛰면 커밋의 원래 내용을 건너 뛰고 패치가 적용되지 않습니다 (따라서 파일에 대한 모든 변경 사항이 대상 브랜치에 적용되지 않음). 가장 쉬운 방법은 두 개의 브랜치, 각각에 여러 커밋이있는 간단한 git 저장소를 설정 한 다음 리베이스하고 커밋을 건너 뛰는 것입니다 (복사 ( ) 또는 건너 뛸 커밋 ( ) 를 지정하는 데 사용할 수 있음git rebase --interactivepickskip

— knittl