마스터에서 개발 브랜치로 git pull


495

dmgr2 (개발)라는 브랜치가 있고 마스터 브랜치 (라이브 사이트)에서 가져 와서 모든 변경 사항을 내 개발 브랜치에 통합하고 싶습니다. 더 좋은 방법이 있습니까? 다음은 변경 사항을 커밋 한 후 계획 한 것입니다.

git checkout dmgr2
git pull origin master

이것이 실제 변경 사항을 개발 지점으로 가져와야합니까? 아니면 잘못 되었습니까?


1
먼저 dmgr2 브랜치에서 모든 변경 사항을 커밋하십시오. 그런 다음 master 1.git checkout master를 가리킨 다음 최신 변경 사항을 가져옵니다. 2.git pull 3.git merge dmgr2 4.git push -u origin master 그런 다음 dmgr2로 돌아갑니다. 5.git checkout dmgr2
mat_vee

이미 dmgr2 브랜치에 대한 모든 변경 사항을 커밋했습니다. 죄송합니다.
Matthew Colley

1
4 단계를 수행하면 개발 변경 사항을 마스터로 푸시하지 않습니까? 난 그렇게하고 싶지
않아

당신이 말하는 것은 마스터 브랜치에서 개발자 브랜치로 변경 사항을 가져오고 싶다는 것입니까?
JcKelley

9
dev지점으로 전환 하십시오 git checkout dev. 그런 다음 git pull --rebase origin master. 운이 좋으면 충돌이 없으며 개발자는 마스터의 최신 변경 사항을 갖습니다.
jww

답변:


724

나열된 단계가 작동하지만 더 많은 옵션을 제공하는 더 긴 방법이 있습니다.

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

fetch전과 명령은 어느 시점에서 할 수있는 merge, 즉, 당신의 순서를 바꿀 수있는 가져 오기 때문 체크 아웃, fetch바로 원격 이름 (까지가는 origin)와 그것을 말한다 : "내놔 모든 것을 당신은 내가하지 않는 것이있다 ", 즉 모든 지점에서 커밋합니다. 그들은 당신의 저장소에 복사되지만 이름 origin/branch이있는 모든 지점의 이름이 지정됩니다.branch 원격에 됩니다.

이 시점에서 모든 뷰어 ( git log, gitk등)를 사용하여 자신이 갖고 있지 않은 것을 "그것이 무엇인지"확인할 수 있으며 그 반대도 마찬가지입니다. 때때로 이것은 따뜻한 퍼지 감정 ( "아, 그래, 사실 내가 원하는 것")에만 유용하고 때로는 전략을 완전히 바꾸는 데 유용 할 때도 있습니다 ( "아, 아직 그런 것을 원하지 않습니다").

마지막으로, merge명령은 이름을 지정할 수있는 지정된 커밋 origin/master을 가져오고 해당 커밋과 조상을 가져 오는 데 필요한 모든 작업을 수행 할 때 수행하는 모든 분기에 수행합니다 merge. 빨리 감기를 삽입 --no-ff하거나 --ff-only방지 하거나 원하는 경우 결과가 빨리 감기 인 경우에만 병합 할 수 있습니다.

시퀀스를 사용할 때 :

git checkout dmgr2
git pull origin master

pull명령은 git에게 run을 지시 git fetch한 다음 도덕적으로 라는 명령을 지시 git merge origin/master합니다. 따라서 이것은 두 단계를 직접 수행하는 것과 거의 동일하지만 아마도 당신과 관련이없는 약간의 미묘한 차이점이 있습니다. (특히 fetch실행 단계 pull 가져 오며 origin/master리포지토리의 참조를 업데이트하지 않습니다. 1 새로운 커밋은 특별한 FETCH_HEAD참조 로만 참조됩니다.)

보다 명확하게 git fetch origin(선택적으로 둘러보고) git merge origin/master시퀀스 를 사용하는 경우 네트워크를 통해 master한 번만 fetch실행 하여 리모컨을 사용하여 로컬 을 최신 상태로 유지할 수도 있습니다.

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

예를 들어.


1 이 두 번째 부분은 git 1.8.4에서 "고정"이라고 변경되어 이제는 "원격 지점"참조를 업데이트합니다. (릴리스 노트에서 알 수 있듯이 업데이트를 건너 뛰려는 의도적 인 디자인 결정이지만 더 많은 사람들이 git 업데이트를 선호하는 것으로 나타났습니다. 이전 원격 지점 SHA-1을 원할 경우 기본적으로 저장됩니다 reflog에서 복구 할 수 있으며 업스트림 리베이스를 찾는 새로운 git 1.9 / 2.0 기능을 사용할 수 있습니다.)


28
난 그냥 친구를 요구하고 있습니다-여기에있는 첫 번째 코드 블록을 취소하는 방법은 무엇입니까 (체크 아웃 / 가져 오기 / 병합)?
Rich Bradshaw

10
@RichBradshaw : git checkout일반적으로 비파괴 적이며 일반적으로를 취소 할 이유가 없으므로 git fetch병합 커밋 을 취소하는 방법을 묻는 것처럼 들립니다. 다음 중 하나를 대답은 다른 커밋과 동일 git reset또는 git revert. 내용은 게시되지 않은 변경 git reset일반적으로 가장 좋은 방법입니다; 다른 사람들이 이미 가지고있는 변화에 git revert대해서는 더 나을지 모르지만 Linus Torvald의 병합 복귀에 대한 조언을 참조하십시오 : kernel.org/pub/software/scm/git/docs/howto/…
torek

2
@WeDoTDD : 질문을 이해하지 못합니다. 거기를보기위한 명령의 수는 (그래프를 저지하다 gitk, git log --graph또는하지 않고 --oneline, 등등) 당신은 할 수 git show또는 git show -m병합 커밋 또는 사용 git diff. 이 모든 경우에 명령 행에 명령을 입력 할 때 프로그램을 지정합니다.
torek

1
@torek : git checkout branch 다음 git pull origin master를 시도했지만 커밋 히스토리와 메시지를 사용하여 로컬로 업데이트 한 다음 로컬로 다시 커밋 해야하는 단일 변경으로 모든 마스터 변경 사항을 가져 왔습니다. 마스터와 분기로 전환하면 "git rebase master"는 해결하기 위해 모든 충돌로 작업을 수행 한 다음 "git pull --rebase"에 추가하고 모든 충돌을 다시 처리 한 다음 git push origin branch를 정렬합니다. 더 좋은 방법이 있어야한다고 생각합니다-맞습니까?
user10556443

1
@ torek : 나는 얻은 결과가 반복적 인 rebase & merge & ...를 처리하도록하는 번거로운 프로세스라는 것에 동의합니다 ... 매스터로부터 업데이트를 원할 때마다 ...하지만 제안 된 방법은 많이 있습니다. 마스터 커밋 순서 / 이력을 유지하지 않고 로컬 지점에서 커밋되지 않은 단일 변경으로 모든 변경 사항을 쉽게 처리 할 수 ​​있습니다. "fetch"를 사용하고 "pull"등을 사용할 필요없이 마스터를 추적하는 더 나은 제안을 배우게되어 기쁩니다.
user10556443

14

상황 : 현지 지사에서 근무하고 있지만라는 개발 지사의 업데이트를 계속 유지하고 싶습니다 dev.

해결책 : 일반적으로 다음을 선호합니다.

git fetch
git rebase origin/dev

15
일반적으로 면책 조항을 사용하면 리베이스는 로컬 브랜치가 로컬 전용 인 경우에만 수행되어야합니다.
Locus

8

이것은 나를 위해 일했습니다. 마스터에서 내 지점으로 최신 코드를 가져 오기

git rebase origin/master


git fetch origin먼저 잊지 마십시오 .
lenooh

3

시나리오 :

마스터 업데이트와 브랜치 업데이트가 있습니다. 저는 지사가 rebasing으로 마스터를 추적하고 모든 기록을 올바르게 추적하기를 원합니다. 내 지점 Mybranch에 전화합시다.

해결책 :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch
  • 상황과 git 힌트에 따라 git mergetool &, git rebase --continue, git rebase --skip, git add -u와의 모든 충돌을 해결해야합니다.

(Tzachi Cohen이 제공 한 마지막 단계에 대한 수정은 "-f"를 사용하여 git을 "서버에서 히스토리 업데이트"로 강제 함)

이제 브랜치는 master 및 rebased와 정렬되어야하며 원격 업데이트도 가능하므로 git log에는 "뒤에"또는 "앞으로"가 없으므로 모든 로컬 충돌 * .orig 파일을 제거하여 폴더를 "깨끗하게"유지하십시오

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.