배경

프로젝트를 진행하면서 자연스레 협업을 위해 git을 사용했다. git을 단순히 저장소의 버전 관리 용도로 사용하긴 쉽지만, 팀원들과 함께 협업을 위한 툴로 사용하기엔 많은 룰을 정해야 했다.

완벽한 정답은 없고 완벽한 프로젝트도 없지만 프로젝트를 거치면서 git을 어떻게 하면 조금 더 잘 쓸지 고민해본 부분을 작성했다.

Git를 사용한 프로젝트

처음으로 시작한 프로젝트는 제대로 된 git 전략도 없이 시도했고, fork를 하면서 작성했던 커밋들은 툭하면 충돌이 발생했다. 명목뿐인 PR이 이뤄졌고, 말 그대로 저장소로 GitHub를 사용했다. 프로젝트를 진행하면서 점점 버전 관리가 힘들어지고 git을 사용함에 룰이 필요하다고 절실히 느꼈다.

두 번째 프로젝트

브랜치 전략 설정

다음 프로젝트에서 제일 처음 시작한 부분은 fork를 버리고, 하나의 공통 레포에서 브랜치를 사용했다. 동아리 활동을 하면서 작성한 레포였고, 선배들에게 우린 Git-flow를 사용하고 있어요를 추천 받아 읽고 적용하기 시작했다.

브랜치 네이밍

기능 단위로 팀원들이 개발을 담당하면서 개발하는 기능 단위로 브랜치 네이밍을 정했다. 개발 초기엔 잘 나뉘어 이뤄졌지만, 프로젝트의 기간이 길어지면서 단점이 생겼다.

• 너무 많은 양의 브랜치가 남는다
  기능 단위로 정했기 때문에 해당 기능에 수정이 발생한 경우가 있어 브랜치를 삭제하지 못하고 남겼고, 그 결과 너무 많은 브랜치를 남기게 되었다. 또 브랜치를 다시 상위 브랜치와 동기화시키면서 커밋 히스토리가 보기 힘들어진다는 문제가 있었다.

• 브랜치명을 정하기 힘들다
  기능 단위로 나누다 보니 기능 수정을 위해 새로운 브랜치를 생성하기엔 이름이 중복되는 경우가 많았다.

3 way-merge

프로젝트 내에서 fast-forward를 하지 않고, Pull Request와 3 way-merge를 최대한 활용했다.

3 way-merge는 merge 대상과 fast-forward 관계로 브랜치가 정리되더라도 강제로 merge 커밋을 생성하는 방식으로 실행하면 아래와 같은 그림이 된다.

$ git merge --no-ff <branch name>

장점

• merge에 대한 정보뿐만 아니라 브랜치에서 진행한 내용을 커밋 단위로 확인할 수 있다

• 문제가 발생한 커밋에 대해 되돌리기 쉽다

단점

• 커밋 히스토리가 복잡해진다
  사진에서 머지 커밋의 메시지를 지정하지 않았지만.. 메시지를 작성하더라도 브랜치 내역 전체가 남으면서 전체적인 히스토리가 길고 복잡해진다.

• 생각보다 세세한 내역의 히스토리를 찾지 않는다
  대부분의 코드 문제는 컴파일 과정에서 찾아지고, 각 브랜치에서 담당자가 테스트를 마친 후 PR을 진행하기 때문에 설정 파일 등의 환경 차이에서 문제가 발생한다. 대부분은 커밋을 거슬러 올라가 찾기보단 새로운 해결법을 적용하는 방식으로 진행했다.

현재 프로젝트

이슈 관리

이전 프로젝트를 끝내고 현재 프로젝트를 진행하면서 이슈 관리 방식을 도입했다. GitHub Issue나 JIRA를 사용하여 이슈를 관리하고 그에 대해 이슈 번호를 붙여 진행하고 있다.

브랜치 네이밍

이슈를 도입하면서 브랜치명을 feature/3과 같은 방식으로 이슈 번호를 사용하여 정했다. 이슈를 통해 주요 업무 내용과 담당자를 정했고 이를 확인하여 브랜치를 관리하는 방식을 사용했다.

이슈와 연계하여 브랜치를 정하면서 이전 프로젝트의 문제였던 동일 기능에 대한 브랜치 문제를 해결할 수 있었다. 이슈에서 업무 내용을 기술하고 있기 때문에 동일 기능이라도 다른 이슈 번호를 통해 네이밍을 다르게 설정하면서 문제를 해결했다.

뿐만 아니라 이름 중복이 삭제되고, 이전 브랜치를 다시 동기화하며 사용할 이유가 없어지면서 종료된 이슈에 대한 브랜치를 삭제함으로 브랜치의 개수를 관리할 수 있었다.

Squash Merge

현재 프로젝트에선 Squash Merge를 활용하여 이력을 관리하고 있는데, Squash Merge를 활용하는 경우 아래의 그림처럼 브랜치의 커밋 내역이 하나의 커밋으로 압축되어 브랜치에 머지된다.

Merge 외에도 rebase interactive 모드를 사용하여 여러 개의 커밋을 하나의 커밋으로 압축하여 Squash Merge 시 생성되는 머지 커밋과 동일하게 생성할 수 있다.

$ git merge --squash <branch name>

장점

• 커밋 히스토리가 깔끔하다
  머지된 브랜치는 하나의 커밋만 진행되기 때문에 해당 브랜치에서 확인하면 다른 브랜치 없이 하나의 큰 줄기로 커밋 단계를 확인할 수 있다

• 이슈 단위 브랜치 사용 시 관리가 편해진다
  종료된 브랜치는 재사용할 염려가 없고, 머지된 내역은 Squash 되어 관리되므로 종료된 이슈에 대한 브랜치를 삭제하기 쉬워진다

단점

• 커밋 단위의 복구가 어렵다
  커밋이 하나의 커밋으로 압축되기 때문에 커밋 단위로 빠른 복구를 진행하기 어렵다.

• 이름이 못생겨진다
  커밋하면서 열심히 정한 메시지가 다 커밋의 Body로 들어가게 된다.

마무리

Rebase Merge도 있으므로 또 고민이 생기면 시도해보겠지만 현재 프로젝트에서 Squash Merge로 꽤 만족스러운 히스토리 관리가 이뤄지고 있다고 생각한다.

Squash Merge는 커밋 레벨의 확인이 어렵고, 복구가 어렵다고 많이 들었다. 하지만 사용하면서 커밋 단위를 기능으로 잘 나누었다면 Merge 커밋도 기능 단위로 관리되므로 확인이나 복구도 쉬울 것으로 생각된다.

하지만 완벽한 기술은 없고 프로젝트 초기에 내 눈에만 완벽해 보이기 때문에 전략을 설정함에서 프로젝트의 성격 및 팀 내 정책에 따라 잘 반영하는 것이 중요하다고 생각된다.