[Git] 팀 프로젝트에서 Git 협업 흐름 정리 (develop, feature, merge 이해하기)

Git 협업 흐름 정리

왜 Git 협업 방식을 알아야 할까?

개인 프로젝트에서는 main 브랜치 하나만 사용해도 크게 문제가 없었다.

하지만 팀 프로젝트에서는 여러 명이 동시에 개발하기 때문에 각자의 작업을 안전하게 관리하고 합치는 과정이 필요하다.

우리 팀은 다음과 같은 브랜치 전략을 사용했다.

main
   │
develop
   │
feature/customer
feature/product
feature/order
...

 

• main : 최종 배포 브랜치
• develop : 개발이 완료된 코드가 모이는 브랜치
• feature/ : 각자 기능을 개발하는 브랜치

---

개발 시작하기

프로젝트를 clone 받으면 처음에는 develop 브랜치에 있다.

먼저 자신의 기능 브랜치를 만든다.

git checkout -b feature/customer

 

 

브랜치를 확인하면

git branch

 

develop
* feature/customer

 

현재 feature/customer 브랜치에서 작업 중이라는 뜻이다.

 

---

기능 개발

예를 들어 Customer 기능을 개발한다고 하면

Customer Entity 작성

↓

Repository 작성

↓

Service 작성

↓

Controller 작성

 

이런 식으로 기능을 구현한다.

작업이 어느 정도 완료되면 커밋한다.

git add .
git commit -m "feat: 고객 단건 조회 구현"

 

 

---

왜 커밋을 먼저 해야 할까?

"develop 최신 내용을 가져오기 전에 왜 꼭 commit을 해야 하지?"

이유는 현재 작업을 안전하게 저장하기 위해서이다.

 

커밋하지 않은 상태는 Git 입장에서 아직 저장되지 않은 작업이다.

이 상태에서 merge를 하면 Git은

• 현재 작업을 유지해야 하는지
• develop의 내용을 먼저 적용해야 하는지

판단하기 어려워진다.

 

그래서 먼저 커밋을 하여 작업을 하나의 스냅샷으로 저장한다.

작업

↓

commit

↓

안전하게 저장 완료

 

이제 Git은 안심하고 develop의 최신 내용을 합칠 수 있다.

 

---

develop 최신 내용 가져오기

팀원들이 develop에 새로운 기능을 merge했다면 내 브랜치도 최신 상태로 맞춰줘야 한다.

순서는 다음과 같다.

1. develop 이동

git checkout develop

 

2. 최신 코드 가져오기

git pull origin develop

 

그러면 원격 저장소의 develop 브랜치와 동일한 상태가 된다.

3. 다시 내 브랜치로 이동

git checkout feature/customer

 

 

4. develop 병합

git merge develop

 

그러면

feature/customer

↓

내 작업

+

develop 최신 코드

 

가 합쳐진다.

 

---

왜 이 과정을 반복할까?

여러 명이 개발하면 develop 브랜치는 계속 변경된다.

예를 들어

A팀원
상품 기능 Merge

B팀원
주문 기능 Merge

C팀원
관리자 기능 Merge

 

이렇게 develop은 계속 업데이트된다.

내 브랜치도 최신 상태로 유지해야 나중에 PR을 보낼 때 충돌(Conflict)이 줄어든다.

---

Conflict는 언제 발생할까?

이번에는 Conflict가 발생하지 않았다.

그 이유는 서로 다른 파일을 수정했기 때문이다.

예를 들어

나
Customer.java 수정

팀원
Order.java 수정

 

이 경우에는 Git이 자동으로 합칠 수 있다.

하지만

나
Customer.java 수정

팀원
Customer.java 같은 부분 수정

 

이라면

Git은 "어느 코드를 사용해야 하지?" 를 판단할 수 없기 때문에 Conflict가 발생한다.

이 경우 개발자가 직접 코드를 선택해서 해결해야 한다.