나의 첫 Git Flow, Git Branch 전략 세우기

Git Flow란?

깃 플로우(Git Flow)는 개발을 위한 브랜치 관리 전략 중 하나이다.

Git Flow를 사용하면 개발 프로세스를 체계적으로 관리할 수 있으며, 다른 개발자들과의 협업도 수월해진다. 따라서 많은 기업과 개발자들이 Git Flow를 사용하고 있다.

이번 프로젝트를 하기 전에 팀원들과의 일관성 있는 작업 수행을 위해 깃 플로우를 정립할 필요가 있다고 생각했다. 이번 블로그에서 프로젝트에 도입했던 깃 플로우에 대해 정리해보려고 한다.

 

Git Repository 구성

• Upstream Remote Repository : 팀이 공유하는 최종 원격 저장소
• Origin Remote Repository : Upstream Repository를 Fork 한 원격 개인 저장소
• Local Repository : Origin Repository는 개인 컴퓨터에 저장되어 있는 개인 저장소

이미지 출처 : https://techblog.woowahan.com/2553/

 

Work Flow 전략

1. Local Repository에서 작업을 완료한 후 작업 브랜치를 Origin Repository에 push 한다.
2. Github에서 Origin Repository에 push한 브랜치를 Upstream Repository의 dev 브랜치로 merge하는 Pull Request를 생성하다.
3. Pull Request를 통해 코드 리뷰를 진행한 후 merge한다.
4. 다시 새로운 작업을 할 때 Local Repository에서 Upstream Repository를 pull한다.
5. 다시 1번부터 반복

위 구성은 우아한 테크코스의 블로그를 참고했다.

 

이런 Work Flow를 제안하는 이유

위와 같은 Flow를 제안한 이유는 치명적인 실수를 방지하기 위함이다.

브랜치를 나누어 작업한다고 하더라도 개발자의 실수로 메인 브랜치에 잘못된 파일을 merge하게 되거나 Repository를 삭제해 버리는 치명적인 위험이 있다고 생각했다.(실제로 이전 프로젝트에서 리포지토리를 삭제해버리는 사건이 있었다..ㅠ)

Fork한 Repository를 두어 위험을 방지할 수 있다고 생각했다.

Git Flow

브랜치는 항상 유지되어야 하는 메인 브랜치와 필요에 따라 생성되는 보조 브랜치로 나누었다.

 

메인 브랜치

• 메인 브랜치는 크게 세 종류로 나눈다.
  • main : 서비스로 출시될 수 있는 브랜치
  • devBack : 출시 버전을 개발하는 백엔드 전용 브랜치
  • devFront : 출시 버전을 개발하는 프론트엔드 전용 브랜치
• main 브랜치는 통합 브랜치의 역할을 하며, 주로 devBack/devFront 브랜치를 기반으로 개발을 진행한다.
• 메인 브랜치는 지워지지 않고 항상 유지되어야 한다.
• 메인 브랜치는 업데이트 때마다 Pull Request를 통해 코드 리뷰를 진행한 후 merge할 수 있다.
• 코드 리뷰 후 문제가 없다면 Pull Request한 당사자가 직접 merge 한다.

 

보조 브랜치

• 보조 브랜치는 실제 작업용 브랜치를 말한다.
• 보조 브랜치는 일정 기간 동안만 유지되며 메인 브랜치에 merge된 후 삭제한다.
• 작업별로 생성한 git issue 번호에 맞춰 브랜치명을 작성한다.
  • iss000 (ex. iss38)

 

사전 작업

1. Upstream Repository를 Fork한다.

2. Fork한 Origin Repository를 local로 clone한다.

$ git clone [origin repository HTTPS]

3. Upstream Repository를 Remote Repository로 추가한다.

$ git remote add upstream [upstream repository HTTPS]

 

Branch 흐름

1. Upstream Repository의 브랜치들을 fetch한다.

$ git fetch upstream

 

2. upstream/dev 브랜치에서 main 브랜치로 merge하여 최신화해 준다.(upstream/dev : Upstream Repository의 devBack 또는 devFront 브랜치를 말함)

$ git merge upstream/dev

 

3. main 브랜치에서 해결할 이슈에 대한 작업용 브랜치를 생성한다. (ex. iss10)

$ git checkout -b iss000

 

4. 작업용 브랜치에서 작업을 진행한다.

5. 작업이 끝난 후 작업용 브랜치에서 변경사항을 커밋한다. (Commit Message Convention에 맞춰 커밋한다!)

git commit -a

 

6. 해당 변경 사항을 각자의 Local Repository에서 각자의 Remote Repository로 Push한다. (Upstream Repository에 Push하는게 아님!)

$ git push origin iss000

 

7. Github에서 작업용 브랜치를 upstream/dev 브랜치에 merge하는 Pull Request를 생성한다. (upstream/main에 Pull Request하는게 아님!)

8. 팀원들과 코드 리뷰 후 문제가 없으면 자신의 Pull Request를 merge한다.

• 기본적으로 Rebase and merge를 한다. 이유는 깔끔한 커밋 히스토리를 만들어서 전체적인 흐름을 보기 편하게 하고 싶었다.
• 불필요한 커밋이 많을 경우 Squash and merge한다.
• merge에 대한 내용은 해당 링크를 참고!

9. 해결한 이슈에 대한 작업용 브랜치를 Remote repository에서 삭제한다.

10. 해결한 이슈에 대한 작업용 브랜치를 Local repository에서 삭제한다.

$ git checkout main $ git branch -D iss000

 

11. Branch 흐르 1번부터 반복

 

마무리

코드를 어떻게 짜야할지에 대한 고민만 했었는데, 이번에 Git Flow를 직접 설계해 보면서 백엔드는 정말 고민하고 공부해야 할 범위가 넓다는 걸 새삼 다시 느낀다.

혼자 처음 설계하다 보니 하루 시간을 다 쏟아부어야 했지만 재밌었고 앞으로 시작하게 될 팀 프로젝트 진행에 도움이 될 거라고 생각하니 기쁘다!

개발을 공부하면서 항상 느끼는 갈증이 있는데, 개발자 인맥이 없다 보니 내가 작성한 코드, 전략이 잘한 건지, 부족한 부분은 무엇인지 피드백을 받기 쉽지 않다는 것ㅠㅠ

혹시 잘못된 부분이나 보완해야 할 내용이 있다면 댓글로 남겨주시면 감사하겠습니다 ❤️

 

참조

https://techblog.woowahan.com/2553/

https://inpa.tistory.com/entry/GIT-⚡️-github-flow-git-flow-📈-브랜치-전략

https://git-scm.com/book/ko/v2/Git-브랜치-Rebase-하기

https://evan-moon.github.io/2019/08/30/commit-history-merge-strategy/