문제상황
깃을 이용하여 협업을 하면 기능 단위로 나누어 일을 분배해 Develop이나 Main 브랜치로 합치는 방식으로 일을 하게된다. 순서가 아래와 같다고 해보자.
순서: 홈페이지 -> 회원가입 기능 -> 로그인 기능 -> 게시판 기능
A, B, C, D 이렇게 4명이서 순서대로 일을 나누어가졌다. 이제 다들 git checkout을 통해 main으로부터 분기해 Feature 브랜치에서 작업을 시작할 것이다.
그런데 만약 C가 성격이 매우 급해서 login_feat 브랜치를 누구보다 빨리 만들었고, 작업도 빨리 끝내 다른 사람들의 작업을 기다렸다고 해보자.
모든 사람들이 일을 끝마쳤고 A부터 차례대로 Develop 브랜치에 합치기 시작한다.
그런데 이게 웬걸? 모든 사람들이 merge 작업을 수행하고 나서 git log를 통해 작업을 확인했더니, 작업 결과물의 커밋이 가장 빨랐던 login_feat의 커밋이 가장 상위에 위치해있다. 이렇게 되면 git history가 굉장히 보기 불편할 것이다.
로그 순서: 로그인 기능 -> 홈페이지 -> 회원가입 기능 -> 게시판 기능
해결방법
그렇다면 git history를 순서에 맞게 기록하려면 어떻게 해야할까? git rebase만 잘 활용해도 아주 예쁘게 만들 수 있다.
계획했던 순서대로 홈페이지 -> 회원가입 기능 -> 로그인 기능 -> 게시판 기능 순으로 아래 과정을 반복하면 된다.
git checkout을 통해 해당 브랜치로 이동해 $ git rebase dev 를 통해 dev에 병합된 기록을 해당 Feature 브랜치로 가져온 다음 merge를 진행하면 순서대로 기록할 수 있다.
$ git checkout 해당브랜치(feat)
$ git rebase dev
$ git checkout dev
$ git merge --no-ff 해당브랜치(feat)
이제 깃로그를 확인해보면 아래와 같이 커밋도 계획했던 순서대로, merge기록도 순서대로 남을 것이다.
$ git log
commit 6ddefb28b1032559fb262c3265274e471f2a006f (HEAD -> dev)
Merge: ddb77a4 807cf3e
Author: BigBell <pythonstrup@gmail.com>
Date: Sat Feb 26 18:04:09 2022 +0900
Merge branch 'board_feat'
commit 807cf3e25edabdb82142d0d1ff85b8eebda2affe (board_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Sat Feb 26 18:03:31 2022 +0900
게시판 기능
commit 6ddefb28b1032559fb262c3265274e471f2a006f
Merge: ddb77a4 807cf3e
Author: BigBell <pythonstrup@gmail.com>
Date: Sat Feb 26 18:04:09 2022 +0900
Merge branch 'login_feat'
commit 807cf3e25edabdb82142d0d1ff85b8eebda2affe (login_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Sat Feb 26 18:03:31 2022 +0900
로그인 기능
commit ddb77a47cac1c08a66d91e9efda7617b82f7121b
Merge: f058fe4 156e0c1
Author: BigBell <pythonstrup@gmail.com>
Date: Sat Feb 26 18:00:36 2022 +0900
Merge branch 'join_feat'
commit 156e0c167e1ce9c470d31a68e1244148625b636b (join_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Sat Feb 26 17:59:56 2022 +0900
회원가입 기능
.......
주의사항
git rebase 명령으로 인해 커밋에 변화가 생길 수 있기 때문에, Develop 브랜치나 Main 브랜치에서는 사용하지 않도록 주의하자. Featrue 브랜치(Topic branch)에서만 사용하는 것이 바람직하다.