* 적용기: 실제 개발에 적용하면서 배우게 된 내용 정리
* 현재 취준생으로 풋내기 개발자가 쓰는 글입니다.
* 그러니 조언과 지적 및 훈수는 언제나 환영입니다! 댓글로 많이 달아주세요!
처음 프로젝트 기획 시 브랜치 전략을 정할 때 그룹 프로젝트에서는 Git Flow를 사용했다.
그리고 지금 하고 있는 개인 프로젝트에서는 Github Flow를 사용했는데,
배운 내용을 정리해보지 못한 것 같아서 한 번 간단하게 나마 적으려고 한다.
** 실제 느낀 점을 적은 것이기 때문에 학습을 위해 보기에는 미흡한 글일 수 있어요!
** 오히려 참고자료에 포함된 자료을 읽는 것을 추천합니당
Git Flow
Git Flow란
팀 프로젝트에서 어떻게 사용했는지 보기 전, Git Flow에 대해 먼저 보자.
Git Flow는 총 5개의 브랜치(master, develop, feature, release, hotfix) 가 사용된다.
- master: production 준비 상태인 branch
- develop: 최신 개발 변경 사항인 braanch
- feature: 새 기능을 개발하기 위한 branch
- develop에서 따와서 작업 후 다시 develop로 병합되어야 함.
- release: 새 production release 준비를 위한 branch
- develop에서 따와서 작업 후 develop와 master에 병합
- 사소한 버그를 수정하거나 release 용 메타 데이터 준비가 수행
- hotfix: 현재 production에서 빠르게 버그를 수정해야 할 때 사용하는 branch
- master에서 따와서 작업 후 develop와 master에 병합
팀에서 사용한 방식
부스트캠프에서 진행한 그룹 프로젝트에서는 이 Git-Flow를 사용해서 branch 전략을 짜게 되었다.
(참고로 당시 우아한 기술 형제 블로그에서 볼 수 있는 Git-Flow 전략을 참고해서 정했다.)
전체 Git 컨벤션은 요 링크에서 확인할 수 있으며, 짧게 요약하면 다음과 같다.
1. upstream/feature/user 브랜치를 생성한다.
2. feature/user에서 작업브랜치(user-ui)를 생성한다.
3. 생성한 branch를 로컬에서 가져온 후에 로컬에서 작업을 진행한다.
4. 만약 commit이 불필요하게 여러 개로 나뉘어져 있다면, squash를 한다.
5. 해당 작업 브랜치에서 작업한 내용을 커밋한 뒤 완료되면, 작업 브랜치를 upstream/feture-user에 rebase 한다.
6. 작업한 내용을 upstream의 feature 브랜치로 PR을 올린다.
7. 리뷰가 끝나고 approve를 받으면 feature branch로 merge 후 작업 상태를 완료로 변경한다.
실제 Git-Flow는 총 5개의 브랜치를 사용하지만
우리는 약 한달 간 개발하며, 추가로 버전 관리를 따로 하지 않고, 출시도 계획에 없었기 때문에
사용한 브랜치는 master, develop, feature 3개가 전부였다.
그룹 프로젝트가 거의 마감에 이르렀을 때는 급한 버그 수정을 위해 종종 hotfix 브랜치를 사용했다.
결과(느낀 점)
Git-Flow에서 실제로 hotfix, release와 같은 branch를 사용하지 않았기 때문에 그대로 가져오지 못하고,
팀 상황에 맞게 정하는 과정에서 시간이 약간 소요되었다.
당연하겠지만, 처음부터 위 Flow대로 간 것은 아니었다.(!)
진행하면서 팀원들끼리 논의해서 중반 쯤 되서야 완전히 적립이 된 것으로 기억한다.
처음 적용하는 입장에서 (merge 방식 등) 그만큼 복잡하다고 느꼈고, 시행착오가 많았다.
Flow 자체가 너무 규칙적 & 체계적이라 유연하지 않은 느낌..
거의 단점만 나열했는데(..) 장점을 전혀 못 느낀 건 아니었다.
참고할 만한 자료(우아한형제블로그)가 있었기 때문에
또한 실제 취업 후 현업에서 일할 때는
유지보수 하는 과정에서 릴리즈 관리나 급한 버그 수정이 종종 있을 것이고, 규모가 훨씬 크고 복잡할 거다.
그래서 Git-Flow 같은 보다 체계적인 branch 전략을 사용할 거라 생각해서, 한 번쯤 경험하기엔 좋은 선택이었다고 느낀다.
결론은! 만약 Git Flow를 다시 사용하게 되는 순간이 오면
아마도 협업 + 어느 정도 규모 있는 프로젝트 + 배포 후 릴리즈 관리 + 철저한 계획 인 상황에서 사용하지 않을까 싶다.
+ 추가로 Android Studio에서는 Git-Flow를 사용할 수 있는 플러그인을 제공한다.
잠깐 사용해본 바로는 branch를 분기하거나 merge 할 때 명령어를 일일히 입력하지 않아도 되는 게 매우 편리했다.
다만 merge 될 때 방식을 아마 정할 수 없는 걸로 기억해서... 팀 프에는 사용하진 않았다.
실제로 나온지 10년이 넘은 Flow라서.. 자료나 이런 플러그인 같은 게 많은 것 같다.
Github Flow
Github Flow란
Github Flow는 Git Flow에 비해서 간단한 workflow로 알려져있다.
또한 역할이 명확한 branch는 master branch 딱 하나다.
- master: 항상 배포할 수 있는 최신 작업 버전 branch.
- production & development
- 안정적인 코드만 반영되어야 한다.
github flow는 hotfix나 feature branch를 따로 구분하지 않으며,
개발 시에는 master에서 branch를 딴 후 개발하여 master에 merge 하는 형식이다.
이 때 master는 안정적인 코드로, master에 merge 할 때는 PR을 권장하며 CI/CD를 필수로 적용하라고 말한다.
적용한 방식
현 시점에 다양한 걸 경험해보고 싶은 내 입장에서,
이미 Git Flow 有경험, 자동화 경험 없음, 개인 프로젝트인 만큼 유연한 Flow 필요, 출시 예정 없음 ⇒ Github Flow로 선택해서 하게 됐다.
내가 개인적으로 스스로 정한 규칙은 다음과 같다.
- 원격 저장소(origin)의 main를 로컬 저장소에서 pull 해서 가져온다.
- 로컬 저장소의 main에서 기능 개발을 위한 브랜치(feature branch)를 만들고 작업한다.
- 기능 개발 전, Github 프로젝트에 이슈를 추가한다.
- docs를 제외한 모든 작업(기능, 디자인, 버그, 리팩토링, 세팅)은 모두 추가한다.
- docs는 main branch에 바로 업로드한다.
- docs를 제외한 모든 작업(기능, 디자인, 버그, 리팩토링, 세팅)은 모두 추가한다.
- 브랜치 이름은 기능이 두드러지도록 한다.
- ex. feature/home-ui
- 기능 개발 전, Github 프로젝트에 이슈를 추가한다.
- 작업한 내역을 원격 저장소에 push 한다.
- 원격 저장소에서 feature branch에서 main branch로 PR을 날리고, 코드 리뷰를 진행한다.
- PR을 날릴 때 체크 리스트를 작성, 스스로 코드 리뷰를 진행한다.
- 코드 리뷰에는 나중에 리팩토링할 코드, 관련 공부 자료 등을 표기한다.
- 코드 리뷰를 하고 난 후, Github Action 수행 결과를 확인, main branch로 merge 한다.
- 이 때 rebase 방식 x
결과(느낀 점)
적용한 후 느낀 점은 역시 Git Flow에 비해서 단순하고, 유연하다고 생각했다.
혼자서 개발하기 때문에, 너무 체계적이면 지키기가 어려워지더라...
그러나 Github Flow가 워낙 단순해서 그런 점을 못 느꼈다.
최소한의 규칙을 세워서 master가 이전 코드의 안정성을 가져가 언제든지 돌아가기 쉽도록 만들었다.
찾아보면서 최대한 commit 메시지와 branch 이름을 명확하게 작성하라고 하는데,
이미 협업한 경험이 있으니 명확하게 작성하고 있고,
commit 메시지에 Github Issue 번호를 넣어서 기능별로 commit을 확인할 수 있기 때문에
명확하지 않아서 느낀 단점은 없었다.
참고 자료
- 우아한 기술 블로그 - 우린 Git-flow를 사용하고 있어요
- Github Docs - Github Flow
- George Stocker - Please Stop Recommeding Git Flow!
- Medium - Git-Flow vs Github-Flow by Quang Nguyen
마치며
어쩌다보니 Git Flow에서는 너무 단점만 언급하고 Github Flow에서는 너무 장점만 언급했지만
최적의 브랜치 전략은 프로젝트 규모나 팀 상황에 따라 달라질 수 있다는 것에 주의하자.
만약 QA나 배포와 같은 상황이 오면 Git-Flow나 GitLab-Flow와 같은 다른 전략이 더 유용할 수도 있다.
실제로 장단점을 비교한 글이 무수히 많고, 우아한 형제 기술 블로그를 보면 알 수 있듯 Github Flow에서 Git Flow로 전략을 바꾸는 경우도 존재하더라.
이번에는 단순히 팀 프로젝트에서, 개인 프로젝트에서 각각 적용해봤지만
다음에는 GitLab Flow를 사용해본다던지, 팀 프로젝트에서 Github Flow를 사용한다던지 등을 경험하게 되면 또 포스팅할 예정이다.
'Git' 카테고리의 다른 글
| [적용기] Git Hooks과 Git Actions로 Android CI 구축하기 (2) | 2023.07.01 |
|---|---|
| [TIL/개념] Git 개체 (0) | 2023.05.07 |
| [TIL/개념] Git 기본: Git의 장점, 기본 명령어, Pull Request (0) | 2023.05.03 |
