Git으로 협업하기! - forking workflow에서 git flow로 변경한 이유

안녕하세요. 휴몬랩에서 개발과 기타 등등을 하고 있는 오지(OG)입니다 :)

 

지금까지 개발을 해오면서 git을 사용한 협업 방법에 대해 많은 고민을 해왔는데요, forking workflow를 사용하다가 git flow로 변경하게 된 이유와 두 방식의 차이를 정리해볼까 합니다.

 

우선 이 글은 git에 대한 기본적인 이해도를 가지고 있다고 생각하고 작성하였습니다. 혹시 나는 git을 처음들어봤다, 혹은 git에 대한 전반적인 지식을 갖고 싶다라고 한다면 이 포스팅을 추천해드립니다. (링크 바로가기)

---

Git으로 협업해야 하는 이유

git은 애초에 협업에 용이하도록 만들어진 버전 관리 방식입니다. 만약 개발팀이 git을 사용하지 않고 협업을 한다면, 아래와 같은 불상사가 벌어질지도 모릅니다.

• A라는 사람이 로그인 페이지를 개발한다.
• B라는 사람이 랜딩 페이지를 개발한다.
• A는 로그인 페이지를 만든 후 프로젝트를 압축해서 B, C, D... 에게 보낸다.
• B는 A가 보낸 프로젝트를 확인한 후 개발 중인 프로젝트에 합친다. 만약 A와 B가 같은 파일을 수정했다면 A가 수정한 파일과 B가 가지고 있던 파일의 차이점을 확인하고 수동으로 합친다..

다행히 우리는 git이라는 완벽한 도구로 쉽고 편리하게 협업을 할 수 있습니다 :)

 

 

Git을 이용한 최고의 협업 방법?

개발자들이 git을 협업 툴로 사용하면서 협업 방법론들이 자연스럽게 생겨났습니다. Atlassian bitbucket 공식 tutorial의 설명에 따르면 사람들이 주로 사용하는 협업 방식은 크게 4가지로 나누어지는 듯 합니다.

Git 협업 방식 4가지

4가지 모두 장단점이 있고 방법론일 뿐입니다. 개발팀의 문화, 인원 , git에 대한 전반적인 이해도 수준, 프로젝트 진행 방식 정도를 고려하여 상황과 환경에 적합한 협업 방식을 골라 적용하면 됩니다.

 

저희 개발팀의 경우 인원이 적고, git을 통한 협업이 익숙하지 않은 사람이 몇 있고, 스타트업이기 때문에 기능이나 디자인의 수정과 업데이트 배포가 굉장히 빠른 편입니다. 또한 각자 진행상황을 빠르게 공유하고 싶었고, 코드리뷰도 용이했으면 좋겠다는 생각으로 협업 방식을 선택하였습니다. 그리고 개인적으로는 대표 브랜치(master, develop 등)와 branch graph는 깔끔한 것을 선호합니다^^.

 

Centralized Workflow를 선택하지 않은 이유

Centralized Workflow는 master branch 하나로 모든 개발이 이루어집니다. 따라서 단순하지만 conflict가 일어날 확률이 높고, 기능상 여러 버전(bugfix, hotfix, release, develop)을 구별하지 않습니다.

 

<Centralized workflow의 단점>

• 서비스 배포 이후 관리가 어렵다.
• conflict가 일어날 확률이 높다.
• master branch가 더러워질 확률이 높다...

Feature Branch Workflow를 선택하지 않은 이유

Feature Branch Workflow는 feature branch를 만들어 개발하고 master에 합치는 식으로 진행합니다. 초기 개발시에는 feature branch workflow가 나쁘지 않으나 이미 서비스가 런칭된 상태라면 힘들 수 있습니다.

 

<Feature Branch Workflow의 단점>

• 서비스 배포 이후 관리가 어렵다.
• conflict가 일어날 확률이 높다.
• 처음부터 명확히 feature를 구분하지 않을 경우 결국 사람 당 1개 브랜치를 만들게 될 확률이 높다.
• feature 명명 기준이 모두 달라 혼란이 올 수 있다.

Forking Workflow를 선택했다 떠나보낸 이유..

Forking Workflow부터는 조금 복잡해집니다. 이 협업 방식에서는 이름처럼 fork 기능을 사용합니다. 대표(중앙) 저장소가 있고 모든 개발자들은 이 대표 저장소를 fork하여 자신의 원격 저장소를 만듭니다. 작업은 모두 fork한 저장소에서 진행되고 대표 저장소에 merge 요청을 할 땐 pull request를 보냅니다.

 

Forking Workflow 방식

정리하면 Forking workflow를 사용할 경우 각자 개인 원격 저장소에서 관리하다가 필요할 경우에만 Pull request를 보내 중앙 원격 저장소에서 합쳐집니다.

 

이 방식은 프로젝트 규모가 크거나 어떤 기준에 따라 잘 분리되어 있을 때 사용하면 좋습니다. 또한 개인 원격 저장소에서 무슨 짓을 해도(?) 중앙 저장소에는 영향을 주지 않기 때문에 마음껏 실험하고 시도할 수 있다는 것이 장점입니다.

애초에 저는 이 forking workflow가 가장 깔끔하고 협업하기에 쉬울 것이라 생각하여 사용했었습니다. 하지만 이 workflow 대로 협업하자 몇 가지 문제점이 발생했습니다.

 

<forking workflow의 단점>

1. git을 처음 써보는 사람의 경우 workflow를 이해하기가 다른 flow보다 상대적으로 어렵다.

   fork, pull request 등 생소한 개념을 직접 사용해야하고, 여러 개의 원격 저장소를 사용하거나, 저장소가 여러가지로 분리되는 등 사실 구조가 복잡해서 처음 접하는 사람들은 굉장히 어려워하는 모습을 보였습니다. 더군다나 fork한 개인의 원격 저장소는 개인이 관리하다보니 잘못된 사용이 있을 때 알아차리기도, 리뷰하기도 어려웠습니다.

2. 작업 상황을 자주(짧은 주기로) 리뷰하기가 쉽지 않다. → 통일된 관리가 어렵다.

   forking workflow는 자신의 원격 저장소에서 주로 작업하다보니 서로 작업하는 내용을 모니터링하기가 어려웠습니다. 직접 이 workflow를 적용해보니 pull request를 자주 하기엔 번거롭고 최소 2~3일, 길게는 몇 주 주기로 pull request를 하게 되더라구요. 이럴 경우 어쩔 수 없이 리뷰하는 주기가 길어집니다.

3. 이 workflow 만으로는 multi thread 적용 불가 (단일 thread가 기본이다 보니... 변형해야 한다. )

   배포 이후에는 배포 버전에서 빠르게 수정하는 버전, 다음 업데이트 기능을 준비하는 버전 등 분리가 필요한데 이는 forking workflow 만으로는 해결하기 힘든 부분입니다. (Gitflow를 이용하면 해결할 수 있습니다.)

forking workflow는 물론 팀원들이 모두(대다수) git의 기본 기능(commit, push, pull, rebase 등)에 익숙하고, 프로젝트 단위가 매우 크며 개인이 독립된 기능을 자유롭게 개발할 경우에 추천합니다. 하지만 저의 경우 상황과 환경이 적합하지 않은 것 같아 빠르게 gitflow 방식으로 전환하였습니다.

---

Git flow Workflow 적용하기

GitFlow는 보통 이미지 하나로 설명하곤 합니다. Git flow로부터 github flow, gitlab flow 등 다양한 방식이 파생되었지만 Git flow가 가장 깔끔할 것 같아 적용하였습니다.

 

보통 왼쪽의 의 그림으로 git flow를 설명하곤 합니다.

 

그림이 복잡한 듯 보이지만 여기서master , develop 브랜치는 사라지지 않는 기본 브랜치이고 나머지 feature, release, hotfix는 필요할 때 만들었다가 삭제하는 브랜치입니다.

 

따라서 사실 결과적으로 남아있는 branch는 master, develop 뿐입니다. 여기에 rebase까지 철저히 하면 아주 예쁘게 곧게 뻗은 branch graph를 만들 수 있습니다.

 

기본 git flow를 이해한 후 저희 팀에 맞게 약간 변형하여 적용하였습니다. 작업 방법도 살짝 공유합니다.

 

<branch>

• master(항상 유지): 제품으로 바로 출시되는 브랜치
• develop(항상 유지): 다음 출시 버전을 개발하는 브랜치
• feature(일시적): 특정 기능을 개발하는 브랜치
• release(일시적): 이번 출시 버전을 준비(QA 수정, bug fix 등)하는 브랜치 → tag로 관리
• hotfix: 출시 버전(master)에서 발생한 버그를 바로 수정하는 브랜치 → 수정 후 바로 배포
• (+bugfix): release 버전에서 발생한 버그를 바로 수정하는 브랜치 → 수정 후 release branch로 pull request

<변형>

1. bugfix branch 추가

   git flow에서 기본적으로 말하는 branch는 hotfix 까지지만 저희 개발 업무 특성 상 release 버전 이후에도 QA와 테스트를 통해 고치는 bug가 많아서 bugfix branch를 하나 더 추가하였습니다.

2. 개인이 Push하는 대신 Pull Request.

   또한 원래는 bugfix, hotfix, feature branch에서 작업이 끝나면 각각 release, master, develop branch 로 rebase 후 push 하면 되지만, git에 익숙해지기 전까지는 pull request를 올리도록 하여 관리자가 체크 후 직접 push하고 있습니다.

Git Flow를 활용한 작업 방법 (Git 초보 버전)

새로운 기능 개발(New version)

1. 원격 develop branch에서 feature/*** branch를 생성 (ex. feature/login_layout)
   • 이 때, feature 단위는 팀 논의 하에 결정합니다. (개발 전 미리 listing)
2. feature/*** 에서 작업 진행
3. develop branch로 pull request 생성 → 관리자가 pull request 확인 후 rebase, push → 해당 feature branch 삭제
4. 새로운 기능 구현 (1번으로)

테스트용 출시 후 (release branch 생성 후)

1. develop branch에서 새로운 release@*** branch 생성
2. QA 시작
3. Bug 수정 시 release branch에서 bugfix/*** branch 생성 → bug 수정
4. bug 수정 완료 시 release branch로 pull request 생성 → 관리자가 pull request 확인 후 rebase, push → merge 후 해당 bugfix branch 삭제
5. 새로운 bug fix (3번으로)

정리

관리자 이외의 개발진들은 아래의 2가지 행동만 하면 됩니다.

1. develop branch에서 구현하고자 하는 기능에 따라 새로운 feature/*** branch를 생성. 기능 구현 후 develop branch로 pull request
2. release branch에서 고치고자 하는 bug에 따라 새로운 bugfix/*** branch를 생성. 버그 수정 후 release branch로 pull request

---

정리하자면, forking workflow에서 git flow로 바꾸게 된 이유는 아래와 같습니다.

1. git에 익숙하지 않은 팀원도 쉽게 접근할 수 있다.
2. multi thread(배포 버전, 개발 버전)가 가능하다.
3. 배포나 업데이트, 수정이 빠르게 가능하다.

협업 방법에 대해 고민하는 분들께 조금이나마 도움이 되었으면 좋겠습니다. :)

여러가지 방식을 시도해보며 팀에게 가장 적합한 방식을 찾길 바랍니다!

 

[References]

- Atlassian bitbucket 공식 tutorial

- 우린 Git-flow를 사용하고 있어요 - 우아한 형제들 기술블로그