[Git] Git Branch 활용하기

✅ Branch 란?

Git에서 프로젝트를 진행하는 동안 서로 다른 작업 흐름을 분리하여 동시에 개발·실험·버그 수정 등을 가능하게 해주는 ‘갈래’ 혹은 ‘분기’ 지점을 의미합. 더 쉽게 말해, 작업을 여러 갈래로 나누어 독립적으로 진행할 수 있도록 하는 기능.

 

✅ Branch를 사용하는 이유

1. 독립적인 작업 환경
   • 각 기능(feature)이나 버그 수정(bugfix)마다 브랜치를 만들어 작업하면, 다른 작업에 영향을 주지 않고 안전하게 개발을 진행할 수 있다.
2. 실험적인 시도
   • 새로운 아이디어를 테스트하거나 위험도가 높은 변경을 할 때, 별도 브랜치에서 시도 후 문제가 없다면 합치고(merge), 문제가 생기면 해당 브랜치만 버릴 수 있다.
3. 협업 효율 극대화
   • 여러 명이 동시에 작업하더라도, 각자 독립된 브랜치에서 작업을 진행할 수 있어 충돌을 최소화하고 병합 시점(merge 시점)을 조절할 수 있다.
4. 작업 이력 관리
   • Git은 커밋(Commit) 단위로 작업 이력을 추적. 브랜치를 통해 변경 사항을 주제별로 정리하기 쉽고, 후에 특정 작업의 이력을 빠르게 추적할 수 있.

 

✅ Branch 활용하기

Branch를 만든다는 것은 복사본을 만든다는 것과 같다.

 

먼저 git init을 한 후 master branch를 main으로 변경하자

git init
git branch -M main

 

 

 

 

브랜치 생성 명령어

git branch 브랜치명

 

"브랜치명" 으로 현재 기준 새로운 branch를 생성한다.

 

 

일단 먼저 main 에서 commit 을 한다.

 

 

그 다음 새로운 branch를 작성해보겠다.

 

 

Branch 생성 확인 (목록 조회)

git branch

 

git branch 는 branch의 목록을 조회할 수 있으며 현재 어떤 branch인지 확인할 수 있다.

 

 

성공적으로 dev branch가 생성된 것을 볼 수 있고, * main이 현재 branch임을 알 수 있다.

 

 

Branch 이동 명령어

git switch 브랜치명
git checkout 브랜치명

 

같은기능이나 switch가 더 최신에 나온 기능이다.

 

사실 브랜치를 옮기는데는 git checkout 이라는 기존의 명령어가 있었다.

그러나 이 명령어는 너무 많은 기능을 가지고 있어 문제가 됐다. 

 

한 명령어가 너무 많은 기능을 가지게 되면 소위 객체지향에서 말하는 GOD Object 와 같은 설계가 탄생할 수 있기 때문에 git 시스템은 버전 업그레이드를 거치며 git switch 라는 명령어를 새로 만들게 되었다.

 

- switch: 브랜치를 이동한다.

- checkout: 브랜치를 이동하거나 워킹 트리의 파일을 복원한다.

 

 

git switch dev 명령어를 통해 dev branch로 변경된 것을 볼 수 있다.

 

브랜치 한 번에 생성 & 이동

git switch -c 브랜치명
git checkout -b 브랜치명

 

이 명령어들로 branch를 새로 생성함과 동시에 해당 branch로 이동할 수 있다.

 

 

 

dev branch에서 새로 작성하고 커밋을 해보았다. 그 후 main branch로 이동하니 dev에서 작성한 내용은 찾을 수 없다.

 

 

branch는 각각의 독립적인 공간이다. 그래서 branch를 생성하는 것이다.

 

이렇게 각자의 독립 공간에서 작업을 한 후 main branch에 합친다.

 

그 과정을 merge라고 한다.

 

main에 합치는 이유?

- 최종브랜치가 필요 (서로 협력한 기능을 하나의 브랜치로 합치기) 협업

 

 

브랜치 merge 방법

git switch 최종브랜치명 (먼저 이동)
git merge 합칠브랜치

 

git switch 명령어로 최종브랜치로 이동한다음 git merge로 병합한다.

 

 

dev에서 작성한 내용이 main에서 확인할 수 있다.

 

 

✅ Pull Request 활용하기

사실 git merge는 잘 안쓴다. 터미널말고 github에서 합칠 수 있다.

 

Github에서 합치는 이유?

 

• 코드 리뷰(Code Review)와 협업
  Pull Request는 다른 팀원들이 내가 만든 변경사항을 쉽게 확인하고, 리뷰를 남기고, 필요한 수정 사항이나 의견을 교환할 수 있는 통합된 인터페이스를 제공한다.
  • 변경된 코드 라인 수, 변경 내용 등을 한눈에 확인 가능
  • 리뷰어가 댓글이나 제안을 달아 직접 수정 요청 가능
  • 커밋 히스토리를 추적하여 누가 어떤 의도로 수정했는지 손쉽게 파악
• 변경 이력(History) 및 문서화
  Pull Request는 단순히 코드를 합치는 것 이상으로, ‘왜 이 수정이 필요한가’, ‘어떤 이슈를 해결하는가’ 등의 내용을 대화 형식으로 기록으로 남길 수 있다. 이러한 이력은 프로젝트가 커질수록 굉장히 중요하다.
  • 단순 merge 커밋 로그보다 더 풍부한 정보(이슈 번호, 커멘트, 승인 등)
  • 팀 외부나 새롭게 합류한 팀원이 빠르게 맥락을 이해할 수 있게 도움
• 자동화된 검사(CI/CD)와 품질 관리
  GitHub Actions, Jenkins, Travis CI 등의 도구와 연동하여 Pull Request가 생성될 때마다 자동으로 빌드, 테스트, 린트 등을 수행해 품질을 관리할 수 있다.
  • 테스트가 통과하지 않으면 머지(merge)가 거부되게 설정 가능
  • 린트 오류나 보안 취약점을 자동으로 탐지
  • 팀원들이 코드 변경 시 문제 발생 여부를 빠르게 파악
• 권한 및 승인 워크플로우
  바로 merge하지 않고 Pull Request를 통해 지정된 리뷰어(혹은 팀)에게 코드 검토를 요청하고, 승인을 받은 뒤 merge를 진행할 수 있다.
  • 여러 단계의 승인을 받아야 하는 조직 구조에 적합
  • 관리자가 아닌 사람도 브랜치를 생성하고 PR을 열어 기여 가능(오픈소스 프로젝트 등)
• 브랜치 보호 및 충돌 최소화
  GitHub에서는 특정 브랜치를 보호하는 정책(예: main 브랜치)에 의해 직접 push나 merge가 제한되도록 설정할 수 있다. 이렇게 하면, Pull Request 리뷰 및 자동화된 검사 과정을 건너뛰고는 병합할 수 없게 되어 안정성과 품질을 확보할 수 있다.
  • 무분별한 브랜치 merge로 인한 오류 또는 품질 저하 방지
  • 필요한 단계를 건너뛰지 않도록 제도적으로 강제

 

 

이러한 이유로, Pull Request 방식은 협업 과정에서 코드 품질과 협력 효율을 높여주고, 모든 변경 사항을 투명하고 체계적으로 관리할 수 있게 해줍니다. 

 

✅ Pull Request 란?

Pull Request(PR)은 Git 기반 협업 툴(주로 GitHub, GitLab 등)에서 한 브랜치에서 다른 브랜치로 변경 내용을 합치기 위해 요청(Request)하는 기능을 말합니다.

 

* Pull: 당겨서 합치는 것 (fetch & merge)

* Request: 요청하다

 

✅ Pull Request 활용하기

 

github에서 한번 해보겠다.

 

우선 git reset 기능으로 merge으로 돌려주었다.

 

github에서 repository를 생성하여 연동해주었다.

 

그 후 dev branch로 변경하고 똑같이 push 해주었다.

 

 

github에서 확인해보니 dev branch에서 push를 하였으니, pull request 기능을 사용할 수 있다고 나온다.

Compare & pull request를 눌러보자.

 

 

 

해당화면에서 pull request 를 생성할 수 있다. 위쪽은 title이도 아래는 description을 작성할 수 있다.

 

그리고 위를 잘봐야한다.

 

 base: main ← compare: dev

 

dev branch를 main에다가 merge 시키겠다는 뜻이다. 어느 branch인지 확인을 잘 해야한다.

 

이렇게 PR이 열린 것을 확인할 수 있다.

 

 

 

 

 

PR 메뉴에서 Files changed 메뉴로 이동하면 어떤 변경이 있는지 확인할 수 있다.

 

원하는 라인에서 + 버튼을 눌러 해당 코드의 코멘트 등록이 가능하다.

 

 

우측 Finish your review 버튼을 클릭 하면 최종적으로 review 를 할 수 있다.

 

여기서 해당 코드에 대한 리뷰도 작성할 수있고, 코멘트, 허가, pr을 못하게 할 수도 있다.

 

• Comment (댓글 달기 / 코멘트만 남기기)
  • 의미: 변경 사항에 대해 일반적인 의견이나 질문, 피드백을 남기고 싶을 때 사용.
  • 영향:
    • 공식적으로 승인(Approve)도, 수정 요청(Request changes)도 하지 않는 “중립” 상태.
    • 코드 리뷰 과정에서 “단순 의견 교환”으로 사용.
• Approve (승인)
  • 의미: PR에 포함된 변경 사항을 검토했고, 별다른 문제나 수정 필요 없이 **‘이 상태로 머지(merge)해도 좋다’**고 동의할 때 사용.
  • 영향:
    • 팀 혹은 저장소 정책에 따라, 승인(Approvals)이 특정 인원 수 이상 모이면 자동으로 머지가 허용될 수 있음.
    • 다른 사람들도 코드가 충분히 검증되었음을 확인
• Request changes (수정 요청)
  • 의미: 코드에서 문제(버그, 로직 오류, 개선 필요 등)를 발견했거나, 현재 상태 그대로는 머지하기 어렵다고 판단될 때 수정이 필요함을 명시.
  • 영향:
    • PR 작성자가 지적된 부분을 수정하지 않으면, 리뷰어가 다시 승인하기 전까지 머지가 진행되지 못하도록 막을 수 있음(저장소 설정에 따라 상이).
    • 수정 요청이 해소되면, 재검토(리뷰) 과정을 거쳐 Approve로 전환 가능.

 

 

 

 

모든 code review 가 끝이나고 approve 가 된다면

 

해당 버튼을 눌러 merge 할 수 있다.

 

merge 에 관한 commit message를 작성하고 confirm merge를 화면 최종적으로 merge가 완료된다.

 

 

 

merge가 완료되면 pull request가 성공적으로 끝났고, 닫혔다는 안내가 나온다.

Delete branch를 통해 해당 branch는 삭제가 가능하다.

 

 

main에서 성공적으로 merger가 된 것을 확인 할 수 있다.

 

 

저장소에서도 확인하려면 git pull 명령어를 통해 원격 저장소의 내용을 로컬로 pull 해야한다.

git pull origin main

 

 

로컬에서도 성공적으로 merge가 되었음을 확인할 수 있다.

 

✅ Branch 사용 시 문제점

1. 브랜치 난립(Branch Proliferation) 및 관리 비용 증가

• 문제 상황
  • 너무 자주 혹은 중복된 목적의 브랜치를 생성하여 팀원이 “이 브랜치는 무슨 용도인가?”를 헷갈려 하는 상황.
  • 오랜 기간 방치된 브랜치가 많아지면 유지·정리 작업이 필요해짐.
• 대처 방법
  • 브랜치 네이밍 규칙(feature/…, bugfix/…, hotfix/…) 등을 정해 일관되게 사용.
  • 필요 없는 브랜치는 머지 후 즉시 삭제하여 정리.

2. 머지 충돌(Merge Conflict) 증가

• 문제 상황
  • 여러 사람이 각자 다른 브랜치에서 동시에 작업하다 보면, 동일 파일·코드 영역을 수정해서 충돌이 잦아질 수 있음.
  • 충돌이 많으면 머지 과정에서 시간이 많이 소모되고, 실수로 인한 버그가 발생할 위험이 커짐.
• 대처 방법
  • 자주 리베이스(Rebase)하거나, 메인 브랜치(main/master)를 자주 병합(Merge)해 최신 상태를 유지.
  • CI(빌드·테스트 자동화) 환경으로 충돌 가능성을 빠르게 확인.

3. 장기간 분리(Long-Lived Branch)의 위험

• 문제 상황
  • ‘한 번에 큰 기능을 완성하겠다’는 이유로, 브랜치를 매우 오랫동안 메인 브랜치와 병합하지 않으면 변경 사항이 크게 쌓여버림.
  • 병합 시점에서 큰 규모의 충돌이나 예기치 않은 오류가 발생하기 쉽고, 리뷰하기도 어려워짐.
• 대처 방법
  • 큰 기능이라도 작은 단위로 나누어 자주 병합(PR)하고, “작은 커밋+빠른 병합” 전략을 사용.
  • 기능을 완벽히 끝내기 전이라도 동작 가능한 단계에서 자주 병합하여 리스크 분산.

4. 테스트·리뷰의 지연

• 문제 상황
  • 브랜치마다 별도로 작업이 이루어지다 보니, 메인 브랜치에 반영되기 전까지는 해당 기능을 다른 팀원들이 테스트하거나 리뷰하기 어려울 수 있음.
  • 결과적으로 코드 품질 확인이 늦어져, 통합 단계에서 대규모 수정이 필요한 경우가 생김.
• 대처 방법
  • Pull Request(Pull Request) 중심의 워크플로우로, 작업 중간에도 팀원들이 코드를 리뷰할 수 있게 함.
  • CI/CD 파이프라인을 통해 브랜치 단위로 빌드·테스트를 자동으로 돌려서 문제 발생 시점 조기 파악.

5. 분산된 커밋 히스토리로 인해 추적 어려움

• 문제 상황
  • 여러 브랜치가 서로 다른 시점에서 파생되고 재병합되다 보면, 전체 프로젝트의 흐름(어떤 기능이 언제, 누구에 의해 추가되었는지)을 한눈에 파악하기 어려울 수 있음.
• 대처 방법
  • 일관된 커밋 메시지 규칙(예: Conventional Commit)과 브랜치 전략(Git-flow, GitHub-flow 등)을 도입해 히스토리 가독성을 높임.
  • 주요 변경(머지 커밋 등)에 이슈/PR 번호를 연결해 놓아, 변경 배경을 쉽게 추적할 수 있게 관리.

결론

• 브랜치 사용 자체는 협업 효율성을 높이는 필수 요소지만, 잘못된 관리·운영 방식으로 인해 충돌, 난립, 긴 통합 주기 등의 문제가 발생할 수 있음.
• 이를 최소화하려면, 명확한 브랜치 전략, 주기적인 병합(또는 rebase) 작업, 자동화된 테스트 및 리뷰 문화를 갖추는 것이 중요.

 

✅ 팀 프로젝트 시 협업 가이드

 

1.팀장: 초기코드 작성 및 github 업로드

1. 폴더생성
2. 초기 코드 작성
3. git init, add, commit
4. github repository push

2. 팀장: dev 브런치 생성

1. git switch -c dev (로컬에서 dev 생성)
2. git push origin dev (원격지 반영)

 

3. 팀장: github setting가서 default 브랜치를 dev로 변경

 

4. 팀장: 팀원들 Collaborators 등록 (Settings)

 

5: 팀원: git clone하기