git pull아마도 커밋을 만들고있을 것입니다. 로컬 커밋을 만든 다음 git pull다른 사람이 커밋을 저장소에 푸시 한 후 실행 하면 Git은 다른 개발자의 커밋을 다운로드 한 다음 로컬 브랜치에 병합합니다.
앞으로 이러한 병합 커밋을 피하는 방법
git pull --rebase미래에 이런 일이 발생하지 않도록 사용할 수 있지만 리베이스에는 위험이 있으므로 pull모두 피하는 것이 좋습니다 .
대신 다음 사용 패턴을 따르는 것이 좋습니다.
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
설명
git remote update -p원격 저장소에있는 모든 커밋을 다운로드하고 원격 추적 분기 (예 :)를 업데이트합니다 origin/master. 작업 디렉토리, 색인 또는 로컬 브랜치를 건드리지 않습니다.
-p인수 자두는 상류 지점을 삭제. 따라서 저장소 foo에서 브랜치가 삭제 되면 자동으로 ref를 삭제합니다 .origingit remote update -porigin/foo
git merge --ff-only @{u}Git에게 업스트림 브랜치 ( @{u}인수)를 로컬 브랜치로 병합하라고 지시 하지만 로컬 브랜치가 업스트림 브랜치로 "빠르게 전달"될 수있는 경우에만 (즉, 분기되지 않은 경우).
git rebase -p @{u}만든 커밋을 효과적으로 이동하지만 아직 업스트림 브랜치 위로 푸시하지 않았으므로 피하려는 어리석은 병합 커밋을 만들 필요가 없습니다. 이렇게하면 개발 기록의 선형성이 향상되어 더 쉽게 검토 할 수 있습니다.
이 -p옵션은 Git에 병합을 유지하도록 지시합니다. 이는 Git이 리베이스되는 커밋을 선형화하는 것을 방지합니다. 예를 들어 피쳐 분기를에 병합 한 경우 이는 중요합니다 master. 를 사용하지 않으면 -p기능 분기의 모든 커밋이에서 master수행 한 선형화의 일부로 복제 됩니다 git rebase. 이것은 개발 기록을 검토하기가 더 어렵게 만들 것입니다.
주의 : git rebase예상 한대로 작동 하지 않을 수 있으므로 푸시하기 전에 결과를 검토하십시오. 예를 들면 :
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
git pull --rebase다음과 같은 이유로이 접근 방식을 선호합니다 .
- 이를 통합하기 위해 히스토리를 수정하기 전에 들어오는 업스트림 커밋 을 볼 수 있습니다 .
- 의도적 인 병합 (예 : 이미 푸시 된 기능 분기를로 병합)을 리베이스해야하는 경우
-p( --preserve-merges) 옵션을 git rebase에 전달할 수 있습니다 master.
속기 : git up대신git pull
위의 작업을 쉽게 수행하려면 다음과 같은 별칭을 만드는 것이 좋습니다 up.
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
이제 브랜치를 최신 상태로 유지하기 위해해야 할 일은 다음을 실행하는 것입니다.
git up
대신 git pull. 로컬 브랜치가 업스트림 브랜치에서 분기되어 오류가 발생하면 리베이스 할 단서입니다.
왜 안돼 git pull --rebase?
Running git pull --rebase은 running git fetch다음에 git rebase. 이것은 새로운 업스트림 커밋으로 빨리 감기를 시도하지만 가능하지 않은 경우 로컬 커밋을 새로운 업스트림 커밋으로 리베이스합니다. 일반적으로 괜찮지 만주의하세요.
- Rebase는 고급 주제이며 리베이스하기 전에 의미를 이해해야합니다.
git pull --rebase커밋을 통합하기 전에 검사 할 기회를주지 않습니다. 상류 변경 내용에 따라, REBASE이 잘못된 동작을-A는 것을 확실히 가능 rebase --onto, merge, reset, 또는 push -f일반보다 더 적합 할 수 있습니다가 rebase.- (현재)
--preserve-merges리베이스 작업 으로 전달할 수 없으므로 기능 분기의 의도적 인 병합은 선형화되어 모든 기능 분기 커밋을 재생 (따라서 복제)합니다.
에 의해 생성 된 기존 병합 커밋 "수정" git pull
에서 만든 병합 커밋을 아직 푸시하지 않은 경우 병합 커밋 git pull을 리베이스 할 수 있습니다. 의도적 인 병합 (예 : 이미 푸시 된 기능 분기를 현재 분기에 병합)이 없다고 가정하면 다음을 수행해야합니다.
git rebase @{u}
위의 명령은 비 병합 모두에서 접근 커밋 선택 힘내을 알려줍니다 HEAD(커밋 현재)을 뺀 모든 커밋에서 도달 @{u}(즉, "상류 지점"에 대한 속기 인 origin/master경우 HEAD이다 master), 재생 (체리 - 선택을 ) 업스트림 브랜치의 맨 위에 놓은 다음 현재 브랜치 참조를 커밋 재생 결과를 가리 키도록 이동합니다. 이것은 병합이 아닌 커밋을 가장 최근의 업스트림 커밋으로 효과적으로 이동시켜 git pull.
의도적 인 병합 커밋이있는 경우 git rebase @{u}다른 브랜치의 모든 것을 재생하므로 실행하고 싶지 않습니다 . 이 사건을 처리하는 것은 훨씬 더 복잡하기 때문에 사용 git up하고 피하는 것이 좋습니다 git pull. 를 사용 reset하여 만든 병합을 실행 취소 pull한 다음 git rebase -p @{u}. 에 대한 -p인수가 git rebase저에게 안정적으로 작동하지 않았으므로 reset의도적 병합을 실행 취소하고 로컬 브랜치를으로 업데이트 @{u}한 다음 의도적 병합을 다시 실행해야 할 수도 있습니다. 갈등).