마스터 브랜치에 반영되면 안 될 커밋들이 들어갔을 때 해결방법.
예를 들어, 작업 중인 기능을 약 한 달 동안 개발했다. 이 브랜치를 master 브랜치에 머지했다고 하자.
origin에 push 하지 않았다면 별 문제 없이 현재 로컬에서의 master 브랜치를 force delete하고 (origin 말고 로컬에서만 삭제하자.) origin에 있는 master 브랜치를 다시 pull 땡기면 된다.
그런데 이런 경우 말고 origin에 벌써 push를 했다고 해보자.
[그림 1]
예를 들면 [그림 1]과 같다.
분홍색 지점이 개발 중인 브랜치(리얼에 나가면 안되는 브랜치)가 master 브랜치에 합쳐진 시점이다.
우선 master에 반영된 브랜치 중 분홍색 지점 이전에 마스터에서 분기한(branch 생성한) 브랜치를 하나 선정한다. (최근꺼일수록 좋다)
[그림 1]에서는 선정한 브랜치가 featureA가 된다.
이 브랜치를 master 브랜치로 대체할 것이다.
[그림 1]의 커밋들 중 마스터에 반영되어야 할 커밋들은 잘못된 머지로 인해 마스터에 반영된 commit9, commit10을 제외한 모두이다.
이 중 commit 6, 7, 8은 이미 featureA에 반영되어 있으므로
commit1, commit2, commit3, commit4를 차례대로(커밋된 순서대로) featureA 브랜치에 cherry pick으로 해당 커밋들만 반영한다.
merge된 시점이 commit1, 2가 반영된 뒤라고 commit3, 4만 cherry pick 하면 안된다는 걸 명심하자.
commit1,2도 featureA에는 없으므로 챙겨줘야 한다.
merge된 시점이 아닌 분기된 시점 이후의 커밋들을 모두 체리픽해줘야 한다.
[그림 2]
얼핏보면 featureA에 commit10이 있는 것 같아 보이지만 featureA 브랜치는 잘못된 브랜치가 머지되기 이전에 마스터 브랜치를 기준으로 만들어 졌기 때문에
featureA 브랜치에는 [그림 2]와 같이 commit6, 7, 8만 있다.
cherry pick 으로 featureA에 변경사항들을 반영했으면 이를 master 브랜치로 대체해야 한다.
git checkout master | cs |
master 브랜치로 체크아웃 한다.
git reset --hard featureA | cs |
현재 브랜치(master)를 featureA 브랜치로 리셋한다.
git push -f origin master | cs |
로컬의 master 브랜치를 origin에 강제 push 한다.
이제 원격에 있는 master history는 위와 같을 것이다.
master 브랜치는 항상 조심 또 조심하자.
참고 : 현재 Git 브랜치를 마스터 브랜치로 만든다.
'GITHUB' 카테고리의 다른 글
[GITHUB] Slack 연동 (0) | 2018.12.31 |
---|---|
[GITHUB] 커밋 합치기 (rebase) (1) | 2018.12.28 |
github ssh 연동 (0) | 2018.12.17 |
[GITHUB] Repository 생성 ~ Git clone 까지 (0) | 2018.11.28 |
github push할 때 Jenkins 자동 빌드 설정 (0) | 2018.11.10 |
댓글