스프링 게시판 프로젝트 4일차 6번의 프로젝트 이야기, 깃 브랜치 전략

지금까지 깃, 깃허브 세팅을 끝냈다.

지금은 내 개인 프로젝트니까 사실 단순히 기록용에 지나지 않겠지만 내 경험들이 훗날 현업에서 도움이 되었으면 좋겠다.

 

2명 이상이 같은 파일을 수정하여 커밋, 푸시할 경우 병합 충돌(merge conflict)이 발생한다.

하지만 같은 파일이라도 다른 줄(Line)의 코드를 수정하면 충돌이 나지 않는다.

병합 과정은 소스 코드 줄 단위로 이루어진다.

 

여태 나는 6개의 팀 프로젝트를 진행했고 그 중 총 4번의 팀장 경험을 했다.

그때마다 어떻게 해야 충돌이 나지 않고 협업을 잘 할 수 있을까를 매번 고민했었다.

 

첫 번째 프로젝트 때는 팀원 각자의 브랜치에 올린 후 팀장인 내가 수동으로 직접 모두의 코드를 합쳐서 거의 내 브랜치로만 master 브랜치에 merge를 했었다.

각자 master에서 pull한 타이밍이 계속 달라지다보니 충돌이 자연스럽게 났었고 그래서 차라리 수동 merge를 해서 충돌을 피했었다. 수동이었기에 백업 역시 수동으로 해줘야했다.

 

두 번째때는 유니티 콜라보레이트 기능을 이용했는데 처음에는 익숙치 않아서 하나의 씬으로 작업하다 충돌이 나곤 했으나 각자 씬을 하나씩 담당하는 방법으로 충돌을 피했다.

 

세 번째때는 역시 각자 하나의 브랜치를 주고 각자 맡은 폼(Form)을 제외한 파일을 수정시에는 무조건 알리도록 했다. 다만 충돌이 날 수 있다는 걸 알리니 다들 겁을 먹어서 커밋을 하지 않고 카톡으로 .txt 파일로 공유를 해줘서 팀장인 내가 직접 합쳐야 했다.

 

네 번째때는 팀원 각자가 라즈베리파이 하드웨어를 하나씩 담당해서 기능 구현을 맡아서 마지막에 합칠 때만 협업이 필요했기에 깃, 깃허브를 나 혼자 기록용으로만 사용했다.

다만, 이때부터 팀에 비전공자가 있었기에 Agile(애자일) 개발방법론 중 하나인 짝프로그래밍(Pair Programming)을 이용하여 개발하였다. 내가 Navigator(내비게이터), 비전공자 팀원이 Driver(드라이버)를 맡았다.

 

다섯 번째때부터는 내가 팀장이 아니었다. 하지만 결국 상대적으로 프로젝트 경험이 많아서 팀장을 도와 PM 역할을 하게 되었다. 짧은 개발 기간 안에 원하는 기능들을 구현하고 싶었고 그걸 위해 조금은 체계적으로 프로젝트를 정리해야할 것 같았다. 그래서 깃허브에 있는 Projects 기능을 처음으로 사용해보았다. 

 

 

그냥 생각나는대로 적어둘 메모장같은 게 필요해서 설계 column을 만들었다.

그리고 설계한대로 To do column에 할 일들을 차례로 적었고 내 나름대로 팀원들에게 할 일을 배분해주었다.

나말고도 다른 팀원이 깃허브를 많이 이용하게 하고 싶었기에 오류가 나지 않는 기능을 구현하면 바로바로 각 브랜치로 올리고 merge하게 했다.

 

여섯 번째때는 팀장도 멘토도 따로 있었기에 개발에 좀더 집중을 했다.

하드웨어 제어이고 초반엔 다같이 공부하는 느낌이었기에 멘토님이 깃허브가 굳이 필요없다하셨지만 왠지 아까워서 공부기록, 주간보고서, 실습코드 보관용으로라도 쓸 목적으로 레포지토리를 만들었었다.

후반에 UI와 PLC 제어로 역할이 나뉜 후, 팀과 그 안의 작은 팀끼리 여러모로 협업할 일이 많아서 깃허브를 사용한 건 좋은 선택이었다.

아무튼 나는 PLC 제어 담당팀이었는데 같이 담당하게 된 비전공자 팀장과 함께 짝프로그래밍을 이용해 개발하였다.

제어라는 분야가 둘다 처음이라 낯설기에 서로 아는 것을 확인하는데 짝프로그래밍은 더욱 효과를 발했다.

짝프로그래밍은 어려운 분야에서의 개발이라는 점에서 에러가 나서 헤매는 시간을 줄일 수 있게 해줬고 통합을 필요없게 해주었다. 그리고 무엇보다 3개월을 언제나 함께 개발하다보니 팀워크를 향상시키고 서로의 의견을 공유하는데 도움이 많이 되었다.

 

아무튼 갑자기 이렇게 최근 1년간의 6번의 프로젝트를 협업관점에서 한 번 돌아봤다.

신입 입사할 경우, 내가 팀장이나 PM일리도 없고, 짝프로그래밍을 할 일도 거의 없을 것이다.

이젠 나서서 뭔갈 만들지 않으면 개인적으로는 팀 프로젝트를 할 일이 없어진 지금, 현업에서는 깃 브랜치를 어떻게 이용하고 관리하는지 궁금해졌다.

 

깃 브랜치 전략에는 대표적인 2가지가 있다고 한다.

 

 

Github flow

 

 

가장 간단한 브랜치 전략이다.

 

하나의 master 브랜치로부터 일단 시작한다.

여기에서 기능 구현 혹은 버그 발생을 한다면 새로운 브랜치를 생성한다.

이때 브랜치명과 커밋메세지는 최대한 직관성 있게 명명한다.

로컬 브랜치에 커밋을 했다면 같은 이름의 원격 브랜치로 수시로 push하며 개발이 완료된다면 master 브랜치로 PR, 즉 Pull Request를 한다.

이에 대한 리뷰, 피드백이 충분히 이루어지면 merge한다.

master 브랜치로 merge하면 자동화 도구를 통해 즉시 배포한다.

 

master 브랜치 하나만 있어서 단순하다는 것, 그래서 사용하기 쉽다는 것이 제일 큰 특징이다.

그리고 CI(Continuous Integration)/CD(Continuous Deployment), 지속적인 통합, 지속적인 배포가 특징이다.

 

깃허브 플로우는 매일 개발하고 지속적으로 테스트, 배포하는 팀에게 적합하다.

 

Git Flow

 

Git Flow는 브랜치가 많아 조금 복잡한 브랜치 전략이다.

하지만 그림을 따라 차근 따라가보자.

 

 

총 5개의 브랜치가 있다.

 

항상 유지되는 중심 브랜치 master, develop 두 가지와 merge되면 삭제되는 보조 브랜치 feature, release, hotfix 세 가지가 있다.

 

master 브랜치는 배포되는 가장 중심 브랜치이다.

hotfix 브랜치는 master 브랜치에서 발견된 버그를 수정하는 브랜치이다.

release 브랜치는 develop 브랜치에서 구현한 기능들을 테스트하는 브랜치이다.

develop 브랜치는 master 브랜치 다음으로 배포될 것을 개발하는 브랜치로 개발의 중심 브랜치이다.

feature 브랜치는 develop 브랜치에 merge할 기능들을 구현하는 브랜치이다.

 

master 브랜치에서 0.1 버전부터 시작한다.

 

master 브랜치로부터 develop 브랜치를 만들고 develop 브랜치로부터 새로 기능을 개발할 feature 브랜치를 만든다.

브랜치명은 보통 feature/구현기능명 으로 명명한다.

기능 구현, 테스트가 완료되면 develop 브랜치에 merge한다.

 

새 release에 보여줄 기능을 모두 구현해 develop 브랜치에 merge했다면, 테스트를 위해 release 브랜치를 만든다.

오류가 있으면 release 브랜치에서 수정하고 테스트가 완료되면, release 브랜치를 master 브랜치에 merge한다.

첫 release 버전은 1.0부터 시작하며 태그로 지정할 수 있다.

오류 수정이 있었다면, develop 브랜치에도 merge한다.

 

배포 중인 master 브랜치에서 버그가 발견되면, hotfix 브랜치를 만들어 버그픽스를 하고 develop 브랜치, master 브랜치에 merge한다.

 

깃허브 플로우보다는 복잡했으나 체계적이라 체화한다면 팀 프로젝트를 수행하는데 좋을 것 같다.

 

깃 플로우는 몇 주에서 몇 달 주기로 공식적으로 릴리즈하는 팀에게 적합하다.

 

두 가지 방법 모두 장단점이 있는 방법이니 두 가지 모두 한 번씩 직접 써보면서 체화해야겠다.

 

References

 

5. 병합 충돌 (Merge Conflict)

GitHub Flow(Scott)

깃 브랜치 전략

git 브랜치 전략에 대해서

Git 브랜칭 전략

Git flow, GitHub flow, GitLab flow

GitHub Flow(번역본)

GitHub Flow(GitHub Doc)

GitHub Flow(블로그)

Git Flow vs Github Flow