Git한테 호되게 혼난 후 고찰

<Git 시행착오 과정> 

 

상대 참조

: Git의 log를 확인하는 과정에서, 커밋 해시를 사용하지 않고 커밋의 현재위치를 기준으로 특정 커밋을 지정할 수 있다. 

 

1. ^ : 한번에 한 커밋 위로 움직임

2. ~<num> : 한번에 여러 커밋 위로 올라감

 

ex) master^^  : master 브랜치의 조부모

    git checkout HEAD~4  : 현재 커밋을 기준으로 4번 위로 이동

 

 

https://wormwlrm.github.io/2020/09/03/Git-rebase-with-interactive-option.html

Git Rebase --Interactive 옵션 알아보기 - 재그지그의 개발 블로그

 

 

커밋 시 

> git commit

입력 후. 아래와 같이 작성하기. 

[feature/#67] 대댓글 UI 추가                   // header : [branch name] + title

- 대댓글 컴포넌트 생성                                     // body
- 댓글 컴포넌트에 대댓글 컴포넌트 달 수 있게 변경

resolves: #67               // footer
see also: #56, #49

 

 

 

Feature/#25라는 브랜치에서 작업을 하다 dev 브런치와의 rebase를 시도함. 

근데 Feature/#25에서 작업해놓은 커밋이 워낙 많다 보니까,  한 커밋을 옮길 때 마다 dev에서 Conflict가 엄청나게 생기게 된다. 

그래서 그것을 다 해결하지 못하여 git rebase --skip 명령어를 쓰게 되었고, 그 탓에 커밋 몇개가 누락되는 엄청난 ! 일이 발생했다. 

rebase를 끝낸 나의 Feature/#25는 내가 이전에 작성했던 코드를 유실하게 되는 일이 벌어졌고, 나는 이를 무마하고 싶어서 rebase를 reset하였다. 

이 reset도 처음부터 잘 된건 아니고, 이상한 지점을 잡아 reset하고 헛짓거리 하다가, 팀장님이 rebase하기 전 지점을 발견해주어서 겨우 완성했다... 

 

그리고 두번째 문제점 ! 커밋 메세지들이 모두 규율을 지키지 않고 제멋대로였다.

형식을 지켜서 다시 reword, 혹은 drop commit을 진행한 다음 깔끔하게 커밋 히스토리를 정리하였다. 

 

그 다음에 Feature/temp라는 브랜치를 따서 Cherry-pick을 이용하여 모든 커밋을 옮겼다. 

 

git checkout Feature/#25
git cherry-pick commit^ commit commit

커밋이 너무 많아서 커밋 해시를 따서 나열하는 게 상당히 귀찮았다 ,, 

 

이때 temp 브랜치는 dev의 최근 커밋에서 따서 형성하였다. 

 

 

느낀점 .. 

 

1. 커밋 히스토리는 깔끔하게. GitHub Flow에 맞추어 관리한다. 

 

2. dev 브랜치와의 Merge를 생활화하자. 항상 작업하기 전에 dev 주 브랜치의 update 사항이 있는지 확인, Pull 후 rebase 하여 작업할 것 . 

 

3. Rebase 함부로 하지 말기 .. conflict나면 최대한 해결하면서 continue하고 skip따위 절대 결코 하지 않기 !!