GitHub Flow로 협업하기

 

1. 로컬의 브랜치 확인

• 터미널에서 현재의 브랜치를 확인한다
  • git branch
• 만약 이전에 작업을 끝낸 feature브랜치에 위치 한다면 master브랜치로 이동
  • git switch master
• 그 후 로컬에서 작업을 끝낸 feature브랜치 삭제 하려면 삭제
• 로컬 master 브랜치가 최신 상태인지 확인. 만약 최신이 아니라면, 최신 변경 사항을 pull 개발 환경을 업데이트
  • git pull origin master

2. feature 브랜치 생성

• 브랜치 이름 작업할 이슈명이랑 통일하기
  • git checkout -b feature/issue#1 master
  • master 브랜치로 부터 분기된 feature/issue#1를 생성하고 이동하겠다는 뜻

3. 기능 개발

• 새로운 기능을 구현하고 코드를 작성. 이 단계에서 필요한 모든 변경 사항을 해당 기능 브랜치에서 작업.

4. 커밋

• 기능 개발이 완료되면 커밋을 한다. 커밋 컨벤션 맞춰서
• 커밋 단위는 이슈의 task단위 (기능 단위)
• 커밋 컨벤션 body, footer도 있지만 이거 까지 적용하는 것은 비현실적으로 생각됨
  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • docs: 문서 수정
  • style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
  • refactor: 코드 리펙토링
  • test: 테스트 코드, 리펙토링 테스트 코드 추가
  • chore: 빌드 업무 수정, 패키지 매니저 수정
• 커밋 컨벤션 예시들
  • git commit -m "feat: 검색창 완성 #1"
  • #1을 넣으면 깃허브에 등록한 이슈와 연동되므로 꼭 신경써서 작성하자
  • 커밋 전에 터미널에서 밑처럼 상태 확인, 저장 먼저해야함
• 터미널에서 커밋 하는 순서
  • git status
  • git add -A // 변경사항 전부 저장한다는 뜻 일부만 커밋할 수도 있는데 좀 어려움
  • git commit -m "feat: 검색창 완성 #1"

5. 원격 저장소에 푸시(push)

• 커밋을 완료하면 해당 브랜치를 원격 저장소에 푸시.
  • git push origin feature/issue#1
• 이렇게 하면 다른 팀원들이 해당 기능에 대한 변경 사항을 확인하고 리뷰할 수 있다.
• 이슈랑 커밋 연동된 모습, 구현한 기능 체크박스 체크
• 사진은 연습 이라고 되어있는데 실수 한 것일 뿐 제대로 작성한다면 feat: 검색창 완성 #1 라고 잘 나온다

6. Pull Request 생성

• push를 하고 나면 해당 기능 브랜치에서 master 브랜치로 Pull Request를 생성할 수 있다.
• 이를 통해 다른 팀원들이 코드를 검토하고 피드백을 제공할 수 있다.
• 하나의 이슈의 기능들을 모두 해결한 후 Pull Request를 생성하는 것이 이상적으로 판단된다
• 하지만 이를 지키기 힘들 것 같다고 판단된다. 따라서 실수한다면 아래처럼 한다
• Pull Request 까지 번호를 연결하긴 힘들다고 판단되므로 Pull Request 뒤에 번호 (#1)를 삭제하고 생성한다

7. Pull Request 리뷰

• Pull Request가 생성되면 다른 팀원들이 코드를 검토하고 피드백을 제공. 필요한 경우 피드백에 대한 수정을 수행하고 커밋

8. Merge

• 한 이슈의 모든 기능에 대한 리뷰 및 수정이 완료되면, Pull Request를 master 브랜치로 병합

9. Feature 브랜치 삭제

• 기능이 develop 브랜치로 병합되었으므로 해당 기능 브랜치를 삭제 (옵셔널)
  • 깃허브 사이트에서 삭제 (remote에서 삭제)
  • 터미널에서 삭제 (local에서 삭제)
    • git branch -d feature/issue#1

 

happy case로만 순서를 정리해 봤는데도 지키기 어려워 보인다