[ Git ] 프로젝트를 하면서 Git Flow를 어떻게 사용을 했는가?

1. 글을 작성한 이유

안녕하세요. 제가 이번에 프로젝트를 하면서 Git Flow 방식을 어떻게 사용을 했는지 정리하는 글을 작성을 하였습니다. 물론 Git flow 방식에 대한 자료는 지금 많이 있지만 저는 프로젝트를 하면서 시중에 있는 내용을 다 이용하기 보다는 프로젝트 규모와 현재 상황에 따라 조금 다른 방식으로 진행하여 공유하면 좋다고 생각하여 글을 작성을 하였습니다.

 

2. Git VS SVN

지금까지 팀 프로젝트는 2개를 진행을 하였습니다. 처음은 국비지원에서 진행한 SVN 협업 프로젝트 그리고 지금 Git으로 진행한 프로젝트가 있습니다.

그러면 SVN과 Git에 대해서 차이점에 대해 조금 살펴보는 시간을 가지겠습니다.

Git과 SVN은 형상관리 툴로 소스의 변화를 끊임없이 관리를 합니다. 소스를 버전 별로 관리할 수 있어 개발할 때 유용성을 제공합니다. 

SVN과 Git의 차이점

- Git이 SVN과 다른 점은 분산형 관리 시스템이라는 것이다.
- SVN : 중앙 서버에 소스코드와 히스토리를 저장
- Git : 소스코드를 여러 개발 PC와 저장소에 분산해서 저장
- 그렇기 때문에 중앙 서버에 장애가 발생해도 로컬 저장소에 커밋을 할 수 있으며, 로컬 저장소들을 이용하여 중앙 저장소의 복원도 가능하다.
- 사본을 로컬에서 관리하기 때문에 GIT이 SVN에 비해 훨씬 빠르다. (SVN은 변경 로그 하나 보는 것도 인터넷을 경유해야 한다.)

3. 나는 어떤 방식으로 협업을 하였는가?

저번에 Git flow에 대해 학습을 하여 이번 프로젝트에 Git flow 방식을 적용을 하였습니다.

Git Flow 전략

물론 처음으로 GIT을 통해 프로젝트를 하면서 문제가 발생을 하였고 Git flow를 학습을 하였을 때와 실제로 프로젝트를 하였을 때 많은 고민이 있었습니다.

일단 저는 강남언니의 Git flow에 대한 블로그를 보고 학습을 하였습니다. 일단 처음으로 고민한 부분은 과연 이렇게 많은 브랜치를 사용을 하는게 지금 프로젝트에 좋은가? 생각을 하였을 때 저는 NO라고 생각을 하였습니다.

그래서 저는 Feat 전략을 사용하여 master , developer , feat 브랜치를 이용하여 git flow 전략의 난이도를 낮추어 협업을 하였습니다.

일단 feat는 기능을 기반으로 브랜치를 생성을 하였고. ex) feat/mg_member

추가적인 issue가 발생을 하면 issue에 등록하고 번호를 받아서 사용하는 방식을 사용을 하였습니다. feat/#22

 

4. 코드 컨벤션을 맞추기 위해 나는 이렇게 노력을 하였다.

코드 컨벤션과 팀 프로젝트의 약속은 매우 중요하다고 생각합니다.

이 부분의 중요성은 제가 국비지원 프로젝트를 하면서 코드 컨벤션과 프로젝트에 대한 약속을 하지 않고 진행을 하였을 때 나중에 많은 오류가 발생을 하였습니다. 저는 이러한 문제를 경험하고 다음 프로젝트를 하면 이러한 부분을 최대한 정하고 프로젝트를 진행을 해야되겠다고 생각을 하였습니다.

그래서 저는 프로젝트 시작 이전에 팀원에게 제가 코드 컨벤션 및 커밋 컨벤션을 팀원에게 공유를 하였습니다.

Git Flow 전략

 

Git Commit Convention설정하기

 

Google Java Style Guide 적용하기

 

5. Merge전략은 어떻게 설정을 해야될까?

저는 프로젝트를 하면서 merge 전략에 대해 고민을 가졌습니다. 일단 스쿼시 머지와 pull request merge 총 2개의 방식을 고민을 하였습니다.

일단 처음에는 Pull Request 머지 방식을 사용하다가 Git Log의 관리가 너무 복잡하고 나중에 더 많은 문제가 발생이 생긴다고 생각하여 다른 Merge 방식을 찾게 되었습니다. 

그래서 Squash & Merge 방식을 찾게 되어 이렇게 하면 Git Log의 관리가 기존의 방식보다 보다 명확하게 관리가 가능하다고 생각을 하였습니다.

Git의 다양한 브랜치 병합 방법 (Merge, Squash & Merge, Rebase & Merge)

 

 

하지만 프로젝트를 하면서 제가 코드 리뷰가 필요하다고 생각하여 이 Squash & Merge 방식 보다는 Pull Request 방식이 더 적합하다고 판단을 하였습니다.