git rebase 매개 변수 이해 및 기억

지금까지 git의 가장 혼란스러운 부분은 다른 브랜치에 대한 것입니다. 특히 혼동되는 것은 명령 행 인수입니다.

한 지점의 작은 조각을 다른 지점의 끝으로 리베이스 할 때마다 git rebase 문서를 검토해야하며 3 가지 주요 인수 각각을 이해하는 데 약 5-10 분이 걸립니다.

git rebase <upstream> <branch> --onto <newbase>

다른 브랜치에 어떤 종류의 리베이스가 주어지면이 세 가지 매개 변수 각각을 설정 해야하는 것을 기억하는 데 도움이되는 좋은 경험 법은 무엇입니까?

나는 git-rebase 문서를 계속해서 또 다시 또 다시 또 다시 반복했다는 것을 명심하십시오. 그러나 지루한 과학 백서 또는 무언가와 같이 항상 이해하기는 어렵습니다. 그래서이 시점에서 나는 그것을 이해하도록 다른 사람들을 참여시켜야한다고 생각합니다.

내 목표는 이러한 기본 매개 변수에 대한 설명서를 검토 할 필요가 없다는 것입니다. 나는 지금까지 그것들을 암기 할 수 없었고, 나는 이미 많은 rebase를 해왔다. 그래서 지금까지 다른 모든 명령과 매개 변수를 암기 할 수 있었지만 rebase로는 rebase 할 수 없었습니다 --onto.

--onto잠시 건너 뛰자. upstream그리고 branch매우 기본적이고 실제로는 모방 checkout되어 branch있으며 두 번째 인수는 선택 사항입니다.

git branch <newbranch>
git branch <newbranch> <base>
git checkout -b <newbranch>
git checkout -b <newbranch> <base>
git rebase <upstream>
git rebase <upstream> <branch>

_{(제외하고, 이러한 인수의 이름 rebase, "상류"와 "분기"매우 아니다 IMO 설명적인 내가 일반적으로 peachoftree처럼 생각. <start>그리고 <end>내가 그들을 사용하게 될 방법이다, : git rebase <start> <end>)}

두 번째 분기가 생략되면 결과는 해당 분기를 먼저 체크 아웃 한 다음 해당 분기를 지정하지 않은 것처럼 수행하는 것과 거의 같습니다. 예외는 branch현재 지점을 변경하지 않습니다.

git checkout <base> && git branch <newbranch> && git checkout <previous_branch>
git checkout <base> && git checkout -b <newbranch>
git checkout <end>  && git rebase <start>

rebase호출했을 때 수행되는 작업 을 이해하기 위해 먼저 특수 유형의 병합으로 생각했습니다. 실제로는 아니지만 처음으로 rebase를 이해하기 시작했을 때 도움이되었습니다. peachoftree의 예를 빌리려면 :

A--B--F--G master
    \
     C--D--E feature

git merge master이 결과 :

A--B--F-----G master
    \        \
     C--D--E--H feature

A는 동안 git rebase master(분기 동안은 feature!)이 결과 :

A--B--F--G master
          \
           C'--D'--E' feature

두 경우 feature모두 master및의 코드가 모두 포함 feature됩니다. 에 있지 않으면 feature두 번째 인수를 사용하여 바로 가기로 전환 할 수 있습니다 git rebase master feature. 위와 동일한 작업을 수행합니다.

지금, 특별한 --onto. 이를 기억해야 할 중요한 부분은 <start>지정하지 않은 경우 기본값으로 설정 된다는 것 입니다. 위의 내용을 --onto구체적으로 지정 하면 결과는 동일합니다.

git rebase --onto master master
git rebase --onto master master feature

_{( 정신적으로 파싱하기 쉽기 때문에 단순히 --onto지정 하지 않고는 사용하지 않으며 <end>, 이미 두 경우 모두 동일하다고 생각합니다 feature.)}

왜 --onto유용한 지 알아보기 위해 다른 예가 있습니다. 내가 켜져 feature있고 버그를 발견 한 다음 수정을 시작했지만 실수 feature대신 분기되지 않았다고 가정 해 봅시다 master.

A--B--F--G master
    \
     C--D--E feature
            \
             H--I bugfix

내가 원하는 것은 bugfix더 이상에 의존하지 않도록 커밋을 "이동" 하는 것입니다 feature. 그대로,이 답변에서 위에 표시된 모든 종류의 병합 또는 리베이스 feature는 두 개의 커밋과 함께 세 개의 커밋을 가져옵니다 bugfix.

예를 들어, git rebase master bugfix잘못되었습니다. 범위 <start>로는 <end>모든 커밋을 포함하는 일 feature의 상단에 재생된다 master:

A--B--F--G master
    \     \
     \     C'--D'--E'--H'--I' bugfix
      \
       C--D--E feature

우리가 실제로 원하는 것은에서 커밋의 범위 feature에 bugfix상단에 재생 될 master. 이것이 바로 --onto"시작"분기와 다른 "재생"대상을 지정하는 것입니다.

git rebase --onto master feature bugfix

A--B--F--G master
    \     \
     \     H'--I' bugfix
      \
       C--D--E feature

새로 고침, rebasing은 두 분기가 서로 독립적으로 개발 된 경우 기본적으로 커밋 기록을 다시 작성하는 경우 커밋 기록이 선형으로 표시되도록 할 때 주로 사용됩니다.

내가 좋아하는 방식은 git rebase --onto <target branch> <start branch> <end branch>

어디에서 <target branch>당신이 rebasing <start branch>하는 지점이며, 일반적으로 <end branch>스플릿 <end branch>하는 지점이며 당신이 rebasing하는 지점입니다.

시작하면

A--B--F--G master
    \
     C--D--E feature

하고

git rebase --onto master master feature

당신은 얻을 것이다

A--B--F--G master
          \
           C'--D'--E' feature

알아야 할 또 다른 좋은 점은 <target branch>기본 설정 <start branch>이므로

git rebase --onto master feature

도움이 더 필요하면 눈물이없는 Rebase 안내서를 확인하십시오.