Git의 응용, branch, merge 그리고 pull requests에 대해서
🚀 Git 핵심 가이드
브랜칭, 머지, 풀 리퀘스트 완벽 정리
Git은 버전 관리의 표준이 되었어요. 개발자들이 변경 사항을 추적하고, 원활하게 협업하며, 코드베이스를 정밀하게 관리할 수 있게 해주죠. 오늘은 Git의 핵심인 브랜칭, 머지, 풀 리퀘스트를 함께 살펴볼게요! 🎯
🌿 1. 브랜칭: 나만의 평행 우주 만들기
안정적인 소프트웨어 버전이 있는데, 새로운 기능을 개발하거나 버그를 수정해야 한다고 상상해보세요. 현재 작동 중인 코드를 망가뜨리지 않으면서요. 바로 이럴 때 브랜칭이 등장합니다!
Git에서 브랜치는 본질적으로 독립적인 개발 라인이에요. 브랜치를 만들면, 그 시점의 프로젝트 스냅샷을 찍고 원본 코드베이스에 영향을 주지 않으면서 변경할 수 있는 새로운 경로를 만드는 거죠.
왜 브랜치를 써야 할까요? 🤔
- 격리: 새 기능 개발이나 버그 수정을 격리해서, 메인 애플리케이션을 망가뜨리지 않아요
- 실험: 안정 버전을 손상시킬 걱정 없이 새 아이디어를 시도하거나 대규모 리팩토링을 할 수 있어요
- 병렬 개발: 여러 팀원이 각자의 브랜치에서 동시에 다른 기능을 작업할 수 있어요
🔀 2. 머지: 작업물 합치기
피처 브랜치에서 작업을 완료했다면, 다음 단계는 그 변경 사항을 다른 브랜치, 보통 main(또는 master) 브랜치로 통합하는 거예요. 이 과정을 머지(Merge)라고 합니다.
📌 Git의 머지 방식
⚡ Fast-forward 머지
피처 브랜치를 만든 이후로 타겟 브랜치(예: main)에 변경이 없다면, Git은 단순히 main 브랜치 포인터를 피처 브랜치의 최신 커밋으로 앞으로 이동시켜요. 새로운 머지 커밋이 생성되지 않아요!
🔄 Three-way 머지 (재귀 머지)
두 브랜치가 모두 분기된 경우(즉, 피처 브랜치 생성 이후 main에도 커밋이 있는 경우), Git은 three-way 머지를 수행해요. 공통 조상 커밋을 찾아서 두 브랜치의 변경 사항을 결합하고, 이 통합을 기록하는 새로운 "머지 커밋"을 생성합니다.
때로는 Git이 자동으로 변경 사항을 합칠 수 없는 경우가 있어요. 머지하려는 두 브랜치에서 같은 코드 라인이 다르게 수정되었을 때 발생하죠.
충돌이 발생하면 Git은 머지 과정을 일시 중지하고 충돌 파일을 표시해요. 수동으로 파일을 편집해서 어떤 변경 사항을 유지할지 결정하고,
git add로 해결된 파일을 추가한 다음 git commit으로 머지를 완료하면 됩니다!
🤝 3. 풀 리퀘스트: 협업 코드 리뷰의 꽃
브랜칭과 머지가 핵심 Git 작업이라면, 풀 리퀘스트(PR) — GitLab에서는 머지 리퀘스트(MR)라고 불러요 — 는 특히 팀 환경에서 협업을 촉진하는 더 상위 개념이에요.
풀 리퀘스트를 쓰는 이유 💪
- 코드 리뷰: 팀원들이 코드를 검토하고, 개선점을 제안하고, 버그를 잡고, 코드 품질을 보장하는 전용 공간
- 토론 & 피드백: 설계 선택, 구현 세부 사항, 잠재적 이슈에 대한 논의를 촉진
- 자동화 체크: 대부분의 CI/CD 파이프라인이 PR과 통합되어 자동으로 테스트, 린터, 빌드 체크를 실행
📋 일반적인 PR 워크플로우
-
1피처 브랜치 생성: 작업을 위한 새 브랜치를 만들어요
git checkout -b feature/my-feature -
2개발 & 커밋: 변경 사항을 만들고 피처 브랜치에 커밋해요
-
3리모트에 푸시: 피처 브랜치를 공유 원격 저장소에 푸시해요
git push origin feature/my-feature -
4풀 리퀘스트 열기: Git 호스팅 플랫폼(GitHub 등)에서 새 PR을 열어 머지 요청을 해요
-
5리뷰 & 토론: 팀원들이 코드를 검토하고 피드백을 줘요
-
6승인 & 머지: 코드가 승인되면 PR이 main 브랜치에 머지돼요
🎉 마무리하며
브랜칭, 머지, 풀 리퀘스트는 현대 Git 기반 개발의 핵심 기둥이에요.
브랜칭은 격리된 병렬 작업을, 머지는 그 노력들을 하나로 모으고,
풀 리퀘스트는 코드 리뷰와 통합을 위한 구조화된 협업 환경을 제공하죠.
이 개념들을 잘 활용하여 더 체계적인 개발을 시작해보세요! 💪
댓글
댓글 쓰기