이번 글에서는 실무에서 깃을 통해 어떤 형식으로 프로젝트 버전관리를 하는지 포스팅 해보려 한다.
많은 방법론 중 실무에서 많이 쓰인다는 Git flow에 대해 알아봅시다! (대형 서비스 기업들이 대부분 사용!)
💁🏻 GIt flow ?
아래 그림은 깃 플로우를 설명할 때 가장 많이 쓰는 그림? 이다.
한 번 살펴보고 개발자의 입장에서 어떤 플로우일지 예상해보자.
master branch
실제 운용되고 있는 서비스(안정적이어야 함 => 맘대로 merge되면 큰일...)
developbranch
다음 버전 개발을 위해 실제 개발되고 있는 브랜치! 다음 버전이 준비되면 master에 merge됨
feature branch
다음 버전에 들어갈 기능 개발을 위해 develop 브랜치에서 새로운 브랜치를 생성해 추후 develop에 merge됨
hotfixed branch
운용중인 서비스에 버그가 생기거나 우선순위가 높은 작업이 있을 때 빠르게 운용 서비스에 merge될 수 있도록 하는 역할을 하는 브랜치 보통 develop, master 두 개에 merge함
release branch
테스트 후 제품 배포를 준비하는 브랜치
간략하게 설명하자면 위와 같다.
실제 개발하는 것을 예시로 설명하자면
개발자 Kenny는 서비스에서 header 부분 리뉴얼을 위해 develop 브랜치에서 feature/header 브랜치를 새롭게 만들어서 관련 코드를 작업하고, develop으로 Pull request를 날렸다. 그 후 동료에게 코드 리뷰를 받고 작업한 코드가 develop에 merge가 됐다. release 브랜치에 develop브랜치 작업 내용들이 merge가 됐지만 조금 수정 사항이 있어 해결한 후 실제 운용 브랜치인 master에 merge되어 실제 서비스에서 헤더가 리뉴얼 된 걸 확인할 수 있다.
그러나 header 반응형에서 오류가 발생했다. 당황하지 않고 hotfixed 브랜치를 따서 빠르게 해결한 후 바로 master 브랜치에 merge해 해결했다. 물론 해당 버그를 해결하고 develop에도 merge했다.
git flow 방식을 왜 사용하는 걸까?
개인적인 생각일 수 있지만 프로젝트 버전관리가 훨씬 간편해지는 느낌이 든다.
git flow는 단순히 브랜치를 본인이 생성해서 하는 것이 아니라 git flow init을 통해 사용자가 편리하게 프로젝트를 관리할 수 있도록 제공해주는 점이 매력적이며, 서비스 또한 안정적으로 운용할 수 있는 것이 장점이다.
위 예시를 살펴봐도 개발자의 실수에 대한 책임을 최소화하고, 본인이 개발하고 싶은 것들을 자유롭게? 실험정신을 가지고 개발할 수 있을 것 같다.
git flow의 단점은?
장점만 있는 건 아니다.
git flow 방식은 해당 방식에 맞는 소프트웨어에서 전략적으로 사용했을 때 빛을 발하며, 단점도 물론 존재한다.
1. 엄청난 브랜치 개수로 인한 관리에 어려움
새로운 기능 개발을 위해 각자 develop에서 하나의 기능을 개발하는 브랜치를 계속 계속 따게되면 브랜치 수가 감당되지 않을 수 있다.
2. 모호한 브랜치 명?
보통 jira나 click up에서 기능과 관련된 카드를 만들어 그 카드의 고유번호를 가지고 branch명을 생성한다 예로 header 리뉴얼 카드를 만들면 위와 같이 #2rwxkeu라는 고유값이 생기며 사람들은 관련 브랜치를 생성할 때 해당 고유값을 사용한다. ex) feature/service-#2rwxkeu
git flow를 설정해보자
$ apt-get install git-flow
$ git flow init // 계속 엔터 누르세요! ⛔️ Working tree contains unstaged changes. Aborting. 변경사항이 아예 없을 때 설정할 수 있으므로 기존 프로젝트에 적용할 때는 git stash를 사용해 현재 변경사항을 다른 곳에 저장해주고 git flow 설정 후 git stash pop을 이용해 가져오도록 하자
그리고 git branch를 입력해보자!
develop 브랜치가 생겼다. 위에는 master 브랜치라 했지만, main 브랜치도 똑같은 역할을 한다..!
✔︎ github에서 master => main 으로 기본값이 바뀌었다
git flow를 사용해보자
만약 현재 어떤 기능을 개발하기 위해 새로운 브랜치를 딴다고 생각해보자.
원래 깃이었다면 git branch <브랜치명> 으로 생성했겠지만, 깃 플로우는 다르다!
1. 일단 진짜 개발 환경이라 생각해보자. 그럼 일단 develop의 코드를 가져와야되고,
2. 이제 시작하는 단계면 로컬 단계의 develop 브랜치를 github에 반영 시켜보자!
⛔️ 이미 구성된 개발 환경일 때 ⛔️
$ git checkout develop // develop 브랜치로 이동!
$ git fetch origin develop // 원격 저장소에서 업데이트 받을 내용이 있는지?
$ git flow feature start -F <브랜치 명> // 이러면 feature/<브랜치 명> 의 브랜치가 생성되고 자동으로 이동된다.
해당 브랜치에서 개발할 기능에 대해 커밋을 계속 진행한다!
적절히 코드를 잘 수정 했다면
$ git add . // 파일 add
$ git commit -m "feat: 헤더 리뉴얼" // 커밋 및 메시지 작성
$ git flow feature publish beakjoon // 다른 사람들이 결과물을 볼 수 있도록 원격 저장소에 브랜치 게시
✔︎ git flow feature publish beakjoon 명령어를 사용하지 않고 git push origin feature/beakjoon 해도 상관 없지만 git flow feature publish beakjoon 명령어를 한 번 사용하면 업스트림 브랜치로 자동 등록되어 추후 git push만 해도 알아서 잘 올라 간다. (⛔️ 해당 브랜치에서 작업할 때 만이다! (git push === git push <현재 브랜치>))
그 후 저장소를 가보자!
상단에 pull request 버튼이 생겼다..!
🎉 feature 브랜치로 작업한 내용을 ⛔️develop⛔️ 브랜치에 pr을 날려 merge할 기회가 생긴 것이다
본인은 test라 대충 작성했지만 pr내용을 코드 리뷰를 하는 동료가 명확하게 어떤 작업을 했는지 이해할 수 있도록 잘 작성하고!
오른쪽에 Assignees도 지정 하고 Labels도 달고 팀 단위로 예시를 들었으니 위에 Reviewer도 지정해주도록 하자!
동료의 코드리뷰가 끝났다면?
실무에서는 QA라고 한다 보통, 모든 QA가 끝났다면 (코드, 디자인 등등?)
팀 마다 규칙이 다르긴 하지만 보통 본인이 Develop 브랜치에 merge한다.
해당 버튼을 누르면 merge가 완료된다. 만약 코드 파일들이 충돌되어 Conflilct 날 수 있지만 그건 수정으로 해결하고 다시 merge해주도록 하자.
