기존에 사용하던 방식에서 새로운 방식으로 git 사용을 좀 더 구체화해서 컨벤션을 맞추고 들어갔을때 처음 사용해본 Squash and Merge에 대한 내용과 과정을 공유해보려한다.
기존 방식과 문제
브랜치 관리
로컬에서
pullmerge모두 하고 remote의 dev/main 브랜치에 push 하는 방식을 사용했다.
(local) develop -> (local) feat/브랜치 -> (local) develop merge -> (remote) develop push 기존에 개발 단계에서 위와 같은 단계를 사용하고 있었다.
깃을 써봤다면 이렇게 사용하면 협업을 아예 고려하지 않는건가?
라는 생각을 할 수 있는데 어느정도 맞다.
사실상 몇달간 거의 혼자서 개발을 하고 코드리뷰도 merge 전에 gpt에게 물어보는 방식을 써서 나혼자만의 프로세스를 만들어 놓은 상태여서 remote feat나 fix 브랜치 관리와, PR 과정이 불필요하다고 생각해서다.
하지만 이제는 협업을 어느정도 고려해야돼고, 제대로된 브랜치 관리를 해보자
새로운 방식
브랜치 관리
올바른 사용 방식으로 이제는 개발 파생 브랜치를 remote에 올리고 PR을 날리는 형식을 만들었다. 이 과정에서 label, project, milestone 등 태그를 하여 읽기에 수월하게 만들었다.
(local) develop -> (local) feat/브랜치 -> (local) develop pull -> (local) feat/브랜치 merge -> (remote) feat/브랜치 push -> (remote) develop PR
이렇게 브랜치 방식을 한번더 재정의해서 사용했다.
Squash and Merge
PR 머지에서 Squash and Merge 방식을 사용했다.
이유는 이러하다.
- 기존의 커밋 로그가 너무 많다.
- 추적이 어렵다
참고로 ISSUE 를 이제 제대로 버그, 기능, 리팩토링, 테스트, 성능 향상 등 관리하기로 했다. 그러다보니
이슈 단위로 나눠지면 해당 PR의 다수의 커밋이 하나의 PR 단위로 커밋이 되면 버그나 기능 단위는 ISSUE에서 파악이 가능하니 커밋은 간략히 봐도 문제 없다.
이게 우리의 결정이었다.
ps.
그렇기 때문에 PR을 날린 브랜치를 develop에서 pull을 받은 상태에서 삭제하려면 강제 삭제 명령어로 해야한다.
(커밋 ID가 develop의 Squash and Merge 커밋으로 새로 만들어져서)
이 Squash and Merge 방식 이후 생긴 문제가 두가지 있다.
PR에 이전 커밋이 계속해서 등장
나도 모르게 feat나 fix 브랜치에서 develop으로 돌아가 브랜치를 머지했을때
해당 PR이 미래의 PR에도 계속 커밋이 등장한다.
(맨 아래 style: - 커밋 제외한 과거 커밋들이 쌓여있는 모습 )
문제는 Squash and Merge 때문에 생긴 문제였다.
#
fix or feat : C -> D
develop :A (remote head) -> B -> -> E (Squash and Merge 요약 커밋)만약 위 상황에서 B 커밋이 develop에 커밋 돼있고,
C - D 가 브랜치에서 합쳐져서 PR이 올라가 Squash and Merge 했을때 E라는 커밋 에는 B-C-D의 내용이 합쳐져 있는데 develop에서 pull 을 받았을 때는 B 커밋은 결론적으로 develop의 커밋으로도 존재하고 squash and merge 에도 포함돼있고 remote에는 B 커밋은 squash and merge 의 E 커밋 안에만 존재한다.
이렇게 생긴 문제였다. 이거를 해결한 방법으로는 한번 Squash and Merge 가 아닌 Merge Commit 으로 한번 B 커밋을 local develop을 remote develop 브랜치와 싱크를 맞춰주는 방법을 사용했다.
Hotfix 이슈
Local develop -> Remote develop 에서 Squash and Merge 전략을 사용하고,
개발이 끝나 Remote develop -> Remote main 서버로 Squash and Merge 전략을 사용했을때
만약 main에 hotfix 가 일어난다면 생긴 문제다
우리는 hotfix 브랜치를 사용할때 전략을 사용할때 main 서버에서 hotfix 서버를 파생 시켜 수정을 진행하고, main 서버와 develop 서버 모두 PR을 날려 main서버와 develop 서버의 싱크를 맞춘다.
여기서 hotfix에 대해서 develop에 PR을 날렸을때 commit이 너무 길어진다.
난 맨 아래에 존재하는 hotfix 커밋 하나만 했는데 remote develop -> remote main 브랜치에서 합쳤을때 생긴 요약 Commit의 하위에 hotfix 커밋이 들어가서 길어지는 문제이다.
이 문제는 remote develop -> remote main에 커밋을 할 때는 Merge Commit을 사용하기로 해서 이미 요약된 커밋을 한번 더 요약하지는 않고 그대로 merge 커밋을 쌓는 방식을 선택했다.
후기
깃허브 공부 오랜만에 많이 했다. 생각보다 내가 쓰던거만 쓴거 아닌가라는 생각도 했다.
오픈소스 기여에 노력했을때 봤던 것처럼 우리의 리포지토리도 프로젝트, 라벨, 마일스톤 등으로 관리 돼서 예뻐서 보기도 좋아 볼 때마다 뿌듯함을 느낀다.
