대형 프로젝트에서 Github 잘 활용하는 법

스윈님 레포에 보면 이런 식으로 브랜치가 많다. 브랜치들 네이밍 규칙이 뭐냐고 여쭤보니 

{카테고리 : feature, refactor ...} / {제작자} / {애자일 할 때 그 스프린트} / {기능 세부}

이런 식이라고 하셨다. 별 생각 없이 지은 거라고 하시긴 했지만 공동 작업을 많이 안 해봐서 merge request도 제대로 보내본 적 없는 나에게는 다소 신문물이었다. 

그래서 url_navigation_pkg를 만들 때는 이를 적극 채택하여 나도 똑같이 따라 해 보기로 했다. 

 

Main에 깔끔하게 Merge Request / Pull Requeset 올리는 방법

1. 작업용 브랜치 생성
2. 작업 단위 잘게 나눠서 커밋  
   1. 한 커밋 = 하나의 논리적 변경이 되도록 의식적으로 나누기
      1. 버그 수정, 리팩토링, 신규 기능 등을 섞지 않기
      2. 커밋 메시지는 의도가 보이도록
         1. fix: ..., refactor : ... , feat :... 
3. 코드 정리 (포맷팅, 린트, 테스트)
4. 커밋 정리 (리베이스)
   1. 너무 잘게 쪼갠 커밋이나 중간에 깨지는 커밋을 정리
5. 최신 main 반영
6. MR / PR 작성 (제목, 설명, 리뷰 포인트 정리)
7. 리뷰 반영 & 커밋 히스토리 정리 후 merge

브랜치 이름 예시 :

• feat/ziwon/sprint0/ros_wrapper
• refactor/ziwon/sprint1/url_navigation_cleanup
• bugfix/ziwon/sprint2/odom_framefix
• dev/ziwon/sprint0/keit_humanoid
• hotfix/ziwon/prod/launch_param_fix

카테고리 규칙

• feat
  • 새로운 기능 추가
• refactor
  • 동작은 유기, 구조/가독성 개선
• bugfix
  • 버그 수정
• dev
  • 특정 프로젝트용 개발
• hotfix
  • 긴급 패치

Work Flow

• 현재 브랜치 이름 변경

# 예: 지금 브랜치를 feat/ziwon/sprint0/ros_wrapper 로 바꾸기
git branch -m feat/ziwon/sprint0/ros_wrapper

# 원래 이름 old_name 이라고 가정
git push origin :old_name  # 원격 브랜치 삭제
git push -u origin feat/ziwon/sprint0/ros_wrapper

• 코드 정리 (포맷, 린트, 테스트)

black .
flake8
pytest

# 발견된 이슈는 커밋 단위로
git add .
git commit -m "chore: apply formatter and linter"

• merge commit

git fetch origin
git merge origin/main
# 충돌 해결 후
git add <file>
git commit


git push -u origin feat/ziwon/sprint0/ros_wrapper --force-with-lease

• MR 작성 시 체크리스트
  • [변경 요약] : 무엇을 추가/수정/리팩토링했는지
  • [배경/이유] : 왜 이 작업이 필요했는지
  • [주요 리뷰 포인트] : 로직이 크게 바뀐 부분, 고민한 설계
  • [테스트]: 실제 로봇/시뮬레이터에서 확인한 내용 등

의식적으로 규칙을 지켜야 스파게티 코드를 방지할 수 있다.