인턴기간 동안 업무를 수행할 때 당연히 Git을 사용했다. 인턴을 하며 동시에 DDD 동아리 활동도 하고 있는데 양쪽 모두 나름의 Git Flow가 있어서 플로우를 따라 작업을 했다.
Git Flow를 따라 작업한게 이번이 처음은 아니다. 그런데 이전에 사용 했을 때와 이번 인턴과 동아리 활동 때와는 다르다. 이전에 사용 했을 때는 코드 리뷰가 없었고 중간 데모가 없었다.
이번에는 코드리뷰가 있었고 중간 데모가 있었다. 그렇다면 코드리뷰와 중간 데모가 있고 없고의 차이는 뭘까?
코드 리뷰의 있고 없고의 차이는 누군가가 내 코드를 반드시 봐야한다는 사실이다.
중간 데모는 개발중인 서비스가 목표한 기능까지 완벽하게 동작하는 상태를 유지해야 한다는 뜻이다.
이는 상당히 어려운 작업이다. 컴공 쪽에는 데모 귀신 이라는 말이 있을 정도로 데모는 개발자에게 정말 무서운 존재이다.
왜 무섭냐면 여러 명의 코드를 통합해야 하며 데모 기간이 가까울수록 각종 버그가 속출하고 빠르게 픽스된 코드를 또 통합해야 하기 때문이다. 픽스 대상 코드들이 의존성을 가지고 여러명이 작업하게 되면 정말 지옥 그 자체이다.

회사에서는 모든 PR에 필수 리뷰어가 2명으로 설정되어 있다. 또, 동아리에서는 함께 작업하는 동료 개발자 1명이 설정 되어 있다.
아이러니하게도 회사에서는 단 한번도 코드리뷰를 받아본 적이 없다. 동아리에서는 정말 꼼꼼하게 코드리뷰를 받고 있다.

위와 같은 일들을 겪으니 Git을 어떻게 사용할지에 대해서 고민을 많이하게 되었고 지금의 내가 생각하는 Git을 사용하는 좋은 습관을 적어보려고 한다.

리베이스의 생활화

팀장님께서 말씀하시기를 "리베이스를 숨쉬듯이 하라"고 했다.
맞는 말 같다. 평소에 리베이스를 습관적으로 수행해서 최신 상태의 코드로 유지한다면 데모에서 있을 통합도 무섭지 않다.
또, 회사 선배 개발자님께서 말씀하시기를 리베이스의 장점은 conflict를 로컬에서 해결할 수 있는 장점이 있는 것 같다. 고 하셨다.
conflict를 해결하고 로컬에서 충분히 테스트 후에 안정한 상태의 코드를 remote에 올릴 수 있는게 좋은 것 같다.

작은 PR 단위

PR을 작은 단위로 날리자
PR의 단위가 클 수록 리뷰할 코드의 양이 많아지고 의존성이 큰 코드를 작성할 확률이 높아지는 것 같다.
나의 거대한 PR이 머지되었을 때 다른 사람이 rebase하면 많은 conflict가 발생할 수 있고 이는 좋은 상황이 아닌 것 같다. 만약 PR의 단위가 작다먼 conflict가 나봤자 1~2개의 파일에서 날테니 상대적으로 피로도가 덜하고 올바른 판단할 확률이 높아진다.

작은 단위의 커밋

코드리뷰를 받는데 커밋 메세지가 명확하지 않았다.
커밋 메세지의 타이틀은 분명히 "폴더 생성 API" 개발이었는데 다른 부분의 코드도 수정되어 있었던 것 같다. 그냥 작업하다가 눈에 보이는 부분들을 그때그때 작업해버린 것 같다.
설령 작업을 여러 부분을 했더라도 선택적으로 스테이징하고 커밋 하는 습관을 들이는 것이 좋을 것 같다.
굳이 코드를 읽지 않아도 커밋 메세지만 읽어도 뭘 했구나 알 수 있도록 하면 좋을 것 같다.
또, 너무 작은 단위로 커밋하면 커밋 메세지를 쓰는게 너무 피곤하기도 한 것 같다.

GUI 툴을 적극적으로 활용하자

회사에서 GitKraken 라이센스를 지원해줘서 처음 사용해보고 있다.
그 전에는 sourcetree를 사용했는데 GitKraken은 확실히 부분 유료 소프트웨어라서 그런지 엄청 기능이 많다.
GUI를 사용하면 선택적으로 커밋하기 쉽고 리베이스, 머지, PR, squash 등 너무 쉽게 할 수 있다.
적극적으로 GUI를 사용해서 팀 전체의 업무를 원활하게 수행되도록 하는게 가장 좋은 것 같다.

결론: 자주 리베이스하고 작게 작업해서 자주 PR하자!