Portfolio

GitHub 공유 방식

원격 레포 로컬에 클론해서 작업하기. prgrms-be-devcourse

브랜치 관련

GItFlow

main

배포용 브랜치, 항상 동작해야 한다.

develop

개발용 브랜치, 기능 개발이 끝난 feature 브랜치에 병합된다. 항상 동작해야 한다.

PR 을 통해 dev 에 반영 되는 브랜치

feature/AIR-100

기능 개발 브랜치
dev 로 부터 따온다.

refactor/AIR-100

대규모 리팩토링 용 브랜치

PR 을 통해 dev와 main 에 반영 되는 브랜치

hotfix/AIR-100

Branch Protections

GitHub Actions 브랜치 merge, push, pr 마다 제약조건을 설정해 안전하게 유지하기

checkstyle - (naver code convention 맞지 않으면 빌드 실패 → GitHub Actions 실패 →해당 pr merge 불가능)
jacoco - (test converage 0.8 넘지 않으면 빌드 실패 → GitHub Actions 실패 → 해당 pr merge 불가능)

깃 컨벤션 (더 자세히 정하기)

feat: commit message
https://gist.github.com/hyuk0309/dea61cf45bc99d9748cd7ee6b0230185

Format of the commit message


<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on github as well as in various git tools.

Subject line

Subject line contains succinct description of the change.

Allowed `<type>`

feat (feature)

fix (bug fix)

docs (documentation)

style (formatting, missing semi colons, …)

refactor

test (when adding missing tests)

chore (maintain)

config (설정)

Allowed `<scope>`

Scope could be anything specifying place of the commit change. For example $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc...

`<subject>` text

use imperative, present tense: “change” not “changed” nor “changes”

don't capitalize first letter

no dot (.) at the end

Message body

just as in use imperative, present tense: “change” not “changed” nor “changes”

includes motivation for the change and contrasts with previous behavior

http://365git.tumblr.com/post/3308646748/writing-git-commit-messages http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Message footer

Breaking changes

All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes


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.

Referencing issues

Closed bugs should be listed on a separate line in the footer prefixed with "Closes" keyword like this:


Closes #234

or in case of multiple issues:


Closes #123, #245, #992

PR, Code Review

Reviewer 수 - 2명, approved
리뷰어 선정

이슈 번호 % 4 → id

id(0) → 하하, 하니
id(1) → 하니, 제이콥
id(2) → 제이콥, 크러쉬
id(3) → 크러쉬, 하하

겹치는 경우 아래 화살표를 따라 한명 추가

하하 → 하니
하니 → 제이콥
제이콥 → 크러쉬
크러쉬 → 하니

Code Review 언제까지 완료할지 - 12h
PR 템플릿


<!-- PR 제목 양식 예시: [LO-N] 회원 기능 도메인 -->

## 🛠️ 작업 내용
-

## 🗨️ 기타
<!-- PR 포인트 혹은 궁금한 점 등등 적어주시면 됩니다. 없으시면 지워주세요 -->
- 

## 😎 리뷰어
<!-- 리뷰어를 지정했으면 지워주세요 -->
- 리뷰어 선정
    - 이슈 번호 % 4 → id
        - id(0) → 하하, 하니
        - id(1) → 하니, 제이콥
        - id(2) → 제이콥, 크러쉬
        - id(3) → 크러쉬, 하하
    - 겹치는 경우 아래 화살표를 따라 한명 추가
        - 하하 → 하니
        - 하니 → 제이콥
        - 제이콥 → 크러쉬
        - 크러쉬 → 하니

( naver XML 링크 )

Git/GitHub Convention