[Git] Git-flow / Git을 사용하여 협업하는 방법

이번에 협업을 진행하면서 처음으로 git을 사용해보았지만 팀원들과 나름대로 규칙을 정해서 git을 사용하여 큰 문제없이 프로젝트를 완료할 수 있었다. 프로젝트를 끝 마친 뒤에야 알게 된 내용이지만 Git을 이용한 협업에도 권장하는 방식이 있으며 그 방식을 Git-Flow라고 부르는 것 같다.

언뜻 보면 어려워 보이지만 속은 그렇게 어렵지 않다고 한다.

 

Git-Flow란?

Git을 이용해 협업을 할 때 서로 작업한 내용을 합치고 배포하고 수정하는 과정을 더 안전하고 깔끔하게 처리하기 위해 표준으로 널리 사용되는 방법이다.

Git-Flow는 5가지의 브랜치를 사용한다.

• main : 기준이 되는 브랜치로 제품이 배포될 브랜치 (main = master)
• develop : 실제 개발이 이루어지는 브랜치, 이 브랜치를 기준으로 각 기능들을 병합한다.
• feature : 기능별로 브랜치를 나누어서 각 feature 브랜치 별로 개발하여 develop에 합친다.
• release : 배포를 위해 master에 보내기 전 QA(품질검사)가 진행되는 브랜치
• hotfix : master 브랜치에서 예기치 못한 버그가 발생했을 때 수정을 위한 브랜치

우리 팀은 브랜치를 master와 각자의 작업 브랜치로 나누어 사용했었다. Git-Flow와 비교해보면 main브랜치를 develop브랜치로 사용했고, 실제 개발 영역은 feature브랜치가 아닌 각자의 영역을 브랜치로 할당하여 사용한 것이다.

(Git을 활용한 Work-Flow중 하나인 GitHub-Flow의 모습과 유사하다.)

 

 

Git-Flow 이해하기

Git-Flow를 설명할 때 꼭 등장하는 이미지이다.

 

 

 

Git-Flow 흐름도

1. master에서 프로젝트를 시작한다.
2. develop에서 동일한 브랜치를 생성한다. 여기서 개발이 진행된다.
3. 공통적인 내용에 대한 개발을 진행하다가, 특정 기능의 개발이 필요하게 될 경우 feature 브랜치를 생성하여 각 기능을 구현한다.
4. 분기된 feature 브랜치에서 개발이 완료되면 검토를 거쳐서 다시 develop에 합친다.
   (merge가 끝난 브랜치는 바로 삭제된다.)
5. 모든 개발이 끝나면 develop 브랜치를 release 브랜치로 옮겨 QA(품질검사)를 진행한다.
6. QA가 끝나면 이제 release브랜치를 다시 develop와 master브랜치로 보낸다. master 브랜치에서 버전에 관한 태그를 추가하고 배포를 시작한다.
7. 배포 중 버그가 발생시 hotfixes 브랜치를 생성하여 수정 후 태그를 다시 생성하여 수정 배포를 한다.

 

 

분산 환경의 Git-Flow

위에서는 한 저장소에서 브랜치를 나누어 사용하는 방법에 대해 서술했다.

하지만 규모가 큰 프로젝트에서는 브랜치 단위가 아닌 저장소 단위로 나누어 작업을 할 수 있다고 하며 이를 분산 환경의 Work-Flow라고 하며 굳이 저장소 단위로 나누어서 작업하는 이유는 더 안전하고 자유로운 실험을 할 수 있기 때문이라고 한다.

저장소를 나누는 방법에는 Fork를 사용할 수 있다.

 

 

 

Fork에 대해

저장소 우측 상단에 작게 Fork라고 적힌 버튼을 누르면 자신의 저장소로 Fork할 수 있다.

Fork는 Clone과 비슷한 개념으로 공용 저장소를 복제해서 자신의 저장소로 가져올 수 있다.

하지만 Clone는 공용 저장소에서 독립된 저장소로 생성하는 것이고 Fork는 공용 저장소의 자식 저장소로 생성된다는 차이점이 있다.

 

 

Fork를 사용하여 생성한 저장소는 이렇게 아래에 원본 저장소의 링크가 달려있으며 원본 저장소에 연결되어 있다는 뜻을 가지고 있다.

이렇게 연결된 저장소는 원본 저장소에 변화를 Fetch를 통해 반영할 수 있고 오히려 반대로 Forked 된 저장소에서 원본 저장소에 변경 사항을 적용하고 싶으면 pull request를 신청해서 관리자 승인으로 자신의 코드가 commit, merge 될 수 있다.

 

 

 

기존 사용하던 pull request는 브랜치간의 병합을 만을 고를 수 있었지만, forked 된 저장소에서 pull request를 요청하니 위 사진과 같이 저장소 관계도 보이며 선택할 수 있게 된다.

 

 

 

forked 된 저장소에서 커밋을 작성하고 원격 저장소에서 메시지를 확인해보니 저렇게 저장소:브랜치명으로 pull request 요청이 표시된다.

한 저장소에서 작업하는 방식과 각자 저장소를 Fork 하여 작업하는 방식은 다소 번거롭지만 pull request의 안전성에서 뛰어난 차이점이 있을 뿐 크게 다른 방법으로 보이지는 않는다.

 

 

---

 

 

자료 출처

https://uxgjs.tistory.com/183 (Git Flow 개념)

https://git-scm.com/book/ko/v2/분산-환경에서의-Git-분산-환경에서의-워크플로#_중앙집중식_워크플로 (중앙집중식과 분산 환경의 개념)

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

(배달의 민족 개발팀의 분산 환경의 Git-Flow)