brunch

You can make anything
by writing

C.S.Lewis

by Aprilamb Apr 14. 2022

Git을 사용한 협업(2): 커밋 가이드라인

작업을 하다 보면 이쯤에서 한번 보존을 하고 싶어질 때가 있습니다. 진행하다가 다시 한번 되돌아볼 가치가 있는 지점이라는 생각이 들어서겠죠? 이럴 때 수행하는 형상 관리 관련 작업이 커밋 commit입니다. 



커밋은 보존 가치가 있는 스냅숏을 남기는 작업입니다. 위의 그림을 보시면 Git 하에서 클라이언트 쪽은 실제로 작업을 수행하는 Working Directory와 커밋으로 스냅숏을 남기게 되는 Local Git Repository 그리고, 그 중간 단계의 커밋 대상을 임시 저장하는 Staging Area가 명확히 나누어 관리됩니다. 


협업 프레임웍에 대한 이야기를 하기 전에, 먼저 협업 작업자 사이에서 어떤 경우에 커밋을 해야 하는지에 대해 명확히 정의를 할 필요가 있습니다. 형상 관리의 기본 단위가 바로 커밋이기 때문입니다. 사실 협업을 하게 될 때에는 커밋 외에도 여러 작업 방법의 기준에 대해 함께 논의를 해두는 게 좋습니다. 귀찮은 작업처럼 느껴지지만 한번 눈높이를 맞추어두면 불필요한 커뮤니케이션을 많이 줄일 수 있기 때문입니다. 


그러면, 한번 커밋에 대해 여러 가이드를 참고한 개인적인 의견을 제시해 볼까요? 이후 이 내용을 기준으로 자신의 프로젝트나 상황에 적합하게 테일러링 해서 적용하시면 도움이 될 겁니다. 


커밋 commit은 되도록이면 자주 하는 게 좋다


Git 구조 하에서 커밋은 해당 상황에서의 소스 전체의 스냅숏을 남기는 작업입니다. 언제든지 다시 이 지점으로 복원하여 작업을 새롭게 시작할 수 있다는 이야기예요. 그렇다면 커밋은 자주 하는 게 좋을까요? 아니면, 가끔 하는 게 좋을까요? 너무 애매한 이야기지만 그래도 선택해야 한다면 우선 자주 하는 게 좋다고 말씀드리고 싶습니다. 사실 프로젝트를 진행하다 보면 여러 가지 상황이 발생하죠. 지금까지 작업해온 내용 중 어떤 기능을 삭제해야 한다던가, 어느 분기에서 다른 방향으로 진행하되 이후 추가했던 기능들 중 몇 가지는 계속 가지고 가고 싶다던가 하는 것들. 이런 여러 상황에 부합하는 작업을 최소화하기 위해서는 촘촘한 커밋이 필요조건이 될 겁니다. 조금 더 명시적으로 이야기하자면 두 개의 다른 기능이라면 각각 나누어 커밋하는 게 좋다는 거예요.


테스트가 끝난 완전한 상태의 소스를 커밋 commit 한다


조금 더 조건을 구체화해보겠습니다. 보완이 필요한 불완전한 상태의 소스를 커밋해 두었다면 어떤 일이 벌어질까요? 나중에 다시 그 지점으로 돌아왔을 때, 불완전한 상태를 보완하기 위한 작업을 수행 한 이후에 다음 작업이 진행 가능할 겁니다. 그 보완 작업은 생각보다 번거로울 수 있기 때문에 되도록 - 이라기보다는 늘 - 테스트가 완료된 완전한 상태에서 커밋을 수행해야 합니다. 조금 더 엄격하게 이야기하자면, 커밋되는 소스는 실 서버에 반영이 되어도 문제가 없을 정도여야 한다는 거고요.


커밋 commit은 기능 작동이나 구조적 변화의 최소 단위별로 수행해야 한다


작업을 진행하다 보면 리펙토링이 필요하다고 판단되는 경우가 있습니다. 프로젝트 초기에는 빈번하게 발생하는 내용이죠. 이런 경우에 기능 추가/수정 작업과 구조 변경 작업(리펙토링)은 반드시 분리해서 커밋하는 게 좋습니다. 이 외에 물리적인 변화 - 소스 파일을 둘로 나눈다던지, 내용을 다른 파일로 옮긴다던지 하는 작업 - 도 따로 커밋하시는 것을 추천합니다. 


커밋 commit은 비즈니스적인 feature 단위로 진행하라


커밋되는 단위는 시스템적인 구분(백엔드, 프런트엔드, 데이터)보다는 사용자 입장에서의 기능 단위로 구분하는 것을 추천합니다. 비즈니스적 기능 작동을 위한 모든 코드들이 한 번에 커밋되는 것이 보다 효율적이라는 것은 설명이 필요 없을 겁니다. 해당 기능을 삭제하게 될 때를 생각해보면 이해가 쉬운데, 그때는 해당 기능과 관련된 모든 코드들이 사라져야겠죠?




사실 이 외에도 여러 가지 고민해볼 만한 상황이 있을 겁니다. 위에 일반화시켜 적어보긴 했지만 분명히 실제 작업 환경이나 작업자의 스킬에 따라 테일러링은 필요할 수 있습니다. 개발 스킬이 엄청나게 뛰어난 작업자라면 잦은 커밋은 오히려 비효율을 야기시킬 수도 있을 테니 말이죠. 위의 내용들을 참고하셔서 작업 상황 및 협업자들의 특성에 적합한 여러분만의 커밋 가이드라인을 만들어 보세요. 그것이 효율적인 협업 프레임웍을 구성하는데 가장 앞서야 할 태스크이기 때문입니다. 


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari