Git Branch 전략
Git Branch 전략은 Git Branch를 효과적으로 사용하기 위한 WorkFlow로
프로젝트의 특성에 맞춰 규칙을 정함으로 프로젝트의 팀원들은 통일된 방식으로 Branch를 사용할 수 있습니다
Git Branch 전략은 Git Flow, Github Flow 등 자주 사용되는 여러 전략이 존재하는데
이 글에서는 쉽게 사용할 수 있는 전략 중 하나인 Github Flow를 사용하도록 하겠습니다
Github Flow
- branch 종류
- main(master): 실제로 배포되는 버전을 관리하는 브랜치
- feature : 개발이 이루어지는 브랜치
- Github Flow 단계
- 신규 기능 개발을 할 때, main 브랜치에서 feature 브랜치를 따서 개발 진행
- 개발이 완료되면 Pull Request(Merge Request) 를 생성하여 Review 를 요청
- Review가 완료되면 해당 feature 브랜치를 main브랜치로 Merge
자 이제 단계별로 작업을 진행하며 어떻게 사용하는지 알아봅시다
Git 단계별 사용
1. 외부 저장소에서 Local로 가져오기
외부 저장소는 대표적으로 Github Gitlab 등이 존재합니다
작업할 컴퓨터(Local)의 폴더에서 git bash와 같은 도구를 사용, 작업할 프로젝트를 가져옵시다
git clone `레포지토리 주소`
2. 작업할 feature 브랜치 만들기
main 브랜치는 배포되는 버전을 관리하기 때문에 이 브랜치에서 바로 작업을 하다가 문제가 생기면 배포되고 있는 애플리케이션에 바로 문제가 생기게 됩니다.
따라서, 작업용 브랜치를 따로 파서 작업을 하고 확실히 검토가 끝난 뒤에 main 브랜치에 merge를 하는 과정이 필요합니다
git branch를 만들어 봅시다
# 브랜치명으로 branch 생성
git branch `브랜치명`
# 생성한 branch로 이동
git checkout `브랜치명`
# 위의 두 코드를 한 줄로 사용
git checkout -b `브랜치명`
branch명도 팀원과 함께 네이밍 규칙을 정해서 사용하는 것이 좋습니다
ex)
{branch-type}/{issue-number}-{feature-name}
feature/#12-sign-up
위와 같이 한눈에 알아보기 좋은 네이밍 규칙을 정해봅시다
3. 작업 내용 Commit 하기
맡은 기능의 작업이 완료된 후 변경사항을 기록해봅시다
# 작업한 모든 변경 사항을 커밋 준비
git add .
# 커밋 준비 상태인 모든 변경 사항 확인
git status .
# 커밋 준비중인 변경 사항 기록하기
git commit -m "커밋 메세지"
커밋 메세지도 팀원과 함께 규칙을 정해서 사용하는 것이 좋습니다
ex)
Header : 타입: 제목
Body : 내용
Footer : 관련 이슈
feat: 회원가입 기능 구현
아이디와 비밀번호를 입력받아 회원가입하는 기능 구현
Resolves: #12
위와 같이 커밋 메세지 규칙을 정해봅시다
4. Commit한 변경 사항 원격 저장소에 Push하기
이제 작업한 내용을 원격 저장소에 보내봅시다
# 로컬 브랜치의 변경 사항을 원격 저장소의 지정된 브랜치에 푸시
git push `원격 저장소명` `브랜치명`
ex) git push origin main
5. PR/MR 요청, Review 후 main 브랜치에 Merge
이제 작업한 내용이 괜찮은지 Review를 받아 봅시다
Github에서는 Pull Request, GitLab에서는 Merge Request를 사용하는데 각 의미를 알아봅시다
Pull Request : 변경사항을 적용하였으니 이를 Pull해서 코드베이스에 반영해 주세요.
Merge Request : 변경사항을 적용하였으니 이를 Merge해서 코드베이스에 통합해 주세요.
즉, Pull 한 이후 다음과 같은 과정이 진행 됩니다
변경사항 Push -> Review 진행 -> main브랜치에 Merge -> 변경사항 적용 -> 작업자들 Pull해서 변경사항 반영
더 이상 필요가 없어진 feature1 브랜치는 히스토리를 깔끔하게 하기 위해 제거 할 수도 있습니다
원격 저장소에서 PR/MR 시 제거하는 옵션을 사용할 수도 있고 아래와 같은 코드를 사용할 수도 있습니다
git branch -d `브랜치명`
6. 변경사항 Pull해서 코드베이스에 반영
기존에 브랜치를 파서 작업하던 main 브랜치가 변경되었으니 변경 사항을 적용할 필요가 있습니다
이 과정에서 여러 충돌 사항이 발생할 수 있으므로 이를 해결해야 합니다
대부분의 git 저장소에서 쉽게 충돌 사항을 해결할 수 있지만 이는 위험합니다
충돌 사항을 main에서 Merge하는 단계에서 잘못 해결한다면 이는 배포되는 main 브랜치에 바로 적용되기 때문입니다
따라서, 로컬에서 미리 충돌 사항을 해결한 후 이 역시 Review를 진행하는 것이 좋습니다
변경사항을 코드베이스에 반영하는 두 가지 방법을 알아 봅시다
1) Merge
git checkout `작업 브랜치명`
# main에 변경사항을 pull 해온 후 merge
git pull origin main
git merge main
# 충돌 해결 후 커밋
git add .
git commit -m "커밋 메세지"
# 원격 저장소에 push
git push origin `작업 브랜치명`
2) Rebase
git checkout `브랜치명`
# main에 변경사항을 pull 해온 후 merge
git pull origin main
git rebase main
# 충돌 해결
git rebase --continue
# 이미 수정 내용 적용, commit 불필요
# 원격 저장소에 push, 히스토리가 변경됐으므로 --force 필요
git push origin feature --force
그렇다면 어느 방법을 사용해야 할까요? 다음의 장단점을 고려하여 선택해 봅시다
- Merge: 히스토리를 보존하지만, 히스토리가 복잡해질 수 있습니다.
- Rebase: 히스토리를 깔끔하게 유지할 수 있지만, 공유된 브랜치의 히스토리를 제거할 수 있어 주의해야 합니다
특히, Rebase 시, "이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라"를 명심합시다
간단히 그 이유를 알아보면, Rebase는 히스토리를 제거하기에 그 이전에 Pull 해 온 작업자의 히스토리와 Rebase를 진행한 후 Pull을 한 작업자의 히스토리가 꼬여서 Pull을 해올때마다 양쪽의 코드는 엉망이 될 것입니다
협업 시 기본적으로 Git을 사용하는 방법들을 알아보았습니다
프로젝트에 알맞은 사용 방법을 팀원과 규칙을 정하여 효율적인 Git 활용을 위해 노력해봅시다