Git Flow에서 Rebase & PR 보내는 방법 완벽 정리 🚀 | 협업을 위한 깔끔 가이드
현재 진행 중인 프로젝트에서 Git Flow에서 rebase 전략을 적용하여 커밋 히스토리를 정리하고, 협업 효율을 높이는 방식을 도입했습니다.
저를 포함한 모든 인턴이 rebase를 처음 접했기 때문에, rebase의 개념부터, 실제 팀 내에서 적용한 전략과 워크플로우까지 정리해보겠습니다.
Git 전략
📌 Branch 구조
우리 팀은 Git Flow를 기반으로 배포, 테스트, 개발을 위한 브랜치를 구분하여 운영하고 있습니다.
branch
- production(배포용)
- staging(테스트용)
- develop(개발용)
- feature(Jira issue 번호)
➡ 실제 작업은 develop과 feature 브랜치에서만 진행하며, 배포 시 production으로 병합됩니다.
📌 Branch 생성 방법
Jira 이슈 번호를 기반으로 기능 개발 브랜치를 생성합니다.
✅ 예시
git checkout develop # 항상 develop에서 브랜치 따기
git pull upstream develop # 최신 상태 유지
git checkout -b USER-14➡ USER-14라는 Jira 이슈를 기반으로 새로운 기능 개발 브랜치 생성
📌 Commit Message Convention
feature 브랜치에서 작업 후 구현이 다 끝나면 commit 해야합니다.
Jira에서 큰 이슈 단위로 브랜치를 생성하고, 각 하위 이슈에 대한 변경 사항은 개별 커밋으로 기록합니다.
[Feat/USER-14] 로그인 기능 gql 추가
Feat | 새로운 기능 추가 |
|---|---|
Fix | 버그 수정 |
Docs | 문서 수정 |
Style | 코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우 |
Refactor | 코드 리팩토링 |
Test | 테스트 코드, 리팩토링 테스트 코드 추가 |
Chore | 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore |
Design | CSS 등 사용자 UI 디자인 변경 |
Comment | 필요한 주석 추가 및 변경 |
Rename | 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우 |
Remove | 파일을 삭제하는 작업만 수행한 경우 |
!HOTFIX | 급하게 치명적인 버그를 고쳐야 하는 경우 |
📌 Git Rebase란?
rebase는 현재 브랜치의 변경 사항을 다른 브랜치의 최신 상태 위로 재배치하는 Git 명령어입니다.
즉, 커밋 히스토리를 정리하고 불필요한 병합 커밋을 최소화하여, 보다 깔끔한 히스토리를 유지하는 역할을 합니다.
📍 기본적인 merge와 rebase의 차이점
| 전략 | 설명 | 특징 |
|---|---|---|
| merge | 두 브랜치를 합치면서 새로운 병합 커밋(merge commit)을 생성 | 커밋 히스토리에 병합 흔적이 남음 |
| rebase | 현재 브랜치를 다른 브랜치 위로 재배치 | 히스토리가 깔끔하게 유지됨 |
보통 git merge를 사용하면 "병합 커밋"이 누적되면서 히스토리가 복잡해질 수 있습니다.
반면, rebase를 사용하면 각 브랜치의 변경 사항을 선형으로 정리할 수 있어 커밋 히스토리가 더욱 직관적이 됩니다.
📌 Git Rebase 적용 프로세스
1️⃣ push 전에 항상 Rebase 진행
➡ 🚨 기본 원칙: PR(Pull Request) 전에는 반드시 rebase 수행
1. 회사 레포를 Fork하고 Clone하기
우리 팀은 각자의 GitHub 계정에서 회사 레포를 Fork한 후, 해당 Fork 레포를 Clone하여 작업했습니다.
이때 원본 회사 레포를 **upstream**으로 지정하여 항상 최신 상태를 유지해야 했습니다.
✅ 초기 설정 (최초 1회만 수행)
git clone [내 Fork 레포 주소]
cd [레포 이름]
git remote add upstream [회사 레포 주소] # upstream 등록✅ 작업 시작 전 항상 최신 상태 유지
git checkout develop
git pull upstream develop # 원본 레포에서 최신 코드 가져오기2. 새로운 작업 브랜치 생성
각 이슈별로 새로운 feature 브랜치를 생성하여 작업합니다.
git checkout develop
git pull upstream develop # 최신 상태 유지
git checkout -b USER-14➡ USER-14 이슈를 기반으로 새로운 기능 개발 브랜치 생성
3. 기능 구현 후 commit or stash 처리
작업을 완료하면 commit해야 하며, 그렇지 않으면 다른 브랜치로 이동할 수 없습니다.
git add .
git commit -m "[Feat/USER-14] 로그인 기능 gql 추가"📌 Commit을 하기 싫을 경우 stash 사용 가능
👉 stash는 작업 중이던 변경 사항을 임시 저장하는 Git 기능입니다.
✅ stash 저장
git stash✅ stash 목록 확인
git stash list✅ 마지막 stash 불러오기
git stash pop➡ 이렇게 하면 임시 저장했던 변경 사항을 복원할 수 있습니다.
4. develop 브랜치를 최신 상태로 유지 후 Rebase 진행
git checkout develop
git pull upstream develop # 최신 상태로 업데이트
git rebase develop USER-14➡ develop 브랜치의 최신 커밋을 가져와 USER-14 브랜치 위로 정리
5. 충돌 해결 및 Pull 에러 처리 후 Rebase 진행
(1) develop 브랜치 최신화 과정 중 Pull 에러 발생 시
✅ git pull upstream develop 실행 중 에러가 발생할 경우
git rebase develop USER-14➡ 에러를 해결한 후 Rebase를 다시 수행하여 브랜치 최신화
(2) Rebase 도중 충돌 발생 시
git add .
git rebase --continue⚠️ 충돌 해결 후 rebase --continue를 반복하여 모든 커밋을 최신 브랜치 위로 정리
📌 참고 : Rebase 충돌 해결 후 마무리하는 방법
(1) 터미널에서git rebase --continue명령어를 실행해도 되고,
(2) VS Code의소스 제어 (Source Control)탭에서계속버튼을 눌러서 마무리할 수도 있습니다.
➡ 두 가지 방법 중 편한 방식으로 진행하면 됩니다! 🚀
6. Feature 브랜치 Push
✅ 일반적인 Push
git push origin USER-14✅ Rebase 후 Push가 안 될 경우 (⚠ 강제 Push 필요)
Rebase를 진행하면 local의 feature 브랜치 헤드 위치와 origin, upstream의 feature 브랜치 헤드 위치가 달라져 일반적인 Push가 불가능합니다.
이 경우, 두 가지 방법 중 하나를 선택할 수 있습니다.
(1) 강제 Push
git push -f origin USER-14⚠️ --force 옵션을 사용할 경우, 팀원과 협의 후 진행해야 합니다.
(2) 원격 브랜치 삭제 후 일반 Push
git push origin --delete USER-14 # 원격 브랜치 삭제
git push origin USER-14 # 일반 Push 수행📌 pr 올리기 전이라면 강제 push(force push)를 하거나 local에서 origin에 해당하는 브랜치를 삭제하면 일반적인 push가 가능합니다.
7. GitHub에서 PR 요청 및 Merge
1️⃣ PR 요청 → (develop < feature)
2️⃣ 코드 리뷰 진행 → 팀원 간 리뷰 후 승인
3️⃣ 리더가 Squash and Merge 진행
🚀 Squash and Merge를 사용하면, 여러 개의 커밋을 하나로 합쳐서 히스토리를 깔끔하게 유지할 수 있습니다.
‼️ 충돌 방지를 위해서 새 브랜치 팔 때 항상 develop으로 이동한 후(최신 상태에서) 새로운 feature 브랜치 파기
📌 Git Rebase 적용 시 유의할 점
✅ Rebase는 혼자 작업하는 브랜치에서 사용하면 안전하지만, 공유 브랜치에서 사용할 경우 주의해야 함
✅ 이미 push된 커밋을 rebase하면 히스토리가 변경되므로, 다른 팀원의 작업에 영향을 줄 수 있음
✅ Rebase를 적용할 때는 항상 브랜치를 백업해두고, 충돌 발생 시 차분히 해결할 것
📌 참고 자료
