Git-flow란?
Git을 사용한 협업의 한 방법으로, git이 갖는 가장 큰 장점은 효율적인 브랜치 관리를 극대화한 방법론이다.
Git-flow
Git-flow에는 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.
master
- 정식 배포되는 안정적 버전의 소스코드
- master 브랜치에는 배포해도 될 만큼 안정성이 충분히 검증된 코드들만이 병합되어야 한다.
- master 브랜치에는 지난 배포판 버전의 소스코드를 확인하기 위한 태그(tag)들을 추가한다.
- 태그를 이용해 각 릴리즈 버전의 소스코드를 확인할 수 있다.
release
- 새로운 버전 릴리즈 준비
- develop 브랜치를 기반으로 생성된다.
- release 브랜치가 생성된 다음 QA 테스트가 release 브랜치 기준으로 진행된다.
develop
- 다음 출시 버전 개발
- 소스코드들이 끊임없이 추가된다.
- 버그 수정 코드, 새로운 기능 추가 코드, 성능 개선 코드들이 검증이 완료되면 여기로 병합된다.
- 개발자는 feature, hotfix 브랜치에서 소스코드를 수정한 다음 develop 브랜치로 Pull Request를 요청한다.
feature
- 새로운 기능개발, 버그 수정을 위한 코드 수정
- 작업된 내용은 pull request를 거처 develop 브랜치에 병합된다.
hotfix
- 출시 버전에서 발생한 버그 수정
- 정기적인 릴리즈 이외에 긴급하게 수행되어야 할 버그 수정을 반영하기 위해 생성되는 브랜치이다.
- master 브랜치를 기반으로 생성된다.
- 작업된 내용은 master에 병합되고 태그를 생성한다.
- master로 병합 이후 수정 내용을 develop 브랜치로도 병합한다.
Git-flow에 따라 관리되는 소스의 소스트리의 형태는 다음과 같다.
회사에서 git-flow를 도입하고 체계적인 소스코드 관리에 한동안 만족하며 개발을 했다. 하지만 개발 작업을 동시에 여러 개 진행하다 보니 소스트리에서 커밋 대환장 파티가 벌어질 조짐이 보였다.
또한 다른 브랜치의 수정사항을 현재 작업하고 있는 브랜치에 반영해야 할 때 Git merge를 사용해서 병합했는데 히스토리 관리 측면에서도, 미관상으로도 깔끔하지 못했다. 찾아보니 Git rebase란 방법이 있었다.
Git rebase
Git rebase는 공통 Base를 가진 브랜치에서, 한 브랜치의 Base를 다른 브랜치의 최신 커밋으로 브랜치의 base를 옮기는 작업이다. 공유 branch에 대한 최신 commit을 반영하면서 작업 해야 할 때 git rebase를 사용하면 작업 branch에서 항상 최신 변경사항을 적용한 commit을 유지 할 수 있다.
rebase를 사용하기 전의 소스 트리가 다음과 같다면,
rebase를 사용하면 히스토리를 다음과 같이 아름답게 관리 할 수 있다.
<참고>
'# Development > Github' 카테고리의 다른 글
| [Github] Sementic Versioning (0) | 2023.01.05 |
|---|---|
| [Github] 작업공간 (0) | 2022.06.27 |
