20251215 깃브랜치협업

유레카에서 2번째 미니 프로젝트를 진행했다. 첫 번째 미니 프로젝트와 다르게 팀 프로젝트로 진행이 됐고 깃 브랜치를 제대로 활용해 볼 수 있는 기회가 됐다. 하지만 깃 브랜치를 공부했던 것과 다르게 실제 적용을 하는데 어려움을 겪었다. (브랜치를 언제 어떻게 나누는지, 병합 충돌 등등) 그래서 깃 브랜치 협업에 대해 공부하고 글로 남겨보려고 한다.

깃(Git)이란?

 깃(Git)이란 컴퓨터 파일의 변경 사항을 추적하고 파일들의 작업을 조율하는 분산 버전 관리 시스템이다.

즉, 소프트웨어 개발에서 코드를 관리하고 기록하고 버전 관리를 해주므로 체계적인 개발이 가능하도록 도와주는 무료 공개 소프트웨어이다.

 

깃은 변경 관리, 브랜치, 머지 등 다양한 기능을 제공한다. 이런 기능들은 원본 코드를 변경하지 않고 실험적인 기능을 개발할 수 있는 별도의 작업 공간을 만들 수 있다.

1. 왜 브랜치(Branch)를 사용해야 될까?

출처 : https://www.khan.co.kr/article/201808202123015

깃 브랜치를 사용해야 하는 이유는 안정적인 개발 환경 유지, 효율적인 병렬 개발 및 협업 그리고 유연한 버전 관리를 위해서 이다. 

브랜치(Branch)의 핵심 역할

• 작업 단위 분리
• 안정적인 코드 관리
• 협업 시 책임 범위 명확화

2. 기본 브랜치 구조 이해하기

가장 많이 사용되는 협업 브랜치 구조는 다음과 같다.

main (또는 master)  → 배포용 브랜치
develop             → 개발 통합 브랜치
feature/*           → 기능 단위 작업 브랜치

각 브랜치의 역할

main

• 실제 서비스에 배포되는 코드
• 항상 안정적인 상태 유지

develop

• 여러 기능을 모아 테스트하는 브랜치
• 다음 배포를 준비하는 공간

feature/*

• 하나의 기능을 개발하는 브랜치
• 예시
  • feature/mypage
  • feature/login
  • feature/profile-edit

하나의 기능은 하나의 feature 브랜치 원칙을 지키면 협업 난이도가 크게 내려간다고 한다.

3. fork 기반 협업 구조란?

출처 : https://velog.io/@hyowon_lee/Git-GitHub%EB%A1%9C-%ED%98%91%EC%97%85%ED%95%98%EA%B8%B0-Forking-Workflow

팀 프로젝트나 오픈소스에서는 fork 기반 협업을 많이 사용한다.

구조

upstream (원본 레포지토리)
   ↑
origin (내가 fork한 레포지토리)

용어 정리

upstream

• 팀의 원본 레포지토리

origin

• 내가 fork 해서 만든 개인 레포지토리

보통 원본 레포에는 직접 push 권한이 없기 때문에 내 레포(origin)에서 작업한 뒤 PR(Pull Request)로 upstream에 반영한다.

4. 협업 시작 전 세팅

출처 : https://velog.io/@koominji/Git-%ED%98%91%EC%97%85%ED%95%98%EA%B8%B0-fork-clone-pull-request-fetch-upstream

레포 클론

git clone <내 레포 주소>

원격 저장소 확인

git remote -v

upstream 등록

git remote add upstream <원본 레포 주소>

등록 후 다시 확인

git remote -v

정상이라면 origin, upstream 두 개가 보인다.

5. 기능 개발 전체 흐름

1) 최신 develop 브랜치 가져오기

작업을 시작하기 전에 항상 최신 develop 상태를 맞춘다.

git fetch upstream
git checkout develop
git merge upstream/develop

이 단계가 굉장히 중요하다고 한다. 이걸 하지 않으면 나중에 PR에서 큰 충돌이 발생할 수 있다.

2) feature 브랜치 생성

git checkout -b feature/mypage

• develop 브랜치 기준으로 생성
• 브랜치 이름은 기능을 명확하게 표현

3) 기능 개발 및 커밋

기능을 개발하면서 의미 있는 단위로 커밋한다.

git commit -m "feat: 마이페이지 프로필 UI 구현"
git commit -m "feat: 프로필 저장 API 연동"

커밋 메세지는 무엇을 했는지 한눈에 보이게 작성하는 것이 중요하다. 그래서 실제 팀 프로젝에는 커밋 컨벤션을 정해두고 작업을 했다.

6. 작업 도중 최신 develop 반영하기

다른 팀원이 develop에 코드를 병합했을 수 있다.

이 경우 feature 브랜치에서도 최신 develop을 반영해야 한다.

git fetch upstream
git merge upstream/develop

충돌이 발생한다면?

출처 : https://www.freecodecamp.org/korean/news/how-to-resolve-merge-conflicts-in-git/

• confilct 표시된 파일을 직접 수정
• 수정 완료 후 다시 커밋

git add .
git commit -m "fix: develop 병합 충돌 해결"

7. Pull Request(PR) 생성

기능 개발이 완료되면 PR을 생성한다.

PR 기준 설정

• base repository: upstream
• base branch: develop
• compare branch: origin/feature/*

PR은 단순한 병합 요청이 아니라

코드 리뷰를 위한 소통 도구라는 점이 중요하다.

 

마무리하며

Git 협업에서 중요한 것은 복잡한 명령어가 아니라 일관된 작업 흐름이라고 한다. 브랜치 협업 컨벤션을 팀들과 협의하여 만들고 잘 지킨다면 프로젝트를 잘 진행할 수 있게 될 것이다. 아직은 경험이 부족해 미숙하지만 계속해 보다 보면 실력이 늘 거라고 생각한다.