나는 git을 언젠가 다시 사용하기 시작했고 복잡성을 완전히 이해하지 못했습니다. 내 기본적인 질문은 여기의 차이 발견하는 것입니다 git pull및 git pull --rebase가산하기 때문에, --rebase매우 뭔가 다른 일을하지 않는 것 옵션 : 단지 풀 않습니다.
차이점을 이해하도록 도와주세요.
답변:
git pull업스트림 지점 추적에 대한 = git fetch+git merge
git pull --rebase업스트림 지점 추적에 대한 = git fetch+git rebase
방법 git merge과 git rebase차이점 을 알고 싶다면 이것을 읽으십시오 .
git pull --rebase것이 동일 git fetch하고 git rebase기본적으로 그 방법 이라는 점은 주목할 가치가 있지만, 의미 적으로 정확히 동일 하지는 않습니다 . 몇 가지 차이점이 있으며 그 중 일부는 여기에 설명되어 있습니다. gitolite.com/git-pull--rebase
fetch?
때때로 우리는 우리가 의존하는 브랜치를 리베이스 / 리와인드하는 업스트림을 가지고 있습니다. 우리가 다운 스트림 인 경우 우리에게 지저분한 갈등을 일으키는 큰 문제가 될 수 있습니다.
마술은
git pull --rebase일반적인 git pull은 느슨하게 말하면 다음과 같습니다 (이 예제에서는 모두 origin이라는 원격과 foo라는 분기를 사용합니다).
# assume current checked out branch is "foo" git fetch origin git merge origin/foo언뜻보기에는 git pull --rebase가 다음과 같이한다고 생각할 수 있습니다.
git fetch origin git rebase origin/foo그러나 업스트림 리베이스에 "스 쿼싱"이 포함 된 경우 도움이되지 않습니다 (커밋의 패치 ID가 순서가 아니라 변경되었음을 의미).
이것은 git pull --rebase가 그보다 약간 더 많은 일을해야한다는 것을 의미합니다. 다음은 그 기능과 방법에 대한 설명입니다.
출발점이 이것이라고 가정 해 봅시다.
a---b---c---d---e (origin/foo) (also your local "foo")시간이 흐르면서 자신의 "foo"위에 커밋을합니다.
a---b---c---d---e---p---q---r (foo)한편, 반사회적 분노에 맞서, 업스트림 관리자는 자신의 "foo"를 기반으로 할뿐만 아니라 스쿼시를 사용했습니다. 그의 커밋 체인은 다음과 같습니다 :
a---b+c---d+e---f (origin/foo)이 시점에서 git pull은 혼란을 초래할 것입니다. 자식 패치조차도; git rebase origin / foo는 한쪽에 "b"와 "c"를 커밋하고 다른쪽에 "b + c"를 커밋하면 충돌하지 않기 때문에 잘라 내지 않습니다. (그리고 d, e, d + e와 비슷하게).
git pull --rebase이 경우에 무엇입니까 :git fetch origin git rebase --onto origin/foo e foo이것은 당신에게 제공합니다 :
a---b+c---d+e---f---p'---q'---r' (foo)
여전히 충돌이 발생할 수 있지만 실제 충돌 (p / q / r과 a / b + c / d + e / f 간)이며 b / c와 b + c와의 충돌로 인한 충돌이 아닙니다.
답변 (약간 수정) :
http://gitolite.com/git-pull--rebase
a---b+c---d+e---f---p'---q'---r' (foo)rebase가 해시 를 변경하므로 최종 결과를으로 변경할 수 있습니다 .
A, 상류 저장소에 PR을 보냈습니다. 그런 다음 git pull --rebase업스트림 리포지토리에 반대 했을 때 A'풀업 업스트림 리포지토리에 새로운 커밋을 얻지 못했습니다 . 실제로는 전혀 A'존재 하지 않았습니다 . A시스템에 병합 되었기 때문 입니까? 아니면 업스트림 버전과 rebased 버전에 차이가 없었기 때문입니까?
git pull --rebase있었습니다. 그러나이 가상 상황에서 나를 혼란스럽게하는 한 가지 점은 업스트림 관리자가 이미 로컬 개발자의 저장소로 가져온 프로젝트 기록을 변경했다는 것입니다. 이것은 일반적으로 나쁜 습관이 아닙니까? 커밋 / 다시 쓰기 히스토리를 스쿼시하려면 이러한 유형의 충돌을 피하기 위해이를 중앙 저장소에 통합하기 전에 수행해야합니다.
로컬 브랜치에 두 개의 커밋이 있다고 가정하십시오.
D---E master
/
A---B---C---F origin/master
"git pull"후 다음과 같습니다.
D--------E
/ \
A---B---C---F----G master, origin/master
"git pull --rebase"후에는 병합 지점 G가 없습니다. D와 E는 다른 커밋이됩니다.
A---B---C---F---D'---E' master, origin/master
git rebase입니까? 그러나 우리는에 대해 이야기하고 git pull --rebase있습니다. 그리고 그들은 다른 것입니다.
충돌이없는 가장 간단한 경우
또한보십시오:
man git-pull
보다 정확하게는 git pull은 주어진 매개 변수로 git fetch를 실행하고 git merge를 호출하여 검색 된 분기 헤드를 현재 분기로 병합합니다. --rebase를 사용하면 git merge 대신 git rebase를 실행합니다.
참조 :
git pull --rebase는 언제 사용해야합니까?
http://git-scm.com/book/en/Git-Branching-Rebasing
git sdd modified-file; git rebase --continue또는 병합 : git add modified-file; git commit;어디 modified-file로컬 파일이 수동 / mergetool을 수정
fetch가요? 그들은 왜 두 개의 rebase흐름 을 만들었 습니까? 1) git rebase과 2) git pull --rebase?
Merge와 Rebase의 차이점을 이해하는 것이 중요합니다.
리베이스는 변경 사항이 계층 구조의 위쪽에서 아래쪽으로 전달되는 방식이고 병합은 변경이 위쪽으로 흐르는 방식입니다.
자세한 내용은 http://www.derekgourlay.com/archives/428을 참조하십시오 .