다음으로 할 일은 새로운 기능을 제공하거나 자체 전용 브랜치에서 다른 버그를 수정하는 것입니다 (포크에만 푸시 됨).
포크는 그대로 있지만 포크 안의 가지들은왔다 갔다 할 수 있다는 뜻입니다.
더 이상 기여할 계획이없는 경우 포크를 제거 할 수도 있지만 '기고 한 저장소'에서 해당 항목이 제거됩니다 .
다음이 더 쉽습니다.
- 당신의 삭제
fix(실제로, 지점 이 지금 당신을 위해 삭제를 포크에 () : 참조 "및 해당 지역의 복제의 repo에서 로컬 및 원격 힘내 분기를 삭제 ")
git pull upstream master( master수정이 통합 된 분기 인 경우 : 병합은 빨리 감기가됩니다.) :이 시점에서 리베이스가 필요하지 않습니다.- 업데이트 된 로컬 위에 수정 브랜치를 다시 만듭니다
master(이제에서 최신 버전으로 upstream master).
그러나 향후 풀 요청을 제출하기 전에 한 단계를 잊지 마십시오 .
먼저 fix업스트림 대상 분기에서 현재 분기 ( )를 리베이스합니다.
( upstream당신이 포크 한 원본 저장소 : " github에서 원본과 업스트림의 차이점은 무엇입니까 "참조 )
원본 리포지토리 ( "업스트림")에 다시 제출하기 전에 작업이 해당 원본 리포지토리 의 최신 버전 을 기반으로하는지 확인해야합니다. upstreamrepo에 다시 ).
예를 들어 " github의 공유 리포지토리에서 pull 요청을 관리하기위한 워크 플로 "를 참조하십시오 .
다시 말해서, upstream당신이 바쁘게 물건을 고치는 동안 진화 할 수 있습니다 (새로운 커밋이 푸시됩니다). 커밋이 최신 버전과 호환되는지 확인하려면 업스트림에서 최신 작업을 기반으로 수정 사항을 재생해야합니다 upstream.
OP 산토 쉬 쿠마 묻는 의견에 :
에서 upstream마스터로 가져오고 병합했습니다 . 이제 어떻게됩니까?
최근 풀 요청 이후 새로운 수정 사항을 적용하지 않은 경우 위를 참조하십시오 ( fix업데이트 된에서 새 분기 를 삭제하고 다시 생성 master).
pull 요청 이후 더 많은 작업을 수행했다면 새로운 pull 요청 upstream을 만들고 싶다면 병합하지 않을 것입니다. I would pull and rebase :
git pull --rebase upstream master
이렇게하면 내 모든 새 로컬 작업이 가장 최근 upstream master커밋 (로컬 리포지토리에서 가져옴) 위에 재생되어 master향후 풀 요청을 통합 할 대상 브랜치라고 가정합니다 .
그런 다음 내 로컬 작업을 ' origin'로 푸시 할 수 있는데, 이는 GitHub의 포크입니다 upstream.
그리고 GitHub의 포크에서 안전하게 풀 리퀘스트를 만들 수 있습니다 upstream. 병합 해결없이 새 커밋 만 추가 할 것임을 알기 때문에 리포지토리에서 새 커밋을 병합 upstream하면 간단한 빨리 감기 병합을 의미합니다.
git pull --rebase(현재 체크 아웃 된) fix브랜치 를 리베이스하려는 맨 위에 브랜치를 지정하지 않으면 A 가 작동하지 않습니다.
( git pull --rebase) 내용 :
You asked to pull from the remote '`upstream`', but did not specify a branch.
마침내 마스터를 추가해야합니까? 그리고 이것은 무엇을할까요?, 그것은 내 fix브랜치를 삭제 합니까?
예, ' master' 와 같이 pull 요청의 대상이 될 분기를 지정할 수 있습니다 . 브랜치를
삭제 fix하지는 않지만 master리포지토리에서 가져온 업스트림 위에서 재생됩니다 .
:)