좋아, 나는 github의 프로젝트에 기여하고 있습니다. github의 프로젝트는 upstream, github의 분기 저장소는 origin, local컴퓨터의 저장소입니다.
git checkout -b feature
# Working on feature
git commit -a -m 'only commit on feature'
그런 다음 풀 요청을 제출합니다.
git push origin master
풀 요청을 검토하고 관련없는 변경을 수행해야합니다. 다른 사람이 커밋하고 병합합니다.upstream/master
이제 upstream메인테이너가 “내 풀 리퀘스트를 마스터 위에 리베이스”하라는 요청을 받았습니다.
이것이 제 이야기입니다 (법과 질서 음향 효과 삽입) …..
풀 요청을 변경하지 않았으며 분기 기능에 대한 동일한 커밋을 수행했습니다.
git checkout master
git fetch upstream
git checkout feature
git rebase master
=> "Current branch feature is up to date."
git push origin feature
=> "Everything up-to-date"
이해가 안 돼요. upstream/master내 pull 요청을 푸시 한 후 누군가 커밋하고 병합했다는 것을 알았을 때 이것이 어떻게 가능 origin/feature합니까?
이 상황에서 올바른 절차가 무엇인지 말해 줄 수 있습니까?
답변
업스트림 저장소에서만 가져 오기를 표시합니다. 실제로 로컬 브랜치를 업데이트하지 않습니다. 에 대한 지식 만 업데이트합니다upstream . 에 리베이스하기 전에 a와 같이 upstream/master완전히 병합 되었는지 확인 하거나 단순히에 리베이스해야합니다 .mastergit pullmasterupstream/master
즉 :
git checkout master
git pull upstream master
git checkout feature
git rebase master
또는
git checkout feature
git rebase upstream/master
최신 정보:
로컬 feature브랜치를 수정 한 후에는 다시 푸시 origin하여 풀 요청 업데이트를 완료 해야합니다 . feature이미 한 번 푸시 push했기 때문에 리베이스가 기록을 변경하고 더 이상 빨리 감기가 아니기 때문에 다시 는 할 수 없습니다 . 일반적으로 푸시가 “빨리 감기가 아닌”상태에서 실패하는 경우 풀을 수행하여 해결할 수 있지만 풀은 두 가지 다른 이력을 결합 할 뿐이며 이는 확실히 원하는 것이 아닙니다. 즉, 이전 (사전 리베이스) feature브랜치가 새 (포스트 리 베이스) 브랜치와 결합됩니다. 새 분기 의 상태 로 덮어 쓰고 origin/feature 이전 feature분기의 모든 레코드를 덤프 하려고합니다 . 즉, 빨리 감기가 아니더라도을 사용하여 강제로 푸시를 수행하고 싶을 것 git push -f origin feature입니다. 노트 :위험 하며 커밋을 잃을 수 있습니다. 리베이스 이전 feature브랜치 에서 의도적으로 오래되고 쓸모없는 커밋을 삭제하려는 경우와 같이 수행중인 작업을 확실히 알고있는 경우에만 사용하십시오 .
답변
이제 업스트림 관리자가 “내 풀 리퀘스트를 마스터 위에 리베이스”하라는 요청을 받았습니다.
2016 년 9 월 이후로 메인테이너는 스스로 리베이스를 실행할 수 있습니다.
“리 베이스 및 병합 풀 요청 “을 참조하십시오.
새로운 “Rebase and merge”옵션을 선택하면 풀 리퀘스트 브랜치의 커밋이베이스 브랜치의 끝으로 리베이스되고,베이스 브랜치 자체가 새로 리베이스 된 헤드로 빠르게 전달됩니다. Rebases는 저작자 정보를 그대로 유지하면서 자동으로 리베이스 커밋의 커미터를 현재 사용자로 설정합니다. 풀 리퀘스트의 분기는이 작업으로 수정되지 않습니다.
충돌로 인해 리베이스를 수행 할 수없는 경우 필요에 따라 수동으로 해결할 수 있도록 알려드립니다.
