세가지 브랜치 관리 전략

대표적으로 브랜치 관리 전략에는 Git flow, Github flow, Gitlab flow 3가지가 있다. 로컬 git을 리모트환경의 github 메인에 푸시하던 방식은 github flow로 가장 간단한 브랜치 관리 방법이다.

깃 플로우만 이해하면 다른 전략들은 간소화 된 내용이기 때문에 쉽게 이해할 수 있다.

Git flow

깃 플로우는 대표적인 브랜치 관리 전략이다. 실제 프로덕션 레벨의 서비스를 개발하고 안정적으로 운영하기 위해서는 브랜치 관리의 필요성이 대두된다. 여러명의 개발자가 협업하기 위해서 필수적인 방법이다.

들어가기

Git flow는 총 다섯개의 브랜치로 이루어진다.

• main (production level)
• develop
• feature
• release(QA)
• hotfix
  

메인 브랜치의 커밋 단위는 실제 프로덕션 버전명으로 짓는다. 가장 최신화 된 기능이 있는 메인 브랜치로부터 가지를 시작해 디벨롭 브랜치를 생성한다. 여기서 디벨롭 브랜치는 각 개발자들이 만든 기능들을 모두 합치는 곳이다. 그러므로 각자 기능개발은 피처 브랜치를 생성해 진행한다.
feature/signup feature/login 등 각 기능들이 완료되면 디벨롭 브랜치에 푸시 하거나 PR로 피어리뷰를 마친 후 머지한다.

다음 릴리즈 버전 준비가 완료됐을 때 QA(quality assurance)를 위한 릴리즈 브랜치를 생성한다. 테스트를 통해 발견된 버그들은 해당 브랜치에서 수정되어 최종 메인 브랜치로 배포된다. 그리고 여기서 발견되어 수정된 결함들은 디벨롭 브랜치와 피처 브랜치에도 반드시 최신화 시켜준다.

여기서 끝나면 정말 해피엔딩이겠지만 실제 서비스를 운영하는 도중에 버그를 발견하게 될 경우도 있다. 그러나 이 버그는 디벨롭 브랜치에서 수정할 수 없다. 이미 다음 릴리즈 버전의 기능들이 포함되어 있을 가능성이 크기 때문이다. 또한 실제 운영중인 서비스의 결함은 치명적이기 때문에 핫픽스 브랜치에서 빠르게 수정한다. 그리고 마찬가지로 수정된 버그들은 반드시 최신화 시켜주어야한다.

깃 플로우가 반드시 최선의 방법은 아니다.

복잡성은 큰 단점이다. 개발자들이 깃 플로우에 익숙해지는 러닝커브가 길고 실제 브랜치가 여러개로 관리될 경우 최신화되지 않을 경우에 버전이 꼬일 가능성이 크기 때문이다.

때문에 우리는 브랜치를 잘 관리하기 위해선 가장 작은 단위인 커밋을 잘 해야한다. 그렇다면 커밋을 어떻게 관리해야할까?

브랜치를 병합하는 두가지 방식

Git merge

깃 머지의 가장 큰 단점은 커밋 기록이 시간 순서대로 모든 커밋이 뒤섞인다는 것이다. 이는 커밋을 브랜치 별로 구분해서 보기 어렵고 유지 보수가 어려워진다. 게다가 머지를 진행할 때마다 불필요한 머지 커밋도 남게 된다.

Git rebase

머지의 불편한 단점을 해소하기 위해서 리베이스 명령어가 등장하게 됐는데, 리베이스를 하게 되면 기능 안에서 시간순 정렬이 된다. 흐름을 파악하기 용이하고 커밋을 깔끔하게 관리할 수 있다. 리베이스는 말그대로 기존 커밋 내용을 새롭게 커밋 하는 거기 때문에 해시값이 아예 달라진다.
이 과정에서 불필요한 커밋을 하나로 squash하거나 커밋 메세지도 변경 가능하다.

주의해야할 점

• git pull origin main 메인 브랜치를 최신화하고 진행하기
• git push origin feature/readme -f 이미 리모트 환경에 push된 히스토리가 존재할 경우 로컬에서 리베이스 한경우 force push를 진행해야한다 (큰 주의를 요함)
• git rebase [—abort | —continue]

• 컨플릭트 났을 때 , 해결한 후

git add . 
git rebase —continue