나는 git pull --rebase기본적으로 사용 하는 사람들 과 절대로 그것을 사용하지 않으려는 사람들을 알고 있습니다. 나는 병합과 rebasing의 차이점을 이해한다고 생각하지만, 나는 이것을 문맥에 두려고합니다 git pull. 많은 병합 커밋 메시지를보고 싶지 않거나 다른 문제가 있습니까?
답변
당신은 git pull --rebase언제 사용해야
- 변경 사항은 별도의 지점이 필요하지 않습니다
실제로-왜 그렇지 않습니까? 더 명확하고 커밋에 논리적 그룹 을 강요하지 않습니다 .
좋아, 나는 약간의 설명이 필요하다고 생각한다. Git에서는 아시다시피 분기 및 병합을 권장합니다. 변경 사항을 가져 오는 로컬 지점과 원격 지점은 실제로 다른 지점입니다.git pull 병합에 관한 것입니다. 매우 자주 푸시하지 않고 대개 완성 된 기능을 구성하기 전에 여러 변경 사항을 누적하므로 합리적입니다.
그러나 어떤 이유에서든이 두 지역 (원격 및 지역)이 하나의 지점 인 경우 실제로 더 나을 것이라고 생각합니다 . SVN 에서처럼. 여기 git pull --rebase가 시작됩니다. 더 이상 병합하지 않고 실제로 원격 지점에서 커밋 . 그것이 실제로 관한 것입니다.
위험한지 아닌지는 로컬 및 원격 지점을 분리 할 수없는 것으로 취급하는지의 문제입니다. 때로는 합리적입니다 (변경이 적거나 강력한 개발을 시작할 때 작은 변경으로 중요한 변경이있을 경우). 때로는 그렇지 않습니다 (일반적으로 다른 지점을 만들 때 너무 게으른 경우). 그러나 그것은 다른 질문입니다.
답변
“git pull –rebase”가 실제로 무엇을 의미하는지에 대한 다른 관점을 제공하고 싶습니다. 때로는 잃어버린 것 같습니다.
Subversion (또는 CVS)을 사용한 적이 있다면 “svn update”의 동작에 익숙 할 것입니다. 커밋에 대한 변경 사항이 있고 변경이 업스트림으로 인해 커밋이 실패하면 “svn update”입니다. Subversion은 업스트림 변경 사항을 귀하와 병합하여 충돌을 일으킬 수 있습니다.
Subversion이 방금 한 것은 본질적으로 “pull –rebase”였습니다. 최신 버전을 기준으로 로컬 변경 사항을 재구성하는 작업은 “변경된”부분입니다. 실패한 커밋 시도 전에 “svn diff”를 수행 한 후 결과 diff를 “svn diff”의 출력과 비교 한 경우 두 diff의 차이는 리베이스 작업이 수행 한 작업입니다.
이 경우 Git과 Subversion의 주요 차이점은 Subversion에서 “귀하의”변경 사항은 작업 복사본에서 커밋되지 않은 변경 사항으로 만 존재하지만 Git에서는 실제로 커밋이 로컬에 있다는 것입니다. 다시 말해, 힘내에서 당신은 역사를 포크했습니다. 당신의 역사와 상류의 역사가 갈라졌지만 공통 조상이 있습니다.
제 생각에는, 현지 지사가 단순히 상류 지사를 반영하고 지속적으로 개발하는 일반적인 경우에는 올바른 의미는 항상 “–rebase”입니다. 왜냐하면 그것이 실제로 의미 론적으로 하고 있기 때문입니다. . 당신과 다른 사람들은 지점의 의도 된 선형 이력을 해킹하고 있습니다. 푸시 시도 이전에 다른 누군가가 푸시를 시도했다는 사실은 관련이 없으며, 이러한 타이밍 사고로 인해 역사에 병합되는 것은 비생산적인 것처럼 보입니다.
어떤 이유로 든 무언가가 지사가 될 필요성을 실제로 느낀다면 그것은 제 생각에는 다른 관심사입니다. 그러나 병합 형태로 변경 사항을 표현하려는 구체적이고 적극적인 욕구가 없다면 기본 동작은 “git pull –rebase”여야합니다.
프로젝트의 역사를 관찰하고 이해해야하는 다른 사람들을 고려하십시오. 역사가 곳곳에 수백 건의 합병으로 흩어 지길 원하십니까? 아니면 의도적 인 발산 개발 노력의 실제 합병을 나타내는 엄선 된 몇 건의 합병 만 원하십니까?
답변
아마도 그것을 설명하는 가장 좋은 방법은 예입니다.
- Alice는 주제 분기 A를 작성하고 작업합니다.
- Bob은 관련이없는 주제 B를 작성하고 작업합니다.
- 앨리스는 않습니다
git checkout master && git pull. 마스터는 이미 최신 상태입니다. - 밥은 않습니다
git checkout master && git pull. 마스터는 이미 최신 상태입니다. - 앨리스는
git merge topic-branch-A - 밥은
git merge topic-branch-B - 밥은
git push origin master앨리스 전에 - Alice는
git push origin master빨리 감기 병합이 아니기 때문에 거부됩니다. - Alice는 오리진 / 마스터의 로그를보고 커밋이 자신과 관련이 없음을 확인합니다.
- 앨리스는
git pull --rebase origin master - Alice의 병합 커밋이 풀리고 Bob의 커밋이 풀리고 Alice의 커밋이 Bob의 커밋 후에 적용됩니다.
- Alice는 그렇습니다.
git push origin master모든 사람들은 앞으로 로그를 볼 때 쓸모없는 병합 커밋을 읽을 필요가 없다는 사실에 만족합니다.
병합되는 특정 분기는 예제와 관련이 없습니다. 이 예제의 마스터는 릴리스 브랜치 또는 개발자 브랜치가 될 수 있습니다. 요점은 Alice & Bob이 동시에 로컬 브랜치를 공유 원격 브랜치에 병합한다는 것입니다.
답변
git pull --rebase같은 지점에서 다른 사람들과 공동 작업 할 때 사용해야한다고 생각합니다 . 작업 → 커밋 → 작업 → 커밋주기에 있으며 작업을 푸시하기로 결정하면 동일한 브랜치에 병렬 작업이 있기 때문에 푸시가 거부됩니다. 이 시점에서 나는 항상 을 pull --rebase. 스쿼시 (커밋을 평평하게하기 위해)를 사용하지 않지만 추가 병합 커밋을 피하기 위해 rebase합니다.
Git 지식이 증가함에 따라 내가 사용했던 다른 버전 제어 시스템보다 역사를 훨씬 더 많이 찾고 있습니다. 작은 병합 커밋이 많은 경우 역사에서 일어나는 더 큰 그림의 초점을 쉽게 잃을 수 있습니다.
이것은 실제로 rebasing (*)하는 유일한 시간이며 나머지 워크 플로는 병합 기반입니다. 그러나 가장 빈번한 커미터가 이것을 수행하는 한, 역사는 결국 훨씬 더 좋아 보입니다.
(*) Git 코스를 가르치는 동안 특정 상황에서 rebasing feature 브랜치를 옹호했기 때문에 학생이 나를 체포했습니다. 그리고 그는이 답을 읽었습니다.) 그러한 재분배도 가능하지만, 그것은 항상 사전에 배열 된 합의 된 시스템에 따라야하며, 따라서 항상 “적용되지 않아야”합니다. 그리고 그 당시 나는 보통 pull --rebase어느 쪽도 하지 않습니다 .
답변
나는 이유가 지금까지 생각하지 않습니다 하지 사용 pull --rebase– 내가 특별히 내 수 있도록 힘내에 코드를 추가 git pull항상 상류 커밋에 대해 리베이스에 명령을.
히스토리를 살펴볼 때 기능을 수행하는 사람 / 갈인이 언제 동기화를 중단했는지 아는 것은 결코 흥미롭지 않습니다. 그 / 그녀가하는 동안 그 / 그녀에게 유용 할 수 있지만, 그것이 바로 그 일 reflog입니다. 다른 사람들에게 소음을 추가하는 것입니다.
답변
기억해라:
- 풀 = 페치 + 병합
- pull –rebase = 페치 + 리베이스
따라서 지점을 처리하려는 방식을 선택하십시오.
병합과 rebase의 차이점을 더 잘 알고 있습니다. 🙂
답변
나는 그것이 개인적인 취향으로 귀결된다고 생각합니다.
변경 사항을 적용하기 전에 바보 같은 실수를 숨기고 싶습니까? 그렇다면 git pull --rebase완벽합니다. 나중에 커밋을 몇 (또는 하나) 커밋으로 스쿼시 할 수 있습니다. 푸시되지 않은 히스토리에 병합 된 경우 git rebase나중에 수행하기가 쉽지 않습니다 .
개인적으로 바보 같은 실수를 모두 게시하지 않아도되므로 리베이스 대신 병합하는 경향이 있습니다.
