Git으로 협업하면서 들었던 생각들을 한번 정리 해보았습니다.

되도록 Rebase

이것은 개발자마다 의견이 가리는 부분입니다. git rebase 설정을 인지하지 못하고 사용하다보면
간혹 작업물을 날릴수도 있고, 충돌을 해결하는 것이 쉽지 않을 수도 있습니다.

그러나 많은 merge는 git graph를 복잡하게 만들어 Git 히스토리를 파악하기 힘들게 합니다.
Git을 사용하는 목적은 히스토리 관리입니다. 그래서 되도록 rebase를 선호합니다.

커밋의 단위와 의미

일정이 빠듯하여 빠르게 개발하다 보면 같은 내용의 작업을 여러 커밋으로 나눌 때가 있습니다.
한 사이클 내에서 이루어지는 작업이라면 되도록 작업 내용과 커밋이 1대1로 대응하는 것이 좋습니다.

정말 이것이 그토록 중요할까? 라고 생각을 할 수도 있습니다. 저 또한 과거에 그랬기 때문입니다.
서비스의 규모는 점차 성장하고 그에 따라 코드의 양도 많이집니다.
그렇기에 시간이 지날수록 이 규칙은 중요해집니다.

그리고 이 규칙대로 커밋을 하다보면 자연스레 각각의 커밋은 의미를 지니게 됩니다.
먼저 작업 내용을 계획하고 각각의 작업이 커밋으로 만들어지기 때문입니다.
그럼 작업 단위로 커밋을 하였는데 이전의 작업 내용을 변경해야 한다면 어떻게 할 수 있을까요?

스택 브랜치

Stacked PR 또는 Stacked branch 라는 개념은 들어보셨을 수도 있습니다.
작업의 단위를 브랜치로 나누되 이전 작업 브랜치를 기반으로 새로운 작업 브랜치를 만드는 전략입니다.

이 전략은 이전 작업 브랜치가 변경된다면 다른 작업 브랜치들을 순차적으로 rebase 해야합니다.
더 편리하게 이 전략을 쓰고자 한다면 Graphite라는 라이브러리는 사용 할 수 있습니다.
이 라이브러리는 gt cli를 통해 스택 브랜치들을 손쉽게 만들 수 있고, 특정 작업 브랜치가 변경이 생기면
자동으로 그와 연결되어 있는 작업 브랜치들을 rebase 합니다.
다만 gt cli의 명령어들을 익혀야하는 단점이 있습니다.

GitButler

GitButler은 새로운 전략을 제시합니다.
하나의 브랜치에서 여러개의 작업을 동시에 진행하고 각 작업 내용을 가상 브랜치라는 곳에 올릴 수 있습니다.
각각의 가상 브랜치는 추후 실제 브랜치로 만들 수 있고 최종적으로 메인 브랜치에 병합 할 수 있습니다.

예를 들어 스타일 변경 작업과 비즈니스 로직 변경작업을 병행한다 했을때
스타일 작업을 하다가 비즈니스 로직을 수정하는 것은 어렵지 않습니다.
각 작업 커밋을 목적에 맞게 가상 브랜치로 옮기기만 하면 됩니다.
그리고 가상 브랜치 내에서도 동일한 작업이 여러 커밋으로 나누어져 있다면
손쉽게 squash도 가능하여 불필요한 커밋을 없앨 수 도 있습니다.

만들어진지 얼마되지 않아 아직 버그가 많이 존재하지만
도구가 좀 더 성숙해 진다면 GitButler를 이용해 작업해 볼 계획입니다.

Git

순수하게 Git에서 제공하는 기능으로 관리하는 전략입니다. 커밋 명령어를 수행시 --fixup 이라는 옵션을 통해 특정 커밋에 연결 할 수 있고
rebase를 통해 자동으로 커밋이 합쳐질 수 있게하여 작업과 커밋이 1대1이 되도록 할 수 있습니다.

# 특정 커밋과 해당 커밋을 연결합니다. 자동으로 커밋 메세지 앞에 fixup! 문자열을 넣습니다.
git commit -a -m 'change comment' --fixup=<이전 주석을 변경한 커밋 해시>

# autosquash 옵션은 rebase 시에 fixup! 이라는 메세지가 존재하는 커밋을 연결된 커밋과 자동으로 합칩니다.
git rebase --autosquash <base 커밋 해시>