Editor’s Note
Git Flow는 개발 일을 막 시작한 주니어 개발자에게는 복잡하고 어려운 개념일 수 있지만, 팀 협업과 버전 관리에 매우 유용한 도구인데요. 이번 아티클은 Git 지식이 거의 없이 회사에 입사한 3년 차 백엔드 개발자 명지 님이, 1년 차 때 실무에서 습득한 Git Flow 경험을 정리했습니다.
아래의 글을 읽으며, Git 실무 경험이 부족한 주니어 개발자들이 실질적인 도움을 받을 수 있을 겁니다. Git 배움의 여정을 거친 개발자가 전하는 실용적인 Git Flow 가이드를 만나보세요.
(이 글은 3년 차 백엔드 개발자 명지 님이 2023년 7월 21일 개인 블로그에 게시한 포스트입니다.)
회사에 들어오기 전, 나는 Git을 거의 몰랐다. git commit, git push 등 간단한 작업만 알고 있었고, 이마저도 IDE에서 지원하는 GUI를 활용해 왔다. 내가 들어온 파트에서는 적극적으로 Git Flow 전략을 사용하고 있었고, 회사 서비스 소스코드에 적응하는 것과 동시에 Git에 대해 파악하느라 꽤 고생했던 기억이 있다.
지금은 기본적으로 필요한 Git 작업들은 충분히 숙지 되어있고, 커밋 충돌이나 rebase 작업 등이 필요한 상황에서 어려워하는 파트원들에게 먼저 다가가 도움을 주곤 한다. 1년간 열심히 공부하고 배운 만큼, 이번 기회에 필수적인 내용에 대해 정리해 보고자 한다.
Chapter 1. 파트에서 사용하는 Git Flow
Branch별 역할 (사내 기준)
- main실제 운영에 반영되어 있는 소스 코드들이 있는 브랜치
- release베타 배포 및 베타 QA를 위한 브랜치main 배포 예정인 feature 브랜치들을 release에 취합한 후,Real 배포 전에 release->main으로 merge 한다
- develop알파 배포 및 알파 QA를 위한 브랜치feature 브랜치 개발이 완료되어 알파QA를 원할 경우,배포 일정과 관계 없이 바로 develop 브랜치에 적용하여 알파 환경에서 테스트를 진행한다
- feature기능 개발을 진행하는 브랜치우리 파트에서는 main 브랜치를 기준으로 feature 브랜치를 생성했다(feature 브랜치의 시작 브랜치는 상황에 따라 전략을 다르게 가져갈 수 있을 것 같다)
- hotfixmain 배포 후 급하게 수정해야할 경우 생성되는 브랜치
Chapter 2. Git Flow를 따라 작업해보자
① Github에 이슈업하기
먼저 개발하고자 하는 테스크에 대한 이슈를 github에서 등록한다.
이슈 생성 후 확인 가능한 이슈 번호가 feature 브랜치 번호의 기준이 된다.
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 -> 부모 feature로 merge하는 pr을 올리는 시점에 코드 리뷰를 진행했다. 즉, 부모 feature 브랜치는 해당 기능 개발 건이 완벽하게 되어있다는 보장이 되도록 방향을 잡았다.
$ (feature/10) git switch -c feature/10-1 $ (feature/10-1)
⑤ 개발 진행
이제 자식 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 브랜치까지 최신화 완료! 이어서 개발을 진행하자.
$ (feature/10) git switch feature/10-1 $ (feature/10-1) git pull (origin) feature/10
⑥ Origin에 리뷰 받을 PR 생성하기
$ (feature/10-1) git push origin feature/10-1
이제 개발이 완료되었다면 origin에 올려주자.
우리 파트의 경우, 개발 PR과 연관된 테스크를 dooray에서 따로 작성하고 있어서, 두레이 링크를 함께 첨부해두고, PR 작업 내역에 대해 간단히 소개한다.
그리고 동교들 간의 활발한 코드 리뷰가 이어진다. PR에서 코멘트로 티키타카를 주고 받기 부족하면, 메신저로도 열띤 토론을 펼치곤 한다.
리뷰어의 피드백을 반영하여 소스코드가 수정될 경우,’수정했는데 의도하신 피드백 방향에 맞을까요? 한번 확인해주세요!’라는 의미를 담아 한번더 리뷰어를 멘션걸어 커밋 번호와 함께 답글을 남긴다.
⑦ feature 브랜치에서는 force push도 괜찮다
만일 이미 origin에 올라간 커밋이라고 해도, feature 브랜치, 즉 개인 브랜치의 영역에서는 force push를 허용하기로 했기 때문에 rebase를 자유롭게 활용하고 있다.
물론 코드 리뷰에 대한 피드백을 rebase로 처리하게 되면, 리뷰어가 수정 내역만 보기 어렵다는 단점이 존재하지만, 이건 파트에서 룰을 세부적으로 정해 나가야 할 부분이다.
$ (feature/10-1) git rebase -i abcdef^ -> 터미널에 보여지는 commit 목록 중 수정하고자 하는 커밋의 pick을 edit로 변경 -> 소스코드 수정 후, 수정한 파일을 git add 하고 -> git rebase --continue로 작업 마무리
⑧Merge Pull Request
코드 리뷰에 참여한 사람들의 approve가 확인되면 이제 부모 feature 브랜치로의 Merge를 진행한다. 우리 파트는 merge branch가 생기는 걸 방지하기 위해,
Rebase and merge 옵션을 선택하고 있다.
Chapter 3. 브랜치 관리와 배포
① feature -> develop
feature 개발이 완료되었다면 alpha QA를 위해 develop에 feature 브랜치를 merge 한다. 알파 QA 과정에서 결함 건이 발견되었다면, 다시 자식 feature 브랜치를 생성하여 작업을 반복한다.
② feature -> release
알파 QA가 끝나고 배포 일정이 정해졌다면, 배포 전 베타 QA 기간에 맞춰 release에 feature 브랜치를 merge 한다. 베타 QA 과정에서 결함 건이 발견되었다면 다시 자식 feature 브랜치를 생성하여 작업을 반복한다.
③release -> main
release->main으로 merge 하기 전, release 브랜치는 베타 QA 후 결함건 수정까지 완료되어있는 상태다. 실제 배포일에 release 브랜치를 main으로 merge하고, main 브랜치를 기준으로 운영 환경에 배포를 진행한다.
④hotfix
만일 main 배포 후 급한 수정건이 발생할 경우, main 브랜치를 기준으로 hotfix 브랜치를 생성하여 빠르게 수정 작업을 진행한다. (hotfix를 만드는 사람이 내가 아니길 항상 빌고 있다.)
$ (main) git switch -c hotfix/10
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 전략에 많이 익숙해져 있다는 것을 깨달았다. 이를 계기로 다양한 Git 전략들을 찾아보며 지식을 새롭게 하고 확장해야겠다.
항해99는 다양한 배경과 경력을 가진 개발자들의 생생한 경험담을 여러분과 공유하고자 합니다. 이러한 이야기들을 통해 개발자 여러분이 서로의 경험에서 배우고 함께 성장할 수 있는 기회를 만들어갈 것입니다. 앞으로도 실제 현장의 목소리를 담은 유익한 콘텐츠로 여러분의 개발 여정에 든든한 동반자가 되겠습니다.
🚢 개발자 이직 준비, 어떻게 시작해야 할지 모르겠나요? 한 단계 더 도약하는 험난한 항해에서 든든한 메이트가 되어드리겠습니다.
성장의 한계를 느끼고 있는 주니어 개발자들은 항해 플러스 백엔드/프론트엔드 코스와 함께 하시면 됩니다. 기본기 역량 강화부터, 커리어 점프시켜 줄 TDD / 성능최적화, 대용량 트래픽 처리, 장애 대응 프로젝트와 이직 코칭까지 한번에 할 수 있습니다. 성장을 향한 강한 의지만 있다면 항해 플러스 10주 성장 코스로 이직을 도전해보세요.
가파르게 성장하는 AI 산업에서 AI 기술을 실무에 적용할 수 있는 역량을 키우고 싶다면 항해 플러스 AI 코스에 합류하세요. 딥러닝 이론과 자연어 처리, LLM 원리와 활용 및 구현, 클라우드 환경 배포 및 파인 튜닝 그리고 AI 전문가의 이직 코칭과 포트폴리오 코칭까지 항해 플러스 AI 코스에서 한 번에 할 수 있습니다. 갈수록 중요해지는 AI 활용 능력, 항해 플러스 AI 코스로 8주 만에 떠오르는 AI 인재로 도약하세요.
CREDIT
글 | 3년차 백엔드 개발자 김명지
Share article
Subscribe to our newsletter