Git 활용 규칙 - boostcamp-2020/IssueTracker-13 GitHub Wiki

커밋

커밋규칙: https://junwoo45.github.io/2020-02-06-commit_template/

template을 이용하면 매우 편합니다!

커밋은 함수 단위 권장, 작업단위와는 연동되지 않음

ex. 클래스 만들고, constructor 만들고 1 commit → 메서드 당 1 commit

# <영어소문자타입>: <한글제목>

##### 제목은 최대 50 글자까지만 입력 ############## -> |

# 본문은 위에 작성
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |

# 꼬릿말은 아래에 작성: ex) #이슈 번호 - 이때는 close 영어쓰기 가능

# --- COMMIT END ---
# <타입> 리스트
# feat: 기능 (새로운 기능)
# fix: 버그 (버그 수정)
# refactor: 리팩토링
# style: 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs: 문서 (문서 추가, 수정, 삭제)
# test: 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore: 기타 변경사항 (빌드 스크립트 수정 등)
# ------------------
# 제목 첫 글자를 대문자로
# 제목은 명령문으로
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------`

PR 컨벤션, 단위

https://tv.naver.com/v/15355381 (16분 부터 PR에 대한 내용)

  • Issue별 PR
  • 제목 형식: [#이슈번호] 구현 내용
  • 구현한 함수 리스트, 구현 의도(왜?) - 무엇을? 은 Issue에서
    • ex. 프로토콜/라이브러리를 쓴 이유, 큰 작업흐름, 함수, 클래스를 나눈 이유
  • 중점적으로 리뷰, 논의하고 싶은 부분 (고민거리, 아쉬운점, ...)
  • max 30분 안에 작성 가능한 분량
  • PR merge는 마지막 리뷰어가 수행

PR 예시

[#3] GitHub 로그인 구현

구현의도(Issue 단위, 큰 틀에서의 왜? 들어가도록)

- 추상화 의도(재사용성, 인터페이스, etc...)
- 함수 구분 기준
- 클래스 계층구조
- Class, Struct, Object의 사용 의도

기능 흐름도, 클래스 다이어그램(선택사항)

사용된 기술

- 오픈소스 라이브러리
- 라이브러리를 왜? 썼는가

리뷰 & 논의사항 & 궁금한점
- A 부분은 더 깔끔한 방식이 있을까 궁금하다. 
- B 클래스명은 괜찮은 지 궁금하다.

Git flow

  • git ignore (꼭 넣자)

  • https://www.toptal.com/developers/gitignore

  • 깃 플로우

    https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

    master: 부캠 저장소 배포브랜치

    develop: 부캠 취합 브랜치 / 포크한 브랜치

    feature: 개별 Issue 단위 브랜치, 개인이 쓰는거

    https://s3-us-west-2.amazonaws.com/secure.notion-static.com/6ab8be52-b132-4279-a936-c9d19aaca273/Untitled.png

    1. repo를 본인 계정으로 fork하고
    2. fork된 repo의 develop에서 새로운 feature 브랜치 생성
    3. feature 개발
    4. 이 상태에서 본인계정: feature/xxx → 부캠계정: develop으로 PR
    5. PR 리뷰 → merge
    6. 부캠계정:develop에서 취합
    7. 목요일 저녁에 부캠계정:develop을 부캠계정:master로 배포
    8. nCloud API 서버 → 금요일 날 변경
    9. 핫픽스도 비슷한 방식으로

    Branch 용어통일

    Upstream: 부캠계정 GitHub

    Origin: 개인계정 GitHub

    Local: 본인 PC

merge

  • rebase 아니고 merge로
  • iOS: 서로 1인 리뷰 통과하고 merge
  • JS: 다른 2인 리뷰 통과하고 merge
  • 하루 치 모아서 → 6~7시에 리뷰 및 merge
  • 1개이상 코멘트, 1개이상 칭찬

Issue & milestone & project

  • Issue 배분
    1. 주차별 Task Pool(=milestone)이 있고, 거기서 가져가면서 Pool을 끝내는 식으로
    2. 작업단위를 미리 지정해놓는다. (마이크로 스크럼 단위, 조정 가능)
    3. 작업단위로 일자 별 진도를 측정
  • 1명당 1개의 issue만 가지고 있기
  • 마이크로 스크럼 시작 때 새로 가져가는 Issue 말하기, Kanban 옮겨놓기
  • 하나의 카테고리(화면단위)가 완성될 때까지 같은 카테고리에 집중하기
    • 다른 카테고리의 issue는 가져가지 않기
  • backlog는 마지막 마이크로 스크럼에서 merge 하면서 총합하여 업데이트
  • Label 사용법
    • iOS / Backend / Frontend
    • 화면단위 or 기능단위
    • 선택적으로: bugfix 등 태그 사용

Boostcamp IssueTracker 13

⚠️ **GitHub.com Fallback** ⚠️