Git branch 관리

Posted Jan 20, 2024 Updated Jan 24, 2024

git-branches

By zwoong

10 min read

branch

Git의 브랜치는 개발자가 메인 개발 라인에서 벗어나 해당 메인 라인에 영향을 주지 않고 독립적으로 작업할 수 있도록 해준다.

동시 개발: 여러 개발자가 서로의 작업을 방해하지 않고 동시에 다양한 기능을 작업할 수 있다.
실험: 새로운 아이디어를 시험해 볼 수 있는 안전한 공간을 제공한다. 실험이 실패하면 기본 코드베이스에 영향을 주지 않고 폐기하면 되고, 성공하면 다시 메인 브랜치로 병합할 수 있다.
특정 작업에 집중: 분기를 통해 개발자는 다른 변경 사항과 별도로 특정 작업(예: 새로운 기능, 버그 수정)에 집중할 수 있다.
코드 검토 및 공동 작업: 기본 분기에 병합하기 전에 풀 요청(또는 병합 요청)이라는 프로세스에서 코드를 검토할 수 있다. 이는 협업을 장려하고, 코드 품질을 향상시키며, 코드가 통합되기 전에 프로젝트 표준에 맞는지 확인할 수 있다.

기능 개발
- 시나리오: 한 개발자는 사용자 인증 작업을 담당하고 다른 개발자는 결제 통합 작업을 담당한다.
- 브랜치 사용법: 각 개발자는 별도의 브랜치를 생성한다(예: feature/user-authentication 및 feature/payment-integration). 각자의 기능을 독립적으로 작업한 이후, 기능이 완성되면 팀에서 검토한 다음 기본 분기에 병합한다.
버그 수정
- 시나리오: 애플리케이션의 프로덕션 버전에서 심각한 버그가 발생했다.
- 브랜치 사용법: 버그를 해결하기 위해 메인 브랜치에서 hotfix/ 브랜치를 생성한다. 버그를 수정하고 코드를 검토한 이후 수정 사항을 프로덕션에 배포한다.

git branch
- 목적: 브랜치를 생성, 나열, 이름 바꾸기 및 삭제하는 데 사용된다.
- 용법
  - git branch: 저장소의 모든 분기를 나열하며 현재 분기를 별표로 표시한다.
    - 옵션
      - -a: 원격 추적 분기와 로컬 분기를 모두 나열한다.
      - -r: 원격 추적 분기를 나열한다.
      - --merged: 현재 있는 브랜치에 이미 병합된 브랜치를 나열한다.
      - --no-merged: 병합되지 않은 브랜치를 나열한다.
  - git branch [branch-name]: 지정된 이름을 가진 새 분기가 생성된다.
  - git branch -d [branch-name]: 지정된 브랜치를 삭제한다.
  - git branch -m [old-branch-name] [new-branch-name]: 브랜치 이름이 old-branch-name에서 new-branch-name으로 변경된다.
git checkout
- 목적: 작업 트리에서 브랜치 간을 전환하거나 파일을 복원하는 데 사용된다.
- 용법
  - git checkout [branch-name]: HEAD가 지정된 분기로 변경되고 작업 디렉터리가 해당 브랜치로 변경된다.
  - git checkout -b [new-branch-name]: 새 분기가 생성되고 즉시 해당 분기로 전환된다.
  - git checkout – [file-name]: 지정된 파일의 변경 사항을 삭제하고 마지막 커밋 상태로 되돌린다.

이제 branch 관리에 핵심인 merge와 rebase에 대해 자세히 알아보자. 😉

git merge는 두 브랜치의 기록을 결합한다. feature-branch라는 브랜치를 다른 브랜치인 main으로 병합하면 Git은 두 브랜치의 기록을 함께 연결하는 main 브랜치에 새로운 병합 커밋을 생성한다.

장단점
- 장점
  - 비파괴 작업: 기존 분기와 해당 기록은 그대로 유지된다.
  - 컨텍스트 보존: 분기가 언제, 어떻게 갈라지고 합쳐졌는지 정보가 기록된다.
- 단점
  - 복잡한 기록: 병합이 자주 발생하는 경우 많은 병합 커밋으로 인해 프로젝트 기록이 복잡해질 수 있다.

feature-merge-branch라는 브랜치에서 새로운 기능을 작업하고 main 브랜치의 해당 브랜치를 병합해보자.

  git checkout -b feature-merge-branch

  git checkout main

  git merge feature-merge-branch

현재 작업 중인 분기에 main브랜치를 rebase하게되면 작업 중인 분기에 전체 커밋 내역을 main브랜치 뒤쪽으로 통째로 이동시킨다.

장단점
- 장점
  - 깨끗한 선형 기록: rebase를 사용하면 더 명확하고 선형적인 프로젝트 기록이 생성된다.
  - 불필요한 병합 커밋 제거: 기록이 복잡해질 수 있는 추가 병합 커밋 생성을 방지할 수 있다.
- 단점
  - 복잡한 충돌 해결: rebase 중에 충돌은 커밋별로 해결해야 한다. merge을 사용하면 병합 커밋에 단 하나의 커밋만 해결하면 된다..
  - 컨텍스트 손실: rebase는 선형 기록을 생성하므로 병렬 개발 분기의 컨텍스트가 손실된다. 대조적으로, merge는 분기가 분기되고 나중에 통합된 시점의 컨텍스트를 보존한다.

feature-rebase-branch라는 브랜치에서 새로운 기능을 작업하고 main 브랜치를 기준으로 rebase 해보자.

  git checkout -b feature-rebase-branch

  git rebase main

merge와 rebase에 대해 간단히 살펴보았다. 그렇다면 각각 어떠한 상황에 사용하는 것이 좋을까?

Git Merge를 사용해야 하는 경우
- 협력 지점: main 또는 development 브랜치와 같이 다른 사람들도 작업 중이거나 작업의 기반이 될 브랜치에서 작업할 때 병합을 사용한다. 병합은 분기 기록을 보존함으로 잠재적인 혼란을 방지한다.
- 풀 요청: 풀 요청(PR)을 완료할 때, 특히 변경 내용의 컨텍스트를 유지하는 것이 중요한 공유 저장소 내에서 병합이 표준이다. 기능이나 수정 사항이 기본 분기에 통합된 위치를 명확하게 보여준다.
- 컨텍스트 유지: 여러 기능이 동시에 개발되는 경우와 같이 병렬 개발 트랙에 대한 전체 변경 내역과 컨텍스트를 유지하려면 병합을 사용하는 것이 좋다.
Git Rebase를 사용해야 하는 경우
- 복잡한 기록 단순화: 더 깨끗하고 선형적인 기록을 원할 경우 rebase가 선호된다.
- 로컬 커밋 정리: 로컬 브랜치에서 일련의 임시 또는 실험적 커밋을 만든 경우 git rebase -i를 사용하여 커밋을 스쿼시하고, 변경 사항을 메인 브랜치에 병합하기 전에 불필요한 커밋을 삭제할 수 있다. (merge에도 유사한 –squash 옵션이 존재)

개인적인 생각으로는 Git을 사용하는 제일 큰 이유 중 하나는 형상관리인데, 분기가 언제, 어떻게 갈라지고 합쳐졌는지에 대한 기록을 남기지 않는 rebase를 사용하는 것 보다는 명확한 컨텍스트를 보존할 수 있는 병합을 사용하는 것이 더 바람직하다고 본다. 🧐

This post is licensed under CC BY 4.0 by the author.