[ TIL ] Day 39 - Git / GitHub 팀 협업하기

🗓️ 수업 일자 : 2025.11.19

✨ 오늘의 수업 평가 :  [ PROJECT ]  ✨🙌 작은 성취, 큰 기쁨 ✨🙌

 

팀 작업 마지막, 개인별 개발 레포트 작성!

사실 별거 아니라고 생각했는데 막상 쓰고 보니

내가 뭘 했고, 어떤 부족한 점이 있었는지, 새롭게 배운 것 등등

작업했던 시간들이 새록새록 떠올랐다.

 

부족함 많은 팀원이었는데, 잘 이끌어줘서 고마운 팀원분들👍

다음 팀에서 만나면, 그때는 더 성장한 모습 보여드릴게요😉

 

👩‍💻 [개인 / 팀 프로젝트] 오늘 작업 내용 💻
- 팀 프로젝트 작업 : 팀 프로젝트에 대한 개인 회고록 작성

 

📝  오늘 배운 내용  

- GitHub 팀 협업 셋팅

- [실무] GitHub 팀 협업 상황 별 명령어 모음

 

---

1. GitHub 팀 협업 셋팅

협업 과정 

1단계 : [팀장] 협업을 위한 저장소를 만들고 팀원을 추가합니다.

            팀장(또는 대표)이 깃허브에 프로젝트 개발을 위한 저장소를 만듭니다.

            이후 해당 저장소의 셋팅으로 들어가 팀원들을 협업자(Collaborator)로 등록합니다.

            [팀원] 팀 저장소를 개인 저장소에 복제 합니다

            팀원들은 팀 저장소에 접속하여 상단 메뉴 중 [Fork]를 이용하여 개인 원격 저장소와 연결합니다.

2단계 : 실제 개발을 시작합니다.
            팀원들은 자신의 로컬 환경에 Fork한 저장소를 연결하고, 규정에 맞추어 자신의 브랜치를 생성합니다.

            단위 작업이 끝날 때마다 해당 브랜치로 커밋하고 푸시합니다. 

3단계 : [팀원] 개발이 완료되면 풀 리퀘스트(=PR) 를 요청합니다

            팀원은 자신의 작업이 완료되면 개인 원격 저장소로 최종 파일을 푸시하고,

            해당 내용을 팀 저장소의 팀장/리뷰어에게 풀 리퀘스트(=PR)를 요청합니다

            [팀장] 코드 리뷰을 시행합니다.

            팀장/리뷰어는 PR 내용과 코드를 확인 한 뒤 수정이 필요한 부분은 comment로 수정 요청을 진행합니다. 

            내용을 받은 팀원은 코드를 수정한 뒤 커밋 & 푸시를 합니다. 

            그럼 Github에서 알아서 이전에 작성한 PR의 맨 마지막으로 해당 커밋을 연동 해 줍니다. 

            팀원은 수정 완료한 작업에 대해서 "Resolve conversation" 버튼을 눌러 완료됨을 알려줍니다.

4단계 : 최종적으로 브랜치를 병합합니다. 

            문제가 없는 PR이거나, 수정이 완료된 PR에 대해서는 팀장/리뷰어가 최종적으로 브랜치 merge(병합)을 진행합니다.

Github 팀 협업과정 다이어그램

실제 PR의 수정 요청 메세지 화면

 

 

브랜치 구성 방식

다양한 브랜치 전략이 있지만, 기본적으로 많이 사용하는 Git Flow 구조로 설명 합니다 

 

• 주요 브랜치
  • main : github 저장소를 생성하면 만들어지는 기본 브랜치, 주로 서비스를 배포할 때 사용하는 브랜치 입니다. 항상 안정적인 상태를 유지해야 합니다.
  • develop : 다음 배포를 위한 개발 브랜치 입니다. 배포 전 신규 기능 / 버그 / 수정사항등 실제 개발 작업에 관련된 브랜치가 모여 해당 브랜치에서 병합 됩니다.
• 보조 브랜치
  • feature : 새로운 기능이 구현되는 브랜치로, feature/기능명 으로 명칭을 사용합니다. 
  • release: 배포 준비를 위한 테스트 배드용 브랜치로, 버전 정리·QA·경미한 수정만 진행 합니다
  • hotfix: 배포 후 급한 오류를 바로 고치는 브랜치로, main에서 분기 후 코드를 수정하고 다시 main과 dev에 반영합니다.
• 선택적 브랜치 
  • bugfix : 개발 도중 발견된 오류를 해결하는 작업을 하는 브랜치로, feature에서 분기되어 만들어 집니다.

브랜치 전략 이미지 (from claude)

 

 

2. [실무] GitHub 팀 협업 상황 별 명령어 모음 - 순서대로 사용

1) 초기 셋팅하기 : 팀 작업 전체 과정에서 1번만 작업하면 됨

(팀 저장소를 Fork 해서 clone URL을 가지고 있는 상태) 

# 1️⃣ 팀 저장소를 바로 가져오는것이 아니라 내 저장소로 Fork 해 온 저장소를 연결
git clone Fork해온-내-저장소-URL    

# 2️⃣ 작업 할 폴더로 이동
cd 프로젝트 폴더

# 3️⃣ 팀 저장소를 추가로 저장하여, 전체 코드가 업데이트 될 때마다 사용 
git remote add upstream 팀-저장소-URL

# 4️⃣ 저장소 URL이 각각 잘 셋팅 되어 있는지 확인
git remote -v 
# origin : 내 저장소 URL 
# upstream : 팀 저장소 URL 

# 5️⃣ 내 작업을 업로드 할 브랜치를 새로 생성
git switch -b feature/기능명

# 6️⃣ 셋팅 한 브랜치 확인
git branch 
# main : 기본 브랜치 
# feature/기능명 : 방금 생성한 브랜치로, 해당 브랜치가 선택(컬러) 되어 있어야 함

 

 

2) 작업 중간에 팀 저장소의 최신 내용 반영하기

# 1️⃣ 팀 레포의 최신 내용 전부 가져오기
git fetch upstream

# 2️⃣ 내가 작업 중인 feature 브랜치로 이동
git switch feature/기능명

# 3️⃣-1 merge 방식 : 팀 레포의 feature 브랜치를 내 브랜치에 합치기
git merge upstream/feature

# 3️⃣-2 rebase 방식 : 팀 레포의 feature 브랜치를 하나의 라인으로 깔끔하게 합치는 방식
git rebase upstream/feature

# 팀 레포의 브랜치가 develop 또는 다른 브랜치 일 경우 
# 아래와 같이 합칠 브랜치 명을 수정
upstream/develop 
upstream/브랜치명

 

 

3) 개인 저장소로 작업물 저장하기

# 1️⃣ 작업한 파일 스테이징 하기(전체 또는 특정 파일만)
git add . 
git add src/폴더명/파일명 

# 2️⃣ 스테이징에 올린 파일에 대해 저장(커밋)하기
git commit -m "커밋 메세지 작성"


[선택사항] 업로드 전 upstream(팀 저장소) 기준으로 최신 작업물 반영
(언제 최신 파일로 변경 됬을지 모르므로, 가능하면 꼭 하기)


# 3️⃣ 내 저장소로 업로드 하기 
git push origin feature/기능명
# branch가 동일하면 git push만 해줘도 괜찮지만 
# 안전하게 업로드 하기 위하여 가능하면 뒷부분까지 모두 작성을 추천

 

 

---

 

📃 내일은 뭘 배울까 🤔

- 팀 작업 최종 발표

- Prisma ORM 문법 공부