답변:
당신은 git pull --rebase언제 사용해야
실제로-왜 그렇지 않습니까? 더 명확하고 커밋에 논리적 그룹 을 강요하지 않습니다 .
좋아, 나는 약간의 설명이 필요하다고 생각한다. Git에서는 아시다시피 분기 및 병합을 권장합니다. 변경 사항을 가져 오는 로컬 지점과 원격 지점은 실제로 다른 지점입니다.git pull 병합에 관한 것입니다. 매우 자주 푸시하지 않고 대개 완성 된 기능을 구성하기 전에 여러 변경 사항을 누적하므로 합리적입니다.
그러나 어떤 이유에서든이 두 지역 (원격 및 지역)이 하나의 지점 인 경우 실제로 더 나을 것이라고 생각합니다 . SVN 에서처럼. 여기 git pull --rebase가 시작됩니다. 더 이상 병합하지 않고 실제로 원격 지점에서 커밋 . 그것이 실제로 관한 것입니다.
위험한지 아닌지는 로컬 및 원격 지점을 분리 할 수없는 것으로 취급하는지의 문제입니다. 때로는 합리적입니다 (변경이 적거나 강력한 개발을 시작할 때 작은 변경으로 중요한 변경이있을 경우). 때로는 그렇지 않습니다 (일반적으로 다른 지점을 만들 때 너무 게으른 경우). 그러나 그것은 다른 질문입니다.
git config --global pull.rebase preserve .
"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"여야합니다.
프로젝트의 역사를 관찰하고 이해해야하는 다른 사람들을 고려하십시오. 역사가 곳곳에 수백 건의 합병으로 흩어 지길 원하십니까? 아니면 의도적 인 발산 개발 노력의 실제 합병을 나타내는 엄선 된 몇 건의 합병 만 원하십니까?
git config --global branch.autosetupmerge always말입니까?
아마도 그것을 설명하는 가장 좋은 방법은 예입니다.
git checkout master && git pull. 마스터는 이미 최신 상태입니다.git checkout master && git pull. 마스터는 이미 최신 상태입니다.git merge topic-branch-Agit merge topic-branch-Bgit push origin master앨리스 전에git push origin master빨리 감기 병합이 아니기 때문에 거부됩니다.git pull --rebase origin mastergit push origin master모든 사람들은 앞으로 로그를 볼 때 쓸모없는 병합 커밋을 읽을 필요가 없다는 사실에 만족합니다.병합되는 특정 분기는 예제와 관련이 없습니다. 이 예제의 마스터는 릴리스 브랜치 또는 개발자 브랜치가 될 수 있습니다. 요점은 Alice & Bob이 동시에 로컬 브랜치를 공유 원격 브랜치에 병합한다는 것입니다.
git co master && git pull; git checkout topic-branch-A; git rebase master; git checkout master; git merge topic-branch-A; git push origin master다른 사람의 지배가 내 앞에 밀려 나면 분명하고 반복 되는 경향이있다 . 나는 당신의 레시피에서 간결한 장점을 볼 수 있지만.
git pull --rebase같은 지점에서 다른 사람들과 공동 작업 할 때 사용해야한다고 생각합니다 . 작업 → 커밋 → 작업 → 커밋주기에 있으며 작업을 푸시하기로 결정하면 동일한 브랜치에 병렬 작업이 있기 때문에 푸시가 거부됩니다. 이 시점에서 나는 항상 을 pull --rebase. 스쿼시 (커밋을 평평하게하기 위해)를 사용하지 않지만 추가 병합 커밋을 피하기 위해 rebase합니다.
Git 지식이 증가함에 따라 내가 사용했던 다른 버전 제어 시스템보다 역사를 훨씬 더 많이 찾고 있습니다. 작은 병합 커밋이 많은 경우 역사에서 일어나는 더 큰 그림의 초점을 쉽게 잃을 수 있습니다.
이것은 실제로 rebasing (*)하는 유일한 시간이며 나머지 워크 플로는 병합 기반입니다. 그러나 가장 빈번한 커미터가 이것을 수행하는 한, 역사는 결국 훨씬 더 좋아 보입니다.
(*) Git 코스를 가르치는 동안 특정 상황에서 rebasing feature 브랜치를 옹호했기 때문에 학생이 나를 체포했습니다. 그리고 그는이 답을 읽었습니다.) 그러한 재분배도 가능하지만, 그것은 항상 사전에 배열 된 합의 된 시스템에 따라야하며, 따라서 항상 "적용되지 않아야"합니다. 그리고 그 당시 나는 보통 pull --rebase어느 쪽도 하지 않습니다 .
나는 이유가 지금까지 생각하지 않습니다 하지 사용 pull --rebase- 내가 특별히 내 수 있도록 힘내에 코드를 추가 git pull항상 상류 커밋에 대해 리베이스에 명령을.
히스토리를 살펴볼 때 기능을 수행하는 사람 / 갈인이 언제 동기화를 중단했는지 아는 것은 결코 흥미롭지 않습니다. 그 / 그녀가하는 동안 그 / 그녀에게 유용 할 수 있지만, 그것이 바로 그 일 reflog입니다. 다른 사람들에게 소음을 추가하는 것입니다.
pull --rebase항상 사용되어야한다, 왜하지 않습니다 pull기본적으로합니까?
.gitconfig옵션 중 일부가 옳은 일을 할 수 있도록 몇 가지 사항 이 있습니다. git rebase와 같이 git rebase는 기본적으로 잘못된 일을한다고 생각합니다 ... 동의하지 않으면 의견을 정당화 할 필요가 없습니다.
master끌어 와서, 그리고 당신이 끌어온 지점이 아직 공개되지 않았다면 좋은 조언처럼 보입니다 . 피처 브랜치에서 다른 한편으로 피처 브랜치를 당기면 master다른 방법과 비슷합니다. 사용할 이유가 없습니다 --rebase. 이것이 기본값이 아닌 이유 일 수 있습니다. Rebases는 변경 사항이 계층의 맨 위에서 아래쪽으로 전달되는 방식이고 병합은 다시 위쪽으로 흐르는 방식이라는 것을 알았습니다. derekgourlay.com/blog/git-when-to-merge-vs-when-to-rebase
나는 그것이 개인적인 취향으로 귀결된다고 생각합니다.
변경 사항을 적용하기 전에 바보 같은 실수를 숨기고 싶습니까? 그렇다면 git pull --rebase완벽합니다. 나중에 커밋을 몇 (또는 하나) 커밋으로 스쿼시 할 수 있습니다. 푸시되지 않은 히스토리에 병합 된 경우 git rebase나중에 수행하기가 쉽지 않습니다 .
개인적으로 바보 같은 실수를 모두 게시하지 않아도되므로 리베이스 대신 병합하는 경향이 있습니다.