Git 심화 마스터: 브랜치 전략부터 충돌 해결까지, 협업을 위한 필수 가이드!

Git의 기본적인 커밋, 푸시, 풀 명령어는 익숙해졌지만, 실제 프로젝트에서는 훨씬 더 복잡한 상황들을 마주하게 됩니다. 특히 여러 개발자가 동시에 작업하는 환경에서는 브랜치(Branch)의 개념과 효율적인 브랜치 전략, 그리고 불가피하게 발생하는 병합 충돌(Merge Conflict)을 해결하는 능력이 Git 심화 활용의 핵심입니다. 이 글에서는 Git의 브랜치를 중심으로 한 심화 내용과 함께 리베이스(Rebase), 스태시(Stash) 등 고급 명령어, 그리고 협업의 필수인 충돌 해결 기법까지 개발자 주니어 및 개발 입문자의 눈높이에 맞춰 쉽고 자세하게 알아보겠습니다!

목차

• Git 브랜치: 왜 사용해야 할까요?
  • 브랜치 생성 및 전환
  • 브랜치 병합 (Merge)
• Git 브랜치 전략: 효율적인 협업을 위한 설계
  • Feature Branch (피처 브랜치) 워크플로우
  • Git Flow 워크플로우
• 병합 충돌 (Merge Conflict) 이해와 해결 방법
  • 충돌 발생 상황
  • 충돌 해결 과정
• Git의 고급 기능 활용하기
  • git rebase: 깔끔한 커밋 이력 만들기
  • git stash: 작업 임시 저장하기
  • git tag: 중요한 지점 표시하기
• Git 심화 활용, 이것만 기억하세요!

---

Git 브랜치: 왜 사용해야 할까요?

Git에서 브랜치는 독립적인 작업 공간을 만드는 기능입니다. 마치 프로젝트의 복사본을 만들어 따로 개발을 진행하다가, 나중에 본래 프로젝트와 합치는 것과 같습니다. 브랜치를 사용하면 여러 개발자가 동시에 다른 기능을 개발하거나, 버그를 수정할 때 서로의 작업에 영향을 주지 않고 효율적으로 협업할 수 있습니다.

브랜치 생성 및 전환

• git branch <브랜치이름>: 새로운 브랜치를 생성합니다. 이 명령만으로는 새 브랜치로 이동하지 않습니다.
• git checkout <브랜치이름>: 특정 브랜치로 작업 공간을 전환합니다.
• git switch <브랜치이름>: git checkout의 브랜치 전환 기능을 대체하는 좀 더 직관적인 명령어입니다.
• git checkout -b <새로운브랜치이름> 또는 git switch -c <새로운브랜치이름>: 브랜치를 생성함과 동시에 해당 브랜치로 전환합니다.

브랜치 병합 (Merge)

개발이 완료된 브랜치의 내용을 메인 브랜치(예: main 또는 master)로 합칠 때 git merge 명령어를 사용합니다.

• 먼저 병합할 대상 브랜치(예: main)로 이동합니다: git checkout main
• 그리고 다른 브랜치(예: feature/new-login)의 내용을 가져와 병합합니다: git merge feature/new-login
• 이때 충돌이 발생하지 않으면 새로운 병합 커밋(Merge Commit)이 생성되며, 이력이 남습니다

Git 브랜치 전략: 효율적인 협업을 위한 설계

Git 브랜치는 개발 팀의 규모와 프로젝트 특성에 따라 다양한 전략으로 활용될 수 있습니다. 대표적인 두 가지 전략을 살펴보겠습니다.

Feature Branch (피처 브랜치) 워크플로우

가장 흔하게 사용되는 간단한 전략입니다.

• main (또는 master) 브랜치는 항상 안정적인 상태를 유지합니다.
• 새로운 기능(Feature)을 개발할 때마다 main에서 새로운 피처 브랜치(feature/<기능명>)를 생성합니다.
• 개발 완료 후에는 main 브랜치로 병합(Merge)합니다. 이때 Fast-forward 병합을 피하기 위해 git merge --no-ff 옵션을 사용하여 항상 병합 커밋을 남기는 것이 일반적입니다.

Git Flow 워크플로우

더 복잡하고 체계적인 브랜치 관리가 필요할 때 사용됩니다. main, develop, feature, release, hotfix 등 여러 종류의 브랜치를 사용하여 개발 주기를 명확히 나눕니다.

• main: 배포 가능한 코드만 유지.
• develop: 다음 버전 개발의 기준 브랜치.
• feature: 개별 기능 개발용 브랜치 (develop에서 분기).
• release: 배포 준비용 브랜치 (버그 수정 및 최종 테스트).
• hotfix: 긴급 버그 수정용 브랜치 (main에서 분기).

병합 충돌 (Merge Conflict) 이해와 해결 방법

여러 개발자가 같은 파일의 같은 부분을 수정했을 때 병합 충돌이 발생합니다. Git이 어떤 변경 사항을 선택해야 할지 자동으로 결정할 수 없을 때 발생합니다.

충돌 발생 상황

• git merge 또는 git pull 시 같은 파일의 같은 라인을 서로 다르게 수정했을 경우.
• 한 파일은 삭제하고 다른 파일은 수정했을 경우 등.

충돌 해결 과정

1. 충돌 감지: Git이 병합 충돌을 감지하면, 해당 파일을 Unmerged 상태로 만듭니다.
2. 충돌 파일 확인: 충돌이 발생한 파일에는 Git이 자동으로 충돌 마커(<<<<<<<, =======, >>>>>>>)를 추가합니다.

3. <<<<<<< HEAD
   이것은 현재 브랜치의 내용입니다.
   =======
   이것은 병합하려는 브랜치의 내용입니다.
   >>>>>>> feature/branch-name
   

4. 수동 해결: 개발자가 직접 파일을 열어 충돌 마커를 제거하고, 원하는 최종 코드를 만듭니다. 두 변경 사항 중 하나를 선택하거나, 두 변경 사항을 조합할 수 있습니다.
5. 충돌 해결 표시: 파일을 수정한 후, git add <충돌해결된파일이름> 명령어로 해결되었음을 Git에 알립니다.
6. 병합 커밋: 마지막으로 git commit 명령어로 병합 커밋을 완료합니다.

Git의 고급 기능 활용하기

Git은 기본적인 브랜치 관리 외에도 개발 워크플로우를 효율적으로 만들어주는 강력한 고급 기능들을 제공합니다.

git rebase: 깔끔한 커밋 이력 만들기

git rebase는 커밋 이력을 재작성(rewrite history)하는 명령어입니다. 특정 브랜치의 커밋들을 다른 브랜치의 최신 커밋 위에 "재배치"하여 병합 커밋 없이 선형적인(Linear)이고 깔끔한 이력을 만들 수 있습니다.

• git checkout feature/branch
• git rebase main (main 브랜치의 최신 커밋 위로 feature 브랜치의 변경 사항을 재배치)
• 주의: 이미 원격 저장소에 푸시되어 공유된 커밋에 대해 rebase를 사용하면 다른 개발자들과의 이력 불일치로 큰 문제가 발생할 수 있으므로, 푸시되지 않은 로컬 커밋에만 사용하는 것이 강력히 권장됩니다.

git stash: 작업 임시 저장하기

현재 작업 중인 변경 사항을 아직 커밋하고 싶지는 않지만, 다른 브랜치로 전환하거나 다른 작업을 해야 할 때 유용합니다. 작업 트리의 변경 사항을 임시로 저장해두고, 나중에 다시 불러올 수 있습니다.

• git stash save "메시지": 현재 변경 사항을 스태시 스택에 저장.
• git stash list: 저장된 스태시 목록 확인.
• git stash pop: 가장 최근 스태시를 불러와 적용하고 스택에서 제거.
• git stash apply: 가장 최근 스태시를 불러와 적용하지만 스택에서는 제거하지 않음.

git tag: 중요한 지점 표시하기

특정 커밋에 "태그"를 달아 중요한 릴리즈 지점(예: v1.0, v2.0) 등을 표시할 수 있습니다. 이는 커밋 해시 대신 사람이 읽기 쉬운 이름으로 특정 시점을 참조할 때 유용합니다.

• git tag -a v1.0 -m "버전 1.0 릴리즈": 주석이 달린 태그 생성.
• git push origin --tags: 태그를 원격 저장소로 푸시.

Git 심화 활용, 이것만 기억하세요!

Git의 브랜치는 협업의 핵심이며, 다양한 브랜치 전략은 프로젝트 관리의 효율성을 높여줍니다. 병합 충돌은 Git을 사용하는 개발자라면 피할 수 없는 부분이므로, 그 해결 방법을 숙지하는 것이 중요합니다. 마지막으로 git rebase로 깔끔한 이력을 만들고, git stash로 유연하게 작업을 전환하며, git tag로 중요한 버전을 표시하는 고급 명령어들을 활용하여 Git을 더욱 능숙하게 다루는 개발자로 성장하시길 바랍니다!