1. Commit, Branch, PR 등 컨벤션을 정합니다.

양식이 통일되어야 원활하게 확인할 수 있기 때문에 컨벤션을 미리 정하고 협업을 하는 것이 권장됩니다.

1) Commit Message Convention

많이 사용하는 commit convention은 아래와 같습니다.

type: subject

body

footer

필수

  • type : 변경 사항의 유형, 소문자
  • subject : 간결한 변경 사항 설명, 첫 글자는 소문자로 작성

선택

  • body : 변경 사항에 대한 자세한 설명
  • footer : 추가적인 메타데이터, 관련 이슈 참조 등

타입

  • feat : 새로운 기능 추가
  • fix : 버그 수정
  • docs : 문서 수정
  • style : 코드의 의미에 영향을 미치지 않는 변경사항
  • refactor : 코드 리팩토링(기능은 그대로지만 코드 재구성)
  • test : 테스트 추가 및 수정
  • chore : 빌드, 보조 도구, 라이브러리 등의 변경사항

2) Branch Strategy

많이 사용하는 Git 브랜치 전략에는 대표적으로 Git Flow 가 있습니다.

git_flow

  • main : 안정적인 프로덕션 코드 저장
  • develop : 기능을 통합하는 브랜치
  • feature : 새로운 기능 개발, dev 브랜치에서 파생
    • 명명 예 : feature/sign-up
  • release : 배포 준비를 위해 버그 수정 및 최종 조정
    • 명명 예: release/1.0.0
  • hotfix : 프로덕션에서 발생한 긴급 버그 수정, main에서 파생
    • 명명 예: hotfix/login-bug

3. Pull Request(PR) 템플릿

PR을 명확하게 작성하고 팀의 코드 리뷰 프로세스를 체계적으로 유지하기 위해 사용합니다. 팀마다 다르지만 일반적으로 다음과 같은 섹션을 포함합니다.

1. 제목
2. 설명
3. 체크리스트
4. 관련 이슈
5. 스크린 샷(선택)
6. 주석
## 제목
<!-- 
간결하고 명확한 PR 제목을 작성하세요. 
예시: "Add OAuth 2.0 support for user authentication" 
-->

## 설명
<!-- 
변경 사항에 대한 자세한 설명을 작성하세요.
무엇이 변경되었는지, 왜 변경되었는지, 어떻게 변경되었는지를 설명합니다.
-->

## 체크리스트
<!-- 
PR을 제출하기 전에 다음 항목들을 확인하세요.
-->
- [ ] PR 제목은 적절하고 명확합니다.
- [ ] 코드가 의도한 대로 동작합니다.
- [ ] 새로운 기능이나 수정된 기능에 대한 테스트를 추가했습니다.
- [ ] 문서(README 등)를 업데이트했습니다.
- [ ] 로컬 환경에서 모든 테스트를 통과했습니다.

## 관련 이슈
<!-- 
관련된 이슈 번호를 참조합니다.
예시: "Closes #123" 
-->
Closes #

## 스크린샷
<!-- 
UI 변경 사항이 있는 경우 스크린샷을 추가하세요.
-->
![스크린샷 설명](URL)

## 주석
<!-- 
리뷰어에게 도움이 될 추가 정보나 주석을 작성하세요.
-->

PR 템플릿 사용 방법

Github Repository에서 PR 템플릿을 추가하려면 .github 디렉토리에 PULL_REQUEST_TEMPATE.md 파일을 생성하면 됩니다.

새로운 PR을 만들 때 자동으로 템플릿 내용이 표준화되기 때문에 코드 리뷰가 체계적으로 이루어질 수 있습니다.


2. 초기 설정

팀장이 Repository를 만들고(Organization으로 만들면 팀의 관심사만 분리되기 때문에 사용하는 것이 좋습니다) 팀원들을 초대합니다.

Github Repository의 main 브랜치에서 develop 브랜치를 만듭니다.


3. 기능 개발

1) 팀원들은 Github Repository를 로컬로 clone 합니다.

git clone {Github Repository Https 주소}

2) 가져온 저장소에서 develop 브랜치로 이동하고 새로운 기능 브랜치를 생성합니다.

// 현재 브랜치(dev)에서 새로운 기능 브랜치 생성
git switch -c {feature/기능}
  • 이때, 만약 develop 브랜치에 갱신된 코드가 있다면 develop에서 pull을 받습니다.
  • 작업하는 중인 코드가 존재한다면 develop로 브랜치를 이동할 수 없기 때문에 잡시 stash 영역(임시 저장 영)에 넣어둡니다.
  • git stash
  • dev 브랜치에서 pull 받은 코드를 현재 기능 구현하고 있는 브랜치에 병합합니다. 그러기 위해서는 작업하고 있는 브랜치로 이동해야 합니다.
  • // 브랜치 이동 git switch {작업하고 있는 브랜치} // dev 브랜치 -> 작업하고 있는 브랜치 병합 git merge develop // 작업하던 기능 stash 영역에서 가져오기 git stash pop

3) 기능을 구현합니다.

4) 완료한 기능을 저장소에 반영합니다.

  • add

      git add {파일} // 파일명이 아닌 . 을 입력하면 변경된 모든 파일이 add 됩니다.

  • git의 staging 영역에 파일을 추가합니다.

  • commit

      git commit -m {commit message}

    -m : commit message 를 인라인으로 작성하라는 옵션입니다.

  • 스테이징 영역에 추가된 변경 사항을 영구적으로 로컬에 저장하는 명령어입니다.

  • pushremote에 로컬 브랜치와 같은 이름의 브랜치를 만들면서 코드를 push하라는 명령어입니다.

  • git push origin {로컬 브랜치와 같은 브랜치명}

5) Github에 push한 브랜치에서 develop 브랜치로 Pull Request를 보냅니다.

  • 팀원들은 해당 PR에 코멘트를 작성합니다.
    • 만약 출돌이 없으면 merge 합니다.
  • 만약 충돌이 있으면 PR을 close 하고 코드를 수정합니다.
  • 같은 PR에서 reopen 한 후 ‘수정완료’ 와 같은 코멘트를 작성합니다.
  • 팀원들의 확인 후에 아무 문제가 없으면 merge 합니다.

4. 개발 환경에 배포

develop 브랜치에 각 기능 개발이 완료된 코드를 병합 완료하면 release 브랜치에 pr 및 merge를 합니다.

이때 배포 환경에서 문제가 있다면 hotfix 브랜치를 새로 만들어 버그를 고칩니다.


5. 운영 환경에 배포

release 브랜치의 코드가 정상 작동한다면 안정적으로 운영하는 main 브랜치에 release 브랜치의 코드를 머지합니다.

저작자표시

+ Recent posts

티스토리툴바