주니어 개발자의 현업에서 배운 Git Flow

⏰ 읽는 시간: 10분

들어가기 전

회사에 들어오기 전, 나는 Git을 거의 몰랐다
git commit, git push 등 간단한 작업만 알고 있었고 이마저도 IDE에서 지원하는 GUI를 활용해왔다.
내가 들어온 파트에서는 적극적으로 Git Flow 전략을 사용하고 있었고
회사 서비스 소스코드에 적응하는 것과 동시에 Git에 대해 파악하느라 꽤 고생했던 기억이 있다.

지금은 기본적으로 필요한 Git 작업들은 충분히 숙지되어있고
커밋 충돌이나 rebase 작업 등이 필요한 상황에서 어려워하는 파트원들에게 먼저 다가가 도움을 주곤 한다

😎😎😎
1년 간 열심히 공부하고 배운 만큼, 이번 기회에 필수적인 내용에 대해 정리해보고자 한다

(+ 본 포스팅은 하이라이팅이 많이 첨부되어 있습니다. 다크모드 대신 라이트모드로 읽는 것을 권장드립니다.)

---

파트에서 사용하는 Git Flow

출처: https://blog.jetbrains.com/space/2023/04/18/space-git-flow/

Branch별 역할 (사내 기준)

• main
  실제 운영에 반영되어 있는 소스 코드들이 있는 브랜치
• release
  베타 배포 및 베타 QA를 위한 브랜치
  main 배포 예정인 feature 브랜치들을 release에 취합한 후,
  Real 배포 전에 release->main으로 merge 한다
• develop
  알파 배포 및 알파 QA를 위한 브랜치
  feature 브랜치 개발이 완료되어 알파QA를 원할 경우,
  배포 일정과 관계 없이 바로 develop 브랜치에 적용하여 알파 환경에서 테스트를 진행한다
• feature
  기능 개발을 진행하는 브랜치
  우리 파트에서는 main 브랜치를 기준으로 feature 브랜치를 생성했다
  (feature 브랜치의 시작 브랜치는 상황에 따라 전략을 다르게 가져갈 수 있을 것 같다)
• hotfix
  main 배포 후 급하게 수정해야할 경우 생성되는 브랜치

---

Git Flow를 따라 작업해보자

Github에 이슈업하기

먼저 개발하고자 하는 테스크에 대한 이슈를 github에서 등록한다

이슈 생성 후 확인 가능한 이슈번호가 feature 브랜치 번호의 기준이 된다.
(ex. feature/#26)

local의 main 브랜치 최신화하기

$ git switch main
$ (main) git fetch
$ (main) git pull origin main

git log로 local main의 최신 커밋이 origin main의 최신 커밋과 동일한지 체크해주자

부모 feature 브랜치 생성하기

이슈 번호는 10으로 가정하고 진행하겠다

$ (main) git switch -c feature/10
$ (feature/10) git push origin feature/10

자식 feature 브랜치 생성하기

$ (feature/10) git switch -c feature/10-1
$ (feature/10-1)

우리 파트의 경우 자식 feature -> 부모 feature로 merge하는 pr을 올리는 시점에 코드리뷰를 진행했다
즉, 부모 feature 브랜치는 해당 기능 개발건이 완벽하게 되어있다는 보장이 되도록 방향을 잡았다

개발 진행

이제 자식 feature 브랜치에서 자유롭게 개발을 진행한다
파트에서 commit 명에 대한 세세한 규칙은 아직 정하지 않았지만
최근 유지보수를 하다보니 커밋만으로 이슈와 PR을 찾기가 어려워 히스토리 추적이 오래 걸렸던 적이 있었다.
그래서 방법을 고민하다가 커밋명 앞에 이슈번호를 붙여주는 방법을 선택했다.
(혼자서만 도입한 방법이라 슬금슬금 파트에 커밋 네이밍 룰을 전파해볼 생각이다)

AS-IS

TO-BE

TO-TO-BE (07.28.업데이트)

최근에 새로 알게 된 사실..
rebase 작업 후 터미널에서 커밋 메시지 정리하고 마치려는데

커밋 맨 앞에 붙은 #으로 인해 해당 라인이 전체 주석 처리가 되어버린 이슈가 있었다

그래서 현재는 [#이슈번호] 커밋메시지 패턴으로 작업하고 있다.

---

개발을 진행하다 main 브랜치가 최신화되는 경우가 있을 수 있다
추후 conflict을 방지하기 위해 상시로 feature 브랜치를 최신화해주어야 한다

$ (feature/10-1) git switch feature/10
$ (feature/10) git pull (origin) main --rebase
$ (feature/10) git push origin +feature/10

부모 feature 브랜치를 무시하고 자식 feature 브랜치에서만 main을 pull rebase 받아오면 안된다
왜냐하면 main -> feature/10 -> feature/10-1 순서로 브랜치를 따왔기 때문에 이 순서를 지켜주어야 한다 !

이때 rebase 옵션을 주는 이유는 feature 브랜치에서 추가된 커밋이 항상 HEAD에 올 수 있도록 하기 위해서다. 작업 시간대별로 commit 순서가 정렬되면 추후 커밋 리스트 보기가 힘들어진다.

최신화가 완료된 부모 feature 브랜치를 origin에 push할 때는 경우에 따라 force push가 필요할 수 있다(+)
사실 나는 귀찮아서 항상 붙여주긴 한다..

$ (feature/10) git switch feature/10-1
$ (feature/10-1) git pull (origin) feature/10

이제 자식 feature 브랜치까지 최신화 완료! 이어서 개발을 진행하자

Origin에 리뷰 받을 PR 생성하기

$ (feature/10-1) git push origin feature/10-1

이제 개발이 완료되었다면 origin에 올려주자

우리 파트의 경우, 개발 PR과 연관된 테스크를 dooray에서 따로 작성하고 있어서 두레이 링크를 함께 첨부해두고, PR 작업 내역에 대해 간단히 소개한다

그리고 이어지는 활발한 코드리뷰! 🥳
PR에서 코멘트로 티키타카를 주고 받기 부족하면 메신저로도 열띤 토론을 펼치곤 한다

우리 파트는 누군가의 코드에 대해 다같이 열심히 고민해주는 분위기라 다같이 성장하기 좋은 것 같다 👍

리뷰어의 피드백을 반영하여 소스코드가 수정될 경우,
수정했는데 의도하신 피드백 방향에 맞을까요? 한번 확인해주세요!라는 의미를 담아 한번더 리뷰어를 멘션걸어 커밋 번호와 함께 답글을 남긴다.

만약 리뷰어가 수정한 커밋에 대해 만족한다면, 👍을 남겨주고 해당 대화는 resolve 처리를 한다.

feature 브랜치에서는 force push도 괜찮다

$ (feature/10-1) git rebase -i abcdef^
-> 터미널에 보여지는 commit 목록 중 수정하고자 하는 커밋의 pick을 edit로 변경
-> 소스코드 수정 후, 수정한 파일을 git add 하고
-> git rebase --continue로 작업 마무리

만일 이미 origin에 올라간 커밋이라고 해도
feature 브랜치, 즉 개인 브랜치의 영역에서는 force push를 허용하기로 했기 때문에 rebase를 자유롭게 활용하고 있다.

물론 코드리뷰에 대한 피드백을 rebase로 처리하게 되면
리뷰어가 수정 내역만 보기 어렵다는 단점이 존재하긴 하지만..
이건 파트에서 룰을 세부적으로 정해나가야할 것 같다

Merge Pull Request

코드 리뷰에 참여한 사람들의 approve가 확인되면 이제 부모 feature 브랜치로의 Merge를 진행한다
우리 파트는 merge branch가 생기는걸 방지하기 위해 Rebase and merge 옵션을 선택하고 있다

merge 옵션별 설명은 https://im-developer.tistory.com/182 포스팅에서 너무 설명이 잘 되어 있다

feature -> develop

feature 개발이 완료되었다면 alpha QA를 위해 develop에 feature 브랜치를 merge 한다.
알파 QA 과정에서 결함 건이 발견되었다면 다시 자식 feature 브랜치를 생성하여 작업을 반복한다.

feature -> release

알파 QA가 끝나고 배포 일정이 정해졌다면, 배포 전 베타 QA 기간에 맞춰 release에 feature 브랜치를 merge 한다. 베타 QA 과정에서 결함 건이 발견되었다면 다시 자식 feature 브랜치를 생성하여 작업을 반복한다.

우리 파트에서는 정해진 배포 일에 여러 feature 개발건이 배포가 나갈 경우,
release에 배포나갈 feature 브랜치들을 취합한다고 표현하고 있다.

release -> main

release->main으로 merge 하기 전, release 브랜치는 베타 QA 후 결함건 수정까지 완료되어있는 상태다.
실제 배포일에 release 브랜치를 main으로 merge하고 main 브랜치를 기준으로 운영 환경에 배포를 진행한다.

hotfix

$ (main) git switch -c hotfix/10

만일 main 배포 후, 급한 수정건이 발생할 경우 main 브랜치를 기준으로 hotfix 브랜치를 생성하여 빠르게 수정 작업을 진행한다. hotfix를 만드는 사람이 내가 아니길 항상 빌고 있다.

hotfix 브랜치 작업이 완료되면 다시 hotfix->main으로 merge 하여 main 브랜치를 기준으로 배포한다

main 배포 후에는 꼭 브랜치 최신화를!

main 배포 후에는 develop과 release 브랜치가 main에 있는 커밋을 모두 가질 수 있도록 최신화를 진행해야한다. 종종 배포 담당자가 이를 놓치게 되는 경우가 있는데, 최신화가 적절한 시점에 되어 있지 않으면 추후 conflict이 발생할 가능성이 높고 공용 브랜치다보니 빠르게 원인을 찾아 바로 해결하기 어려운 경우가 발생한다.

develop 브랜치가 복구가 어려울 정도로 꼬여있으면 브랜치 삭제 후, main 기준으로 다시 develop 브랜치를 생성해야 한다. 이럴 경우 develop 브랜치에만 알파QA 할 feature 브랜치를 merge 해둔 개발 담당자들은 이 작업을 1번더 해야 하기 때문에 번거로운 상황이 온다 🥺
꼭 브랜치 최신화는 바로바로 챙겨주자!

---

정리하며

여기까지 파트에서 사용하고 있는 Git Flow 전략을 좀더 상세하게 정리해보았다
git 백지 상태에서 1년 동안 열심히 공부해서 여기까지 성장할 수 있어서 다행이라는 생각이 든다
이제 정말 Git이 왜 편한지 알게 되었다!
그리고.. rebase가 무섭지 않게 될 때, 정말 열심히 공부했구나를 느꼈다😎

머릿속에만 그려두고 있다가 처음으로 글로 정리해보았는데
우리 파트의 git flow 전략에 많이 적응되어 있어서
refresh를 위해 다른 git 전략도 찾아보며 다양하게 알아두어야겠다는 생각이 문득 들었다 :)

오늘의 포스팅은 여기까지!