Git) 팀 프로젝트 협업 루틴 만들기 (develop 브랜치 기반 체크리스트)

[ Git 루틴 만들기 ]

팀 프로젝트에서 Git이 꼬이는

대부분의 이유는 ‘규칙이 없어서’가 아니라

‘규칙이 있어도 매번 다르게 해서’다.

그래서 오늘은 팀 프로젝트를 수행할 때

도움될 수 있는 Git 루틴을

체크리스트 형태로 정리한다.

 

핵심 사항은 3가지다.

1. develop는 항상 팀이 함께 작업하는
   '최신 통합본’으로 유지
2. 각자 작업은 feature에서만 진행
3. 충돌은 PR 순간이 아니라,
   PR 전에 feature에서 미리 해결

---

기본 원칙

• develop: 통합 브랜치(기본 브랜치)
• main: 최종 배포 브랜치
• feature/이름-기능: 개인 작업 브랜치
• develop에는 직접 push 금지, 무조건 PR로만 머지

브랜치 흐름은 이렇게 생각하면 된다.

• feature에서 작업
  → develop로 PR 머지
  → 배포 시점에 develop
  → main

---

매일 작업 시작 루틴

작업 시작 전에 가장 먼저 할 일은

develop를 최신화하는 것이다.

여기서 중요한 포인트는 pull은

‘현재 내가 서 있는 브랜치’를 업데이트한다는 점이다.

 

1) develop 최신화

git checkout develop
git pull origin develop

 

2) 내 feature로 이동

git checkout feature/seunghwan

 

3) 최신 develop를 내 feature에 반영

git merge develop

이렇게 하면 내 feature는

‘오늘 기준 최신 develop’을 포함한

상태에서 작업을 시작하게 된다.

---

작업 중 루틴

기능 단위로 작게 커밋하고 자주 push한다.
작업이 길어질수록 충돌이 커지고,

나중에 합치기 어려워진다.

git add -A
git commit -m 'feat: ...' //커밋 메세지 작성
git push

커밋 메시지는 팀 규칙을 규정하고

그 규칙을 따르는 것을 추천한다.

(예: feat, fix, chore, refactor)

---

develop로 합치기(PR) 루틴

PR 올리기 직전에 반드시 마지막 동기화를 한다.
이 과정의 목적은 PR 버튼 누르는 순간

충돌이 터지는 상황을 줄이는 것이다.

 

1) develop 최신화

git checkout develop
git pull origin develop

 

2) feature로 이동 후 develop 반영
(충돌 있으면 여기서 해결)

git checkout feature/seunghwan
git merge develop
git push

 

3) GitHub에서 PR 생성

• base: develop
• compare: feature/seunghwan
• 리뷰 후 merge

---

PR 머지 후 팀 공통 루틴

누가 PR을 머지했든 다른 사람들은

작업 시작 전에 develop를 다시 당겨야 한다.

내 로컬 develop가 옛날 상태면

다음 작업에서 충돌 가능성이 바로 올라간다.

git checkout develop
git pull origin develop

---

충돌을 줄이는 팀 규칙 3개

1. 같은 파일을 건드릴 예정이면 작업 시작 전에 공유
   > 예: anime.jsp를 동시에 수정하면 충돌 가능성 급상승
2. PR은 작게/자주할 것
   > 기능이 완전히 끝날 때까지 한 번에 올리면
   > 충돌도 커지고 리뷰도 어려워진다.
3. PR 전에 feature에 develop merge는 필수
   > 충돌이 나면 PR에서 터뜨리지 말고
   > 내 feature에서 먼저 해결하고 들어간다.

---

※ 포인트 정리

pull하면 내 이클립스 코드가 바뀌나?

바뀐다.

git pull origin develop을 하면

로컬 develop 작업 폴더가

원격 develop 최신 커밋 기준으로 업데이트된다.

파일이 추가/수정/삭제될 수 있다.

두 사람이 같은 파일을 각자 feature에서 수정하면
develop 머지 때 무조건 터지나?

무조건은 아니다.

서로 다른 줄/영역을 수정했다면 자동 병합될 수 있다.

같은 줄/영역을 수정했다면 충돌이 난다.

그래서 ‘PR 직전 feature에서 develop merge’ 단계에서

미리 충돌을 처리하는 루틴이 중요하다.

checkout은 뭔가?

브랜치를 ‘바꾸는 것’이다.

지금 내 작업 폴더의 기준을 해당 브랜치로 전환한다.

예시)

• git checkout develop 하면
  작업 폴더가 develop 기준으로 바뀐다.
• git checkout feature/seunghwan 하면
  feature 기준으로 바뀐다.

---

[ 마무리 ]

이 루틴의 핵심은 하나다.

develop를 최신으로 유지하고
feature에 미리 반영한 뒤, PR로만 합친다.

팀이 이 루틴을 고정하면,

충돌은 ‘가끔 해결하는 이벤트’가 아니라

‘예상 가능하게 관리되는 절차’가 된다.

 

Git 루틴 최종 체크리스트

▶ 기본 원칙
develop는 통합 브랜치이자 기본 브랜치다
main은 최종 배포 브랜치다
각자 작업은 feature/이름-기능 브랜치에서만 한다
develop에는 직접 push하지 않고 PR로만 머지한다

▶ 매일 작업 시작 루틴
develop를 최신 상태로 만든다
내 feature 브랜치로 이동한다
최신 develop를 내 feature에 반영한다

▶ 작업 중 루틴
기능 단위로 작업을 쪼갠다
작은 단위로 자주 커밋한다
커밋한 내용은 feature 브랜치에 자주 푸시한다

▶ develop로 합치기(PR) 루틴
PR 올리기 직전에 develop가 최신인지 다시 확인하고 최신화한다
최신 develop를 내 feature에 한 번 더 반영한다
충돌이 나면 PR 전에 내 feature에서 먼저 해결한다
feature에서 develop로 PR을 만들고 리뷰 후 머지한다

▶ PR 머지 후 팀 공통 루틴
누가 PR을 머지했든, 다른 사람은 작업 시작 전에 develop를 다시 최신화한다
이후 새로운 작업은 다시 feature에서 시작한다

▶ 충돌을 줄이는 팀 규칙
같은 파일을 크게 수정할 예정이면 작업 시작 전에 공유한다
PR은 작게, 자주 올린다
PR 전에 feature에 develop 반영은 필수로 한다