실무에 들어가면서 브랜치의 중요성을 깨닫고 활용 방식을 몸소 익히게 됐습니다.
해당 포스팅은 이전의 실수를 짚고, 받았던 피드백을 복기하기 위한 글입니다.
❌ 기존의 잘못된 방식
기능 추가(feat)과 버그 수정(fix) 두 가지의 작업을 한다고 가정합니다.
첫 번째 실수
- main 브랜치 기준으로 feat 브랜치를 만들고 기능 추가 진행
- 다음 업무인 fix 브랜치를 feat 브랜치 기준으로 생성해 버그 수정 진행
feat과 fix는 다른 작업인데 브랜치 이름만 다르게 하고 결국 같은 라인이 된 상황입니다.
사실상 브랜치 구분이 없는 것이죠.
두 번째 실수
- feat 브랜치 작업 완료 후 main 브랜치 기준으로 fix 브랜치를 만들어 작업 완료
- feat과 fix 두 브랜치 간의 호환을 확인하기 위해 둘을 병합해버림
브랜치의 분리가 의미없어진 것입니다...
위 문제 상황의 깃 히스토리를 시각적으로 표현하면...
두 가지의 작업이 하나의 라인에 이어지는 것을 볼 수 있습니다.
main
|
o ← 기존 main 커밋
└───────────── feat
|
o ← feat 기능 추가
└───────────── fix
|
o ← fix 버그 수정이렇게 다른 성격의 작업이 하나의 브랜치에 함께 올라갔을 때의 문제점은 생각보다 치명적입니다. 코드 형상 관리가 무의미해져 버립니다..!
❓ 문제점
- 코드 의존성
- feat 브랜치가 fix 브랜치의 변경 사항에 의존됨
- PR 단위로 기능을 관리하기 어려움
- 충돌 가능성
- 먼저 병합된 두 브랜치를 main에 병합할 때 conflict 발생 가능성 증가
- 기능별 확인 및 작업 취소 어려움
- feat 작업만 단독으로 확인하기 어려움
- 추후에 특정 브랜치의 작업이 필요없다고 판단될 때 쉽게 떼어내기 어려움
⭕️ 변경 후의 방식
- 새로운 작업은 항상 main에서 시작한다. (main이 아니어도 변경의 기준이 되는 브랜치 1개를 정하기)
- feat과 fix의 병합을 테스트하거나, feat이 fix의 변경 사항이 필요하다면 별도의 임시 로컬 브랜치를 만들어 확인한다. (푸시하지 않고, 확인 완료 후 삭제)
위 처럼 진행했을 때의 깃 히스토리 구조를 트리 형태로 표현해보면,
task와 bug 커밋이 분리되어 있는 것을 확인할 수 있습니다.
추후에 특정 브랜치의 변경 사항을 제거하기도 수월해지고 두 브랜치가 서로 의존하지 않게 됩니다.
main
|
o ← main 커밋
├───────────── feature/task
| |
| o ← task 커밋 1
|
└───────────── fix/bug
|
o ← bug 커밋 1로컬에서 두 브랜치의 변경 사항을 합쳐서 확인할 때는 main 기준에 임시 브랜치를 생성하여 두 브랜치를 병합해 확인합니다. 이때 임시 브랜치는 원격에 pull 하지 않아야 합니다.
merge/feat_and_fix (로컬)
|
o ← main
|
├─ feature/task 머지
| o ← task 커밋 1
|
└─ fix/bug 머지
o ← bug 커밋 1
참조문헌
Backend Developer