step3
브랜치에서 PR 보낸 상태. upstream
에서 merge
는 아직 안되었고 git rebase upstream/honeySleepr
도 아직 안한 상태.merge가 되기 전에 브랜치를 만들어서 작업하면 다음 PR 시 어떻게 되는지 테스트해보기 위해 test
브랜치를 만들어서 커밋을 하나 만들었다.
git switch honeySleepr
로 브랜치를 honeySleepr로 이동 해준 뒤git fetch upstream honeySleepr
를 했을 때의 로그 상태. upstream을 참조하는 새 브랜치(upstream/honeySleepr)가 생겼다.git rebase upstream/honeySleepr
upstream/honeySleepr와 honeySleepr가 머지된 모습 여기서 rebase 대신 git merge upstream/honeySleepr
해줬어도 결과는 같았을 것이다.
(honeySleepr : A->B / upstream/honeySleepr : A->B->C 상태였기 때문에 fast forwarding이 되기 때문이다)
그렇기 때문에 이 경우에는 fetch->rebase 또는 fetch-> merge 하지 않고
git pull upstream honeySleepr
한방으로 해결 할 수도 있다. (pull = fetch + merge 이라고 이해하면 되는 것 같다)
이제 기존에 작업했던 step3 브랜치는 지워주고, 현재 HEAD 위치에서 새로 브랜치를 파서 다음 작업을 진행하면된다
삭제를 안하고 step3 브랜치를 HEAD 위치로 옮겨오면 그대로 이어서 될 것 같긴한데.. 그러면 커밋들도 정리해야하고, 원격 저장소로 push 할때도 충돌이 날 것 같고 정신이 없어지기 때문에 괜히 그러지 말자.
git branch -D step3
step3 브랜치가 분기가 되어 있기 때문에 -d
가 아닌 -D
명령으로 강제로 지워줘야 한다.
git push origin -d step3
원격 저장소의 step3 브랜치도 필요가 없으므로 삭제해준다.
이 작업은 PR 받는 github 에서도 할 수 있다. merge 승인 후에 브랜치 지우기 버튼이 생기는데 그걸 누르면 똑같이 처리된다.
refs/stash
라고 되어 있는 부분의 분기된 커밋 3개는 test 브랜치에서 작업 중이었지만 커밋은 아직 안한 변경사항들을 git stash
를 사용하여 임시 저장한 것이다위 경우 test 브랜치가 남아있기 때문에 여전히 분기된 상태로 남아있다. test 도 지우게 되면 깔끔하게 아래 커밋 3개만 남겠지만, test에서 작업한 커밋(5225ecf)이 있으므로 이 커밋을 honeySleepr 브랜치에 이어 붙이는 것을 연습해볼 것이다.
git switch -c step4
-c
는 브랜치를 만드는 명령어이다git cherry-pick 커밋번호
해당 커밋을 현재 HEAD 위치 뒤에 이어붙인다. (여기서는 git cherry-pick 5225ecf
)
-d
명령어를 쓰면 merge가 안돼서 삭제가 안되므로git branch -D test
- 참고용 (위에 내가 정리한 것 살짝 다름)
pr 제출 후
git switch -C 다음스탭브랜치
작업진행
갓눅스의 머지 승인
git switch 깃헙아이디
git pull upstream 깃헙아이디
git push origin 깃헙아이디
git switch -C tmp
git cherry-pick 엄청난커밋들
git switch 다음스탭브랜치
git reset --hard tmp
git branch -D tmp(by @JERRY)