AngularJS에서 사용(했던) Git Commit Convention #8

gabrielyoon7 · 2023-01-12T09:06:18Z

gabrielyoon7
Jan 12, 2023
Maintainer

프로젝트와 직접적인 관련이 있는 것 같지는 않아서 Issue로 등록하기는 뭐하고,

그냥 잡담 게시판에 주저리 주저리 글을 적어봤습니다.

Git Commit Convention?

Git에서 Commit을 보낼 때 어떤 기준으로 해야 할까요?

사실 정답은 없습니다.

프로젝트마다 규칙도 다르고, 반드시 따라야 하는 명확한 기준이 없기 때문입니다.

다음은 Angular JS에서 정의한 Git commit 규약으로, 전세계에서 가장 범용적으로 사용되는 commit 규칙 중 하나 이니 참고해보시길 바랍니다.

AngularJS Git Commit Message Conventions

사용했던 이라고 강조한 이유는 일부 표기법이 더 세분화되었기 때문인데, 아직도 많은 사람들이 위 규칙을 따르고 있어 소개해봅니다.

*CS-HOME에 이 규칙을 반드시 적용하라는 의미는 절대 아닙니다. 모든 판단은 여러분이 스스로 하시면 됩니다.
이후에 여러분들이 진행하는 프로젝트에서 사용할 법한 유용한 문서를 소개 해드리는 것 입니다.

위 글에서 중요한 부분을 번역 및 첨언 하여 아래에 소개해드리겠습니다.

Commit Message를 작성하는 법

Commit Message 양식

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

커밋 메시지는 *1줄*에 100글자를 넘을 수 없습니다.

헤더

`<type>` 자리에 올 수 있는 것

feat (기능)
fix (버그 수정)
docs (문서 작업. readme 등)
style (포맷 수정. 단순한 세미콜론 추가, 띄어쓰기 정렬 등)
refactor (수행하는 기능은 변경이 없으나, 새로운 로직으로 개선한 경우. jQuery Ajax에 관하여 #6 가 여기에 해당)
test (테스트 케이스 추가)
chore (프로젝트 유지 및 환경 설정 관련 CSS & JS 라이브러리 코드 중복 #7 이 여기에 해당되는 내용일 것이겠죠?)

`<scope>` 자리에 올 수 있는 것

commit 위치를 지정하는 모든 것이 될 수 있습니다.
어떤 commit인지 더욱 강조할 때 쓴다고 생각하시면 됩니다.
예를 들면 $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc... 과 같이 특정 기능이나 위치의 커밋임을 강조합니다.

단, 이 부분은 선택사항 입니다. 적지 않아도 됩니다. 프로젝트마다 규칙이 다를 수 있습니다.

`<subject>` 자리에 올 수 있는 것

명령형과 현재 시제로 구성된 문장을 씁니다.

update readme.md (O)
updates readme.md (X)
updated readme.md (X)
기능 목록 최신화 (O)
기능 목록 최신화했음 (X)
기능 목록 최신화. (X)

.으로 끝나지 않습니다.
첫 글자를 반드시 소문자로 적습니다.

특히 첫 제목은 한 줄로 누구나 알아보기 쉽게 간결하게 적습니다.
그래야 나중에 commit 이력을 분석할 때 유용합니다.

본문

`<body>` 자리에 올 수 있는 것

이 곳도 마찬가지로 명령형과 현재 시제로 구성된 문장을 씁니다.
여기서 부터 작성되는 내용은 github의 commit history에서 ...으로 요약되는 부분입니다. 즉, 한 눈에 보이지 않으므로 부가 설명을 작성하는 곳이라고 생각하시면 됩니다.
저는 보통 이 곳에 목록형으로 작성합니다.
왜 이런 커밋이 일어났는지 이유를 서술하곤 합니다. (변경 이유, 동기, 변경사항 등)
단, 이 부분은 선택사항 입니다. 적지 않아도 됩니다. 프로젝트마다 규칙이 다를 수 있습니다.

바닥

BREAKING CHANGE

변경 사항이 중대한 경우에 표기합니다.

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.

예를 들면, 어떤 기능이 굉장히 범용적으로 사용되고 있는데, 갑자기 수정해야 하는 경우에는 위와 같이 표기합니다.
물론 이렇게 하는 이유는 다른 사람들의 혼동을 줄이기 위함입니다.

단, 이 부분은 선택사항 입니다. 적지 않아도 됩니다. 프로젝트마다 규칙이 다를 수 있습니다.

Commit Message 예제

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)

fix($compile): couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Closes #392
Breaks foo.bar api, foo.baz should be used instead

feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected

New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.

Closes #351

style($location): add couple of missing semi colons

docs(guide): updated fixed docs from Google Docs

Couple of typos fixed:
- indentation
- batchLogbatchLog -> batchLog
- start periodic checking
- missing brace

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.

Commit의 단위?

제가 듣기로는 이번 8기는 Commit을 일주일에 2번 이상 해야 한다고 들었는데, 사실 Commit은 여러분이 생각하는 것 보다 더 잘게 쪼개서 해야 합니다.

그 이유에 대해서는 후술하겠지만, 간단히 말하자면 Commit 이력만 보고도 여러분이 무슨 짓을 했는지 다른 사람들이 알 수 있어야 합니다.

보통은 기능 단위로 잘게 쪼개서 Commit을 날리며, Commit을 날릴 때마다 Commit Message를 같이 작성합니다.

기능의 단위는 어떻게 정의할 수 있을까요? 또, 어떻게 기능을 잘게 쪼갤 수 있을까요?

예를 들면 로그인 기능을 구현해야 한다고 가정할 때, 대부분의 사람들이 이렇게 Commit을 날릴 것입니다.

feat: 로그인 기능 구현

이 Commit Message가 궁금해진 다른 사람이 해당 변경 사항(코드)을 조회해봅니다.

변경된 코드를 보니

로그인 하는 HTML를 작성하고,
input태그로 부터 읽는 함수를 만들고,
읽어낸 아이디와 비밀번호를 서버로 전달하는 함수를 만들고,
되돌아 오는 결론에 따라서 로그인 처리를 해줄지 말지를 결정하는 코드

가 작성되어있습니다.

하지만, 기능 단위로 Commit을 날린다면 다음과 같이 날릴 수 있을 것입니다.

위에 구현된 변경 코드들을 다 쪼개서 Commit하면 됩니다.

feat: 로그인 정보를 받아 줄 Input 태그 구현

feat: Input 태그로 부터 아이디와 비밀번호를 읽는 기능 구현

feat: 아이디와 비밀번호를 서버로 전달하는 기능 구현

feat: 서버로 부터 반환 받은 로그인 결과 처리 구현

벌써 4개의 Commit이 작성되었습니다.

만약에 작업하면서 수정할 사항이 생긴다면

refactor: 아이디와 비밀번호를 서버로 전달할 때 fetch가 아닌 axios를 사용

fix: 서버로 부터 반환받을 때 발생하는 오류 수정

이런식으로 더 많은 Commit이 발생할 것입니다.

근데 왜 이렇게 잘게 쪼개야 하냐구요?

사람들이 Commit Message를 이렇게 관리하는 이유

여러분이 지금 IntelliJ에서 작업하시면서 터미널을 직접 조작하실 일이 거의 없겠지만,

작업하시는 폴더를 CMD에서 접근하신 후, 다음과 같은 명령어를 입력하시면 이유를 간접적으로 아실 수 있습니다.

git log <last release> HEAD --grep feat

(last release는 최신 커밋 고유 번호를 입력하시면 될 것입니다)

이런식으로 입력을 해보시면 CMD창에 여러분이 입력하셨던 커밋 중, feat에 해당하는 커밋 만 모아볼 수 있습니다.

즉, 누가 어떤 기능 작업을 했는지 더욱 세밀하고 명확하고 책임을 줄 수 있다는 의미 입니다.

어떤 커밋에서 어떤 코드가 수정되었는지 더욱 정확하게 알 수 있게 됩니다.

커밋 이력을 볼 때 훨씬 깔끔하게 정리해서 조회를 할 수 있습니다.

결정적으로, 이 프로젝트에서 사용할 일은 없겠지만, 스크립트로 CHANGELOG.md를 생성하는 기능에도 활용할 수 있습니다.

여러분이 어떤 변경을 했을 때 변경 사항을 자동으로 마크다운으로 정리하여 패치 내역을 만들 수도 있다는 것 입니다.

결국 이 것도 사람이 하는 일이기에, 협업을 자동화 하기 위해서 등장한 기술임을 잊지 않으시면

왜 git의 commit을 이렇게 까지 규약을 만들어가면서 지키시는지 알 수 있을 것입니다.

방금 설명드린 git에 대해서 더 많은 정보를 알고 싶으시다면 이 글에서 참고하시면 됩니다.

커밋 메시지 분리를 위한 팁

여러분이 작업하시는 프로젝트에 docs 폴더를 하나 추가하시고, 기능 목록을 관리할 md 파일을 하나 추가해보세요.

이 파일은 기능 목록을 관리하는 파일로, 특정 기능을 구현하기 전에 계획하거나 수행 여부 등을 기록하는 곳 입니다.

예를 들면

로그인 기능

로그인 정보를 받아 줄 Input 태그 구현

Input 태그로 부터 아이디와 비밀번호를 읽는 기능 구현

아이디와 비밀번호를 서버로 전달하는 기능 구현

서버로 부터 반환 받은 로그인 결과 처리 구현

과 같이 체크를 하면서 하면 해야할 일의 계획과 기록을 다같이 할 수 있을 것입니다.

(체크 안된 마크 다운은 -[ ] 입니다.)
(체크 된 마크 다운은 -[x] 입니다.)

이만 글을 마치겠습니다.

긴 글 읽어주셔서 감사합니다.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CS-HOME

AngularJS에서 사용(했던) Git Commit Convention #8

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 0 comments

Select a reply

CS-HOME

AngularJS에서 사용(했던) Git Commit Convention #8

gabrielyoon7 Jan 12, 2023 Maintainer

Git Commit Convention?

Commit Message를 작성하는 법

Commit Message 양식

헤더

<type> 자리에 올 수 있는 것

<scope> 자리에 올 수 있는 것

<subject> 자리에 올 수 있는 것

본문

<body> 자리에 올 수 있는 것

바닥

BREAKING CHANGE

Commit Message 예제

Commit의 단위?

사람들이 Commit Message를 이렇게 관리하는 이유

커밋 메시지 분리를 위한 팁

Replies: 0 comments

gabrielyoon7
Jan 12, 2023
Maintainer

`<type>` 자리에 올 수 있는 것

`<scope>` 자리에 올 수 있는 것

`<subject>` 자리에 올 수 있는 것

`<body>` 자리에 올 수 있는 것