
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/honeySleeprupstream/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 step3step3 브랜치가 분기가 되어 있기 때문에 -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)