내 조직에서 다음 메시지를 커밋하는 유일한 사람입니다.
원격 추적 분기 ‘원점 / 개발’을 개발에 병합
내가 뭘하는지 잘 모르겠지만 그만두고 싶어요.
이 커밋을 생성하기 위해 어떤 명령을 내리고 있으며이를 생성하지 않기 위해 사용해야하는 적절한 명령은 무엇입니까?
답변
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를 삭제합니다 .origin
git remote update -p
origin/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}
한 다음 의도적 병합을 다시 실행해야 할 수도 있습니다. 갈등).
답변
git fetch
git rebase origin/master
그렇게해야합니다. 또는 계속해서 pull을 사용하려면
git pull --rebase
또한 구성에서 해당 분기를 설정하여 자동으로 리베이스하거나 앞으로 만드는 다른 추적 분기에 대해 자동으로 설정할 수 있습니다. 그런 다음 다시 사용하여
git pull
자세한 내용은이 페이지의 “병합 대신 rebase를 사용하여 가져 오기”섹션을 참조하십시오.
http://mislav.uniqpath.com/2010/07/git-tips/