Skip to content

깃 컨벤션과 깃허브 활용 방안

Jump to bottom
LeeJE20 edited this page Dec 21, 2022 · 1 revision

깃 툴

커밋 형식

요구사항

  • 쓰기쉽다
  • 기억하기쉽다
  • 배우기쉽다

선택지

  • udacity

  • angular

    • 예시

      feat($browser): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Breaks $browser.onHashChange, which was removed (use onUrlChange instead)

      feat($compile): simplify isolate scope bindings

Changed the isolate scope binding options to:
  - @attr - attribute binding (including interpolation)
  - =model - by-directional model binding
  - &expr - expression execution binding

This change simplifies the terminology as well as
number of choices available to the developer. It
also supports local name aliasing from the parent.

BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.

To migrate the code follow the example below:

Before:

scope: {
  myAttr: 'attribute',
  myBind: 'bind',
  myExpression: 'expression',
  myEval: 'evaluate',
  myAccessor: 'accessor'
}

After:

scope: {
  myAttr: '@',
  myBind: '@',
  myExpression: '&',
  // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
  myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.
```a

    <type>(<scope>): <subject>

<body> 

<footer>

    • type

      • feat (feature) : 기능
      • fix (bug fix) : 버그 수정
      • docs (documentation) : 문서
      • style (formatting, missing semi colons, …) : 스타일 변경 (형식, 세미콜론 누락 등)
      • refactor : 리팩토링
      • test (when adding missing tests) : 테스트
      • chore (maintain) : 빌드, 패키지 관련 (업데이트 등)

    • scope: 커밋 변경 위치

    • body: 필요시, 변경 이유와 이전 코드와의 차이점

    • footer: 필요시

      • 주요 변경 사항 (변경점)
      • 변경 이유
      • 마이그레이션 참고사항

의사결정

  • angular를 기반해서 사용하자

    • udacity를 기반으로 좀 더 발전시킨 방식 (인 것 같음)
    • body 내용이 구체적 - 뭘 적어야 할지 고민 덜 해도 됨
    • BREAKING CHANGE - 중요한 부분 강조 가능

  • type 형식

  • FEAT: 전부 대문자

  • feat: 전부 소문자

    • 보통 코드짤 때 소문자를 쓰고 있어서 더 편함

  • [FEAT] 대괄호 이용

    • 세미콜론보다 깔끔해보임 (눈에 잘 띈다)

  • ✨feat: 깃모지 이용 https://gitmoji.dev/

    • 템플릿 없으면 커밋메시지를 못 씀 (ex. 외부 컴퓨터 이용 등)

  • 메시지 언어

  • feat: 한글로 작성

    • 가독성이 좋다
    • 빠르게 개발하자

  • feat: write in english

커밋메시지 템플릿

  • cli 도구

  • 참고: 정은 졸프때 썼던 템플릿

    # FEAT: 새로운 기능의 추가 #이슈번호
# FIX: 버그 수정 #이슈번호
# DOCS: 문서 수정 #이슈번호
# STYLE: 코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우) #이슈번호
# REFACTOR: 코드 리펙토링 #이슈번호
# TEST: 테스트 코트, 리펙토링 테스트 코드 추가 #이슈번호
# CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우) #이슈번호
# DEV: 개발 환경 세팅 #이슈번호
# ADD: Feat 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 파일 생성 #이슈번호
# HOTFIX: issue나, QA에서 급한 버그 수정 #이슈번호
# DEL: 쓸모없는 코드 삭제 #이슈번호
# CORRECT: 주로 문법의 오류나 타입의 변경, 이름 변경 등에 사용 #이슈번호
# MOVE: 프로젝트 내 파일이나 코드의 이동 #이슈번호
# RENAME: 파일 이름 변경이 있을 때 사용 #이슈번호
# MERGE: 다른 브랜치 merge #이슈번호
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |
# —————————
#     제목은 명령문 대문자 영어로 적자.
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기
#     본문은 한글로 적는다.
#     본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# —————————

  • 결정사항

# feat : 기능 #이슈번호
# fix : 버그 수정 #이슈번호
# docs : 문서 #이슈번호
# style : 스타일 변경 (형식, 세미콜론 누락 등) #이슈번호
# refactor : 리팩토링 #이슈번호
# test : 테스트 #이슈번호
# chore : 빌드, 패키지 관련 (업데이트 등) #이슈번호
# perf: 성능 향상 #이슈번호
# move: 프로젝트 내 파일이나 코드의 이동, 이름 변경 #이슈번호

##################################################
#----------본문은 50자까지만 작성하기-------------#
# - 변경 이유
# - 이전 코드와의 차이점

# BREAKING CHANGES:주요 변경 사항 (변경점)
# - 주요 변경 이유
# - 마이그레이션 참고사항

브랜치 전략

요구사항

우리 서비스 분석

  • 웹앱
    • 정기 배포 필요 (추후 기능 추가 예정되어 있음, 단위별로 끊어서 개발하기로 협의)
  • 나중에 서비스가 안정화되고 단위별 개발이 필요없어지면 다른 브랜치 전략으로 전환가능

선택지

  • 깃플로우: 정기 배포, 버저닝이 필요한 애플리케이션

    image

    • feature – develop – release – hotfix – master
      • feature: Develop 브랜치에서 기능 구현을 할 때 만드는 브랜치
      • Develop: 다음 릴리즈 버전 개발을 진행하는 브랜치
        • 추가 기능 구현이 필요해지면, 해당 브랜치에서 다시 브랜치(Feature)를 내어 개발을 진행하고, 완료된 기능은 다시 Develop 브랜치로 Merge한다.
      • Release: Develop에서 파생된 브랜치
        • Master 브랜치로 현재 코드가 Merge 될 수 있는지 테스트하고, 이 과정에서 발생한 버그를 고치는 공간이다. 확인 결과 이상이 없다면, 해당 브랜치는 Master와 Merge한다.
      • Hotfix: Mater브랜치의 버그를 수정하는 브랜치
        • 검수를 해도 릴리즈된 Master 브랜치에서 버그가 발견되는 경우가 존재한다. 이때 Hotfix 브랜치를 내어 버그 수정을 진행한다. 디버그가 완료되면 Master, Develop 브랜치에 Merge해주고 브랜치를 닫는다.
      • Master
        • 릴리즈 시 사용하는 최종 단계 메인 브랜치
        • Tag를 통해 버전 관리를 한다.
    • 웹 애플리케이션은 일반적으로 롤백되지 않으며, 지속적으로 서비스를 제공하기에 소프트웨어를 다양한 버전으로 지원할 필요가 없다
    • 만약 당신의 팀이 소프트웨어를 지속적으로 제공한다면 GitHub-flow와 같은 간단한 워크플로우 채택을 제안
    • 소프트웨어 버전 관리가 필요한 앱이나 솔루션, 혹은 public API에 적합한 워크플로우
    • 웹 애플리케이션에서 Git-flow는 고려할 전략이 아닙

  • 깃허브 플로우: 상시 배포 모델

    image

    • master만 둔다.
    • master는 언제든지 배포가 가능하다.
    • 새로운 프로젝트는 master를 기반으로 별도 브랜치를 생성하여 작업을 진행한다.
    • 브랜치는 로컬에 commit하고, 정기적으로 원격 브랜치에 push한다.
    • 피드백이나 도움이 필요하거나, 코드 병합할 준비가 되었다면 pull request를 만든다.
    • 다른 사람이 변경된 코드를 검토한 뒤 승인하면 master에 병합한다.
    • 병합된 master는 즉시 배포할 수 있으며, 배포 해야만 한다.

  • 깃랩 플로우: 모바일 어플리케이션 등에 적합

    image

    • Master 브랜치와 Production 브랜치 사이에 pre-production브랜치를 두어 개발 내용을 바로 반영하지 않고, 시간을 두고 반영 (앱스토어 승인 기간 고려)
    • production 브랜치에서 릴리즈된 코드가 항상 프로젝트의 최신 버전 상태를 유지할 필요가 없음
    • feature 개발 > master 병합(로컬) > pre-production테스트(테스트서버) > production 배포(배포서버)

의사결정

  • 돈이 있으면: 깃랩플로우
    • feature - develop - test - main
  • 돈이 없으면
    • feature - develop - main
    • 테스트 코드 검증을 위해 나중에 테스트 브랜치가 필요하면 넣자

이슈 템플릿

feature/ refactor / suggest

## ✅ Checklist
- [x] 완료된 항목은 체크해주세요
- [ ] 이슈 제목 작성 [FEATURE] 개발할 기능
- [ ] Assigneers, Labels, Projects, Milestone 붙여주세요

## ✏️ Description
- 설명을 작성해주세요

## 📋 TODO
- [ ] 할 일

bug

## ✅ Checklist
- [x] 완료된 항목은 체크해주세요
- [ ] 이슈 제목 작성
- [ ] Assigneers, Labels, Projects, Milestone 붙여주세요

## ✏️ Description
- 버그를 재현하려면 어떻게 해야 하는지
- 내가 한 행동 (구체적)
- 이용 환경 (os, 브라우저 등등)

## 🎯 Goal
- 정상 동작이면 어떻게 되어야 하는지

## 📋 TODO
- [ ] 할 일

PR 템플릿

참고: https://www.talater.com/open-source-templates/#/

## ✅ 체크리스트
- [ ] 테스트 코드가 잘 통과되나요?
- [ ] 이 프로젝트의 코드 스타일을 따르나요?
- [ ] 문서변경이 필요한 경우, 변경하였나요?

## 📋 변경 유형
- [ ] Bug
- [ ] Feature
- [ ] Breaking change (기존 기능을 변경하게 하는 bug 또는 feature)

## ✏️ PR 개요
- 

resolved: #이슈번호

milestone

https://applecider2020.tistory.com/27

milestone: 이슈들의 그룹화

  • 어떤 것을 milestone에 등록할까요?
  • 릴리즈 버전 (mvp, version 1.0.0, 1.0.1) 스프린트 단위 비슷.. 그 날짜까지 목표로 하는 기능들
    • 목표 달성 활동에 가까우므로 이걸로 하자
  • 대그룹 (소모임, 번개, 인증..)

브랜치명

  • 아래처럼 작성한다
  • feat/이슈이름-그대로-#13

project

  • 이슈와 연결된 칸반보드

classic: 칸반보드만 있음

new: 노션처럼 칸반보드를 테이블로도 볼 수 있고, 필터링 기능도 강화

  • 프로젝트를 릴리즈 버전마다 만들지, 계속 하나에 이어나갈지
  • 계속 한 프로젝트에 이어나가기로 한다.

전체적인 워크플로우

  1. 이슈를 만든다
  2. 이슈를 프로젝트에 등록한다
  3. 이슈에 기반한 브랜치를 만든다
  4. 개발을 한다
  5. PR을 날린다 (관련된 이슈 연결) resolved: #14
  6. 코드리뷰한다
  7. 코드 수정 → 4번으로 이동 승인 → merge
  8. 이슈를 삭제한다 (자동), 브랜치는 수동 삭제 (자동삭제 방법 알면 적용해주세요~~)

Home

기술 선택과 그 이유

  1. DB 선택
  2. API 문서 도구 선택
  3. 깃 컨벤션과 깃허브 활용 방안
  4. 사용 기술 선택

기술 공유

  1. Jacoco 세팅
Clone this wiki locally