Git 브랜치(Branch)

브랜치(Branch)

• 브랜치는 하나의 저장소 내의 독립적인 작업 공간이다.
• 브랜치를 생성하면 기존 코드의 복사본이 만들어지고, 그 후에는 독립적으로 작업할 수 있다.
• 다른 브랜치에서 작업한 내용이 현재 작업 중인 브랜치에 영향을 주지 않아서, 여러 기능을 동시에 개발할 때 유용하게 쓰인다. 
• master/main: Git이 제공하는 기본적인 브랜치의 이름.
• 작업이 끝나면 그 브랜치를 main(혹은 다른 브랜치)에 병합(Merge)해서 최종적으로 통합하는 방식이다. 
• 브랜치 예시 
  • main 브랜치: 프로젝트에서 안정적인 코드를 유지하는 브랜치. 배포나 릴리즈할 때 주로 사용.
  • feature 브랜치: 새로운 기능을 개발하는 브랜치. 예를 들어, 로그인 기능을 만들 때 feature/login이라는 브랜치를 생성해서 작업할 수 있다. 
  • bugfix 브랜치: 버그를 수정하는 브랜치. bugfix/fix-login-error와 같은 이름으로 생성해서 작업 가능.

 

브랜치의 특징

• 독립적: 각각의 브랜치는 서로 다른 작업을 할 수 있도록 독립적인 공간을 제공한다. 예를 들어, feature/login 브랜치에서 로그인 기능을 작업하면서, 다른 브랜치에서는 디자인 변경을 할 수 있다. 
• 병합(Merge): 작업이 끝나면, 다른 브랜치에 작업 내용을 병합하여 코드가 통합되도록 한다. 예를 들어, feature/login에서 작업한 내용을 main 브랜치에 병합할 수 있다. 두 버전의 합집합을 구하는 것으로 아래와 같은 세 가지 상황이 일어날 수 있다.
  • 빨리 감기 (Fast-forward) : 하나의 커밋에만 변화가 있어 새로운 상태를 만들어줄 필요 없이 기존 커밋과 동일하게 변화가 있는 커밋으로 상태를 바꾸어주는 상황
  • 병합 커밋 (Merge Commit) : 두 커밋에 모두 변화가 있어 병합하면서 새로운 커밋이 만들어지는 상황
  • 충돌 (Conflict) : 같은 파일에 대해 두 커밋 모두 변화가 있어 어느 쪽으로 합쳐야 할지 충돌이 일어나는 상황. 충돌이 난 부분을 확인하고 무엇을 남길지 수동으로 선택해서 해결해야함.

 

브랜치를 사용하는 이유

1. 협업: 여러 사람이 동시에 작업할 때 서로의 작업이 충돌하지 않도록 분리된 공간을 제공.
2. 안전성: 새로운 기능을 추가할 때 기존 코드가 망가지지 않도록 독립적인 작업 공간을 제공.
3. 실험: 실험적인 코드 변경을 할 때, 메인 코드와 분리된 공간에서 테스트할 수 있다.

 

브랜치를 만드는 규칙

• [master] 브랜치에는 직접 커밋을 올리지 않는다. (동시 작업을 하다가 꼬일 수 있으므로)
• 기능 개발을 하기 전에 [master] 브랜치를 기준으로 새로운 브랜치를 만든다.
• 브랜치 이름은 [feature/기능이름] 형식으로 하고 한 명만 커밋을 올린다.
• [feature/기능이름] 브랜치에서 기능 개발이 끝나면 [master] 브랜치에 이를 합친다.

 

Git Branch 전략 예시 - github flow

• 깃허브를 기반으로 한 간단하고 유연한 개발 워크플로우
• 주요 목표: 신속한 배포와 효율적인 협업을 지원하는 것
• Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미이다.

---

 

 

헷갈릴 수 있는 포인트

1. 브랜치 vs Fork

	브랜치 만들기 (협업)	Fork 하기 (기여)
대상	저장소 내에서 독립적인 작업 공간을 생성	다른 사람의 저장소를 복제하여 독립적인 작업 공간 생성
목적	저장소 내에서 기능 개발, 버그 수정 등 다양한 작업 독립적으로 처리	다른 사람의 프로젝트에 기여하거나 개인화된 복제본을 만들 때 사용
작업 범위	같은 저장소 내에서만 작업	원본 저장소와 독립적인 복제본에서 작업
기여 방식	같은 저장소 내에서 PR을 통해 병합	PR을 원본 저장소에 보내 기여 (기여자의 복제본에서 작업)
동기화	같은 저장소에서 브랜치 간 동기화 가능	fork한 후 원본 저장소와 동기화는 별도의 작업이 필요

 

핵심 차이점

• 브랜치는 하나의 저장소 내에서 작업을 분리하고 독립적으로 할 수 있는 방법. 
• Fork는 다른 사람의 저장소를 복제하여 내 GitHub 계정에 독립적인 복사본을 만드는 방법으로, 주로 기여나 개인적인 실험에 사용된다.

 

2. fetch -> merge vs 브랜치끼리 merge

	fetch -> merge	브랜치끼리 merge
대상	원격 저장소에서 로컬 저장소로 변경 사항 가져오기	로컬 브랜치끼리 변경 사항 병합 (원격 저장소에는 영향X)
주요 목적	원격 저장소의 최신 상태를 로컬로 가져와 동기화 후 병합	여러 브랜치에서 작업한 내용을 하나로 합침
실행 명령	git fetch → git merge	git merge <브랜치명>
병합되는 것	원격 저장소의 변경 사항 (예: 다른 사람이 한 작업)	두 개 이상의 로컬 브랜치 (예: feature -> main)
충돌 여부	원격 저장소에서 가져온 내용과 로컬 내용이 겹칠 경우 충돌 가능	로컬 브랜치끼리 변경 사항이 겹치면 충돌 가능

• fetch -> merge: 원격 저장소와 로컬을 동기화 후 병합하는 과정
• 브랜치끼리 merge: 로컬 브랜치끼리 변경 사항을 병합하는 과정

 

3. main이 아닌 브랜치끼리 merge하는 경우?

• 일반적으로는 main 브랜치에 병합하는 과정이 자주 일어나지만, 다른 브랜치들끼리 병합하는 경우도 종종 있다.
  • 보통 각 기능은 독립적으로 작업되기 때문에, 두 개 이상의 브랜치에서 작업한 내용을 main 브랜치로 병합하는 것이 일반적.
  • PR을 통한 리뷰가 이루어지는 동안 브랜치들끼리 병합하는 상황은 상대적으로 드물다. 
• 그럼에도 브랜치끼리 병합하는 경우
  • 기능 간의 의존성이 있을 때: 두 브랜치에서 서로 다른 기능을 개발했지만, 그 기능들이 서로 의존하는 경우, 먼저 하나의 브랜치에서 다른 브랜치를 병합해서 전체 작업을 테스트할 수 있다.
  • 충돌 해결: 두 개의 브랜치에서 같은 파일을 수정한 경우, 충돌(conflict)을 해결하려면, 두 브랜치를 병합하여 충돌을 해결하고, 나중에 병합된 상태로 main 브랜치에 올리기도 한다. 
• 예시: Feature 브랜치끼리 병합, BugFix 브랜치끼리 병함