☁️ goormTIL | Git 협업 #48

매루·2025년 11월 17일

DEEPDIVE_FE TIL goormTIL

goormTIL

목록 보기

46/67

📅 2025-11-17

➡️ Git 협업에 대해 새롭게 알게 된 것 또는 헷갈리는 부분 정리

🔎 학습 리마인드

📌 Git 핵심 명령어 정리

명령어	설명	예시
`git init`	현재 폴더를 Git 저장소로 초기화	git init
`git add`	변경된 파일을 스테이징 영역에 추가	git add . (전체 파일 추가)
`git commit`	스테이징 영역에 있는 변경사항을 커밋(버전)으로 확정	git commit -m "feat: 로그인 로직 추가"
`git push`	로컬 저장소의 커밋을 원격 저장소로 업로드	git push origin feature/login
`git pull`	원격 저장소의 최신 커밋을 로컬 저장소에 가져오고 병합( fetch + merge 를 합친 명령어)	git pull origin dev
`git merge`	다른 브랜치를 현재 브랜치에 병합(Merge Commit)	git merge feature/login
`git checkout`	특정 브랜치로 이동하거나, 특정 커밋 시점으로 이동	git checkout dev
`git branch`	브랜치를 생성, 조회, 삭제 등에 사용	git branch feature/login
`git rebase`	커밋 히스토리를 재정렬하여 깔끔하게 합치는 방법 ( 지금은 하지 마세요 )	git rebase dev

📌 Git 브랜치 전략

여러 명이 동시에 개발할 때, 충돌을 최소화하고 개발이 끝나면 안전하게 통합(merge)하기 위해서 브랜치 전략이 필요

💡 대표적인 브랜치 전략

Git Flow: 오래된 전통적 방식. develop, feature, release, hotfix 등을 세분화
A-One-Flow, Trunk Base Development 등등…

💡 Git Flow

일반적으로 나누는 브랜치
- 메인 or 마스터 브랜치(main, master) → 배포용
- 디벨롭 브랜치(dev)
- 기능 단위 별 브랜치(i-12)

병합 순서

기능 단위 별 브랜치 → 병합 → 디벨롭 브랜치 → 최종병합→ 마스터 브랜치

브랜치명	설명	예시
`main`	배포용 브랜치	`main`
`dev`	통합(개발)용 브랜치	`dev`
`feature/` or `feat/`	기능 개발 브랜치	`feature/login`
`bugfix/` or `fix/`	버그 수정 브랜치	`bugfix/nav-bar`
`hotfix/`	긴급 패치 브랜치	`hotfix/payment`
`chore/`	문서, 설정파일 변경 브랜치	`chore/update-readme`
`docs/`	문서 작업 브랜치	`docs/api-guide`
`refactor/`	리팩토링 브랜치	`refactor/homepage-ui`

권장하는 브랜치 관리 Flow

📌 Git 컨벤션과 코드 스타일 통일

공통된 컨벤션을 정해두고, 최대한 엄격하게 지키는 것이 좋음

💡 커밋 메시지 컨벤션

커밋 타입	설명	예시 메시지
`feat`	새로운 기능 추가	`feat: 회원가입 로직 추가`
`fix`	버그 수정	`fix: 로그인 시 비밀번호 검증 오류 해결`
`docs`	문서 수정	`docs: README에 프로젝트 개요 추가`
`style`	코드 포맷팅, 세미콜론 누락 등; 코드 변경 없음	`style: ESLint 룰 적용 및 포맷 수정`
`refactor`	코드 리팩토링, 성능 개선 (기능 변경 없이 구조 개선)	`refactor: 홈 화면 UI 로직 개선`
`test`	테스트 관련 코드(누락된 테스트 추가, 리팩토링 테스트 등)	`test: 유닛 테스트 추가`
`chore`	빌드 업무, 패키지 매니저 설정, 기타 자잘한 수정	`chore: package.json 버전 업그레이드`

팀에 따라 [이슈번호] 등의 형식을 추가하기도 함

💡 코드 스타일 가이드 (Prettier, ESLint 등)

Prettier: 코드 포맷팅 자동화 도구 (코드 포매터)
ESLint: 자바스크립트 문법 검사 (정적 분석기)
- 의존성 배열, 리스트 Key 등
팀에서 합의한 룰을 공유하고, 자동화하여 스타일이 강제로 통일되도록 세팅

💡 PR

Pull Request (PR)

“내가 작업한 내용을 코드베이스에 병합(Merge)하고 싶어요!” 라는 요청
코드 변경 사항을 팀원들에게 공유하고, 리뷰 과정을 통해 코드 품질을 높일 수 있음
바로 공용 브런치로 병합되는게 아니라 요청을 거치게 되므로 충돌, 오류 등에 좀 더 안전하게 대응할 수 있음

좋은 PR의 조건

작은 단위로 PR 작성하기
- 한꺼번에 너무 많은 변경사항이 담긴 PR은 리뷰하기 어려움
- 한 기능 or 한 이슈 단위로 나누어 PR을 올리는 습관이 굉장히 중요함
- feat/login-page 이런식으로 page 단위의 모든 기능들을 전부 다 한 PR 에 넣으려고 하면 리뷰가 불가능할 수준으로 작업 단위가 커지게 됨
의미 있는 커밋으로 구성하기
- feat: 로그인 화면 추가 → design: UI 컴포넌트 배치 수정 → fix: 로그인 오류 수정
- 이런 식으로 커밋 히스토리를 읽었을 때, 작업 흐름이 자연스럽게 보이도록 함
PR 템플릿 활용하기
- 작업 배경, 주요 수정 사항, 리뷰 포인트, 테스트 방법 등을 간단히 정리
- 예시) 뱅크샐러드 PR 템플릿
  - Background: 이 PR을 작성한 배경 및 관련 이슈(디자인 문서, 작업 티켓 등)
  - Important: 리뷰어에게 꼭 전달하고 싶은 논의 사항
  - Changes: 핵심 변경 사항(커밋 해시와 함께)
  - Test Guide: QA 방법, 전/후 스크린샷 등

라벨(Label) 활용

기능 라벨: feature, bugfix, hotfix 등
상태 라벨: Pending, Review in progress, Approved 등
라벨을 통해 PR 상황을 한눈에 파악할 수 있어, 팀원들의 시간 절약에 큰 도움이 됨

나쁜 PR

한꺼번에 너무 많은 변경 사항(리뷰어가 내용을 파악하기 어려움)
설명 없이 코드만 덩그러니 있음(리뷰어가 맥락을 알기 힘듦)
중복 · 불필요한 파일이 많음

💡 코드 리뷰

코드리뷰는 지적이 아니라 협업
더 좋은 코드를 함께 만들어가기 위한 대화
예시
- 질문 유형 코멘트
  1. 구현 의도 질문
    
    “이 부분에서 이 로직(XYZ)을 선택하신 이유가 궁금합니다. 다른 방식(ABC)으로 구현하면 어떤 이점 혹은 단점이 있을까요?”
  2. 사용 라이브러리 질문
    
    “이 라이브러리를 선택하신 이유가 있나요? 직접 구현같은 좀 더 가벼운 대안도 있는 것 같아서요.”
  3. 가정/전제 질문
    
    “이 로직이 실행되기 전에 이미 유저 권한이 검증된 상태라는 전제를 가지고 계신 것 같은데, 맞을까요?”
- 개선 제안 유형 코멘트
  1. 코드 구조 개선
    
    “이 함수가 하는 일이 조금 많은 것 같습니다. A 기능과 B 기능으로 나누면 더 가독성이 좋아질 것 같아요.”
  2. 성능 개선
    
    “현재 매번 데이터베이스에 접근하는 로직인데, 캐싱을 도입하면 성능 면에서 이점이 있을 것 같습니다.”
  3. 로직 단순화
    
    “여기에서 if-else가 계속 중첩되는데, early return을 쓰면 더 명확하고 짧아질 것 같아요.”
  4. 네이밍 개선
    
    “handleData()보다 transformUserData()처럼 함수를 더 구체적으로 설명하는 이름은 어떨까요?”
  5. 타입 안전성/오류 처리
    
    “유저 입력값이 null인 경우도 대비해야 할 것 같아요. 예외 처리를 추가해주세요.”
- 칭찬 유형 코멘트
  1. 아이디어 칭찬
    
    “이 부분은 좋네요! 배워갑니다~”
  2. 가독성 칭찬
    
    “코드가 매우 깔끔하고 읽기 편하네요.”
- 설명 요청 유형 코멘트
  1. 복잡한 알고리즘/로직
    
    “이 로직이 꽤 복잡한데, 주석을 추가해주실 수 있을까요?”
  2. 레거시 코드 맥락
    
    “기존 제 코드 부분과 호환이 이뤄지는지 궁금합니다.”
  3. 서드파티 API 연동
    
    “이거 API를 어떻게 호출하는지 조금 더 자세한 예시나 문서를 링크해주실 수 있을까요?”
- 정보 공유 유형 코멘트
  1. 문서/가이드 링크
    
    “이 부분에서 공식 가이드는 이렇게 권장하고 있는데, 참고해보시면 좋을 것 같아요. 공식문서 링크”
  2. 관련 라이브러리 소개
    
    “비슷한 기능을 하는 ABC라는 라이브러리가 있는데, 더 가벼울 수 있으니 한번 살펴보셔도 좋겠습니다.”
- 코딩 스타일 지적
  1. 불필요한 주석/로그
    
    “개발 과정의 디버깅 로그(console.log)와 주석(// 테스트)은 머지 전에 제거하는 게 좋겠습니다.”
  2. 포맷팅/린트
    
    “ESLint 규칙에 따라 세미콜론을 붙여야 하는데, 자동화 설정이 안 되어 있는지 확인해주세요.”
  3. 팀 컨벤션 상기
    
    “이런 경우에는 snake_case보다는 camelCase를 권장하고 있습니다. (컨벤션 링크) 확인 부탁드려요!”
    
    “코딩 컨벤션에 따르면 함수 선언부는 윗줄에 작성하고, 변수는 const를 먼저 선언하도록 하고 있습니다. 수정 부탁드려요.”
- 머지 관련(Merging & Conflict) 유형 코멘트
  1. 머지 충돌 안내
    
    “지금 dev 브랜치와 충돌이 발생했네요. 충돌 부분 확인 후 해결 부탁드립니다.”
  2. 머지 시점 확인
    
    “이 PR은 이 PR(링크) 이 머지된 후에 머지하는 게 좋겠습니다. 순서가 바뀌면 기능이 깨질 수도 있어서요~ 트래킹 부탁드립니다.”
  3. 스크럼 이후 머지 제안
    
    “내일 스크럼 때 관련 이슈를 한 번 더 논의하고 머지하면 어떨까요? 공유가 필요해 보입니다.”
- 최종 승인 & 기타(LGTM, 마무리)
  1. LGTM(승인)
    
    “LGTM! 특별히 문제 없어 보이고, 제안해주신 부분도 좋습니다.”
  2. 조건부 머지(Conditional)
    
    “크게 문제는 없지만, 위에서 제안한 부분만 반영해주시면 머지 가능합니다!”
  3. 추가 리뷰 요청
    
    “제가 로컬에서 테스트해봤는데 작동은 잘 됩니다. 혹시 다른 분들도 한 번씩 확인 부탁드려요.”

📌 정리

브랜치 전략
- 기능별 브랜치를 만들어 독립적으로 작업 → dev(통합) → main(배포)
PR & 코드 리뷰
- 작은 단위로 PR을 올리고, 명확한 설명과 함께 리뷰 요청
- 리뷰 시, 개선 제안·칭찬·설명 요청 등 적극적 커뮤니케이션 (중요)
컨벤션 및 스타일 통일
- 커밋 메시지 컨벤션, 코드 스타일(Prettier/ESLint) 등을 확실히 정해놓고 모두가 지키기
Clean Code 습관
- 불필요한 코드/주석/커밋 줄이고, 의미 있는 변경만 남기기
- 변수명, 함수명 통일
- 기능 변경 시점마다 정리하는 습관 들이기