[Git] git에서 branch로 flow 관리하기

학부 2학년으로 막 복학했던 17년 초, 당시 학과 선배에게서 github라는 것을 처음 들어보면서 git에 대해서 알게 되었다.

처음에 개념적으로 알아볼 때에는 버전 관리, 협업 등에 많이 이용되는 것을 알았고, branch, merge, pull request 등 많은 기능들에 대해서 읽었지만 정작 졸업할 때까지 commit을 제외하고는 사용이 많지 않았다. 입사 후에 git을 본격적으로 사용하면서 git flow에 대해서 알게 되었고, branch 전략과 PR, tagging 등 협업과 버전 관리를 사용하고 있다. 그래도 학부생 때 git을 조금이나마 사용해보아 익숙했던 것이 적응에 수월하기는 했다.

밑에서는 졸업 후 막 사용해본 필자의 경험을 토대로 쓰는 것이고, 잘 정리된 글은 여기를 참고하시길 바란다.

---

 

Branch(브랜치)

나뭇가지처럼, 각자 다른 개발을 할 때 메인 스트림을 놔두고 길을 분리하는 것이다. 후에 기능 개발이 잘 되었다고 판단하면 리뷰를 거친 후에 메인 스트림에 merge가 된다.
하지만 서두에 말했듯이 학부생 시절에는 대규모 개발팀을 경험한 적도 없고, 많아야 2~3명의 팀원과 개발하고 branch나 코드 리뷰에 대한 지식이나 경험도 없었기 때문에 master branch만을 사용했었는데, 이제는 팀에서 branch를 사용하다 보니 이 용이성에 대해서 알게 되었다.

개인 github에서 branch를 merge하였다.

이런 식으로 기능 개발을 위한 branch를 생성하고 master에 merge한다. 줄기의 흐름을 도식화해서 보면 이해가 빠른데, github에서는 아쉽게도 제공해주지 않는 것 같다. bitbucket에서는 저장소 별로 제공해주기 때문에 나중에 사용할 기회가 있다면 살펴보면 히스토리와 흐름을 직관적으로 파악하기 좋다.

Pull Request(PR), Merge(병합)

Merge는 위에서 만든 branch를 다른 branch와 합치는 것인데, git에서의 merge는 상당히 보수적이어서 conflict가 일어나는 부분은 자동 merge를 지원하지 않고 직접 해결해야 한다. 다만 이 때의 merge는 검증 단계 없이 바로 합쳐지기 때문에 새로 들어오는 코드에 대한 검증이 되지 않고, 특히 master나 release 브랜치라면 심각한 영향을 끼칠 수 있다.

PR 자체는 git에 포함된 내용은 아니지만, github, gitlab, bitbucket 등 대부분의 플랫폼에서 지원한다. PR은 다른 branch에 merge하기 위해 요청하는 것이다. 즉, 바로 merge를 하는 것이 아니라 요청을 하고 리뷰를 받는 검증 단계이다. 주로 commit을 하고 그 내용을 설명하고 코드 리뷰가 이루어진다. 리뷰어들은 보고 approve하거나 needs work하는데, 일정 정도 approve를 받고 합의가 되면 비로소 merge를 하게 된다. github와 같은 오픈소스 생태계에서 굉장히 많이 쓰이며, 필자의 팀에서도 매우 활발하게 PR과 코드 리뷰가 이루어진다. PR에서의 코드 리뷰는 과도한 간섭이 아니라면 무분별한 소스 코드의 추가 방지, 구조 개선, 변경점 공유 등 많은 장점이 있다고 생각한다.

개인 github에서의 pull request

위와 같이 변경점에 대해서 공유하고 코멘트를 달 수 있다. 해당 사진은 본인의 private 저장소이기 때문에 셀프 PR 후 merge.

Tagging

태깅의 개념도 입사 후에 알게 되었는데, 현재 커밋에 대해서 태깅을 하여 버전 관리를 하는 것이다. 예를 들어, master에 merge한 후에 이번에 배포가 되었다면 v1.0.1로 태깅을 하고, 다음번 배포에는 v1.0.2로 태깅하고.. 이런 식으로 배포가 되었을 때마다 태깅을 한다면 후에 히스토리, 버전 관리가 가능하다.

Branch 관리 전략

위에서 말한 branch를 협업을 위해 사용하는데, 점점 규모가 커지고 branch가 난립하다보니 branch 관리를 효율적으로 하자는 생각에서 나온 것이 branch 관리 전략 들이다. git flow, github flow, gitlab flow 등이 존재하는데, 이 글에서는 git flow와 github flow를 알아 보자.

git flow

git flow는 조금 복잡한데, 다음과 같은 단계를 거친다. 왼쪽에서 오른쪽으로 merge가 진행된다. 가장 중심이 되는 branch는 master와 develop이며, 이름은 사실 상관 없지만 유지하는 편이다. master는 최종적인 메인 스트림이고 develop은 개발 단계 전반의 메인 스트림이기 때문에 상당히 중요하다. 이 두 branch에 대해서는 merge할 때 좀 더 신중하게 하는 편이 좋다.

feature - feature/major - devlop - release/ - hotfix - master

• feature / feature/major : 기능 개발을 위해서 만드는 가장 말단의 branch이다. major는 여러 기능들이 모아서 주요 기능이 될 때 말단들의 메인 스트림이다.
  ex) 로그인 구현(feature/major) - 로그인 페이지 View 제작(feature) + 로그인 request 구현(feature) + 유효성 검사(feature)
• develop : 말단 feature들은 feature/major로 merge되면서 일차적으로 코드나 구조에 대한 부분은 검증되었고, 해당 기능이 개발 전체로 흡수된다.
  ex) 홈페이지 제작(develop) - 로그인 구현(feature/major) + 회원가입 구현(feature/major) + ...
• release : 배포하기 위해 만드는 branch로, 마지막 테스트를 통한 검증 등을 수행한 후에 빌드/배포를 진행한다.
• hotfix(핫픽스) : release branch에서 배포를 진행했을 때, 서비스에서 예상치 못한 중대 결함이 발견되어 급히 수정해야할 경우 위 단계를 거치지 않고 최대한 빠르게 구현 후에 바로 배포하고 master로 merge한다. 이 때 develop과 차이가 생기기 때문에 master->develop으로 백머지가 필요하다.
• master : 최종적인 메인 스트림으로, 실제로 배포되어 현재 서비스중인 코드를 유지한다.

꽤나 복잡하지만 실제로 사용해보면 엄청나게 복잡하지는 않다. 정기적으로 배포가 이루어지는 프로젝트일 때 굉장히 유용하고 관리가 잘 되며, 한 프로젝트 내에서 여러 개발을 진행할 때에도 서로 엉키지 않고 잘 진행된다. 

다만 꼬였을 경우에는 풀기가 좀 어렵다는 느낌은 있었다.

github flow

github flow는 위의 git flow가 너무 복잡하다는 점에서 착안하여 master를 제외하고는 모두 단순화한 flow이다. 개발은 각자의 branch에서 진행하고, branch에서 파생되는 branch는 없다. 다만 master는 개발 중인 상태가 아니라 항상 배포 가능한 상태이다. 도움이 필요하거나 merge 준비가 완료되었을 때 PR을 작성한다.

마치며

서두에서 언급했듯 학부생 시절에는 github에서 검색하고 둘러보고 commit이나 몇 번 해본 수준이었고, 제대로 사용하는 것은 아직 4달 남짓이기 때문에 많이 익숙하지 않고 부족하다.

하지만 어쨌든 git은 협업을 하고 버전 관리를 위한 도구이므로, 위의 전략 등에 너무 얽매이지 않고 가장 개발에 도움이 되는 방향으로 팀에 맞게 운영하면 된다고 생각한다.