협업을 위한 GIT 개발일지 - 3주차 (3) Git 협업 가이드

💡수업 목표💡

1. 협업을 위한 작업 관리 스킬을 익힙니다- PR과 commit 되돌리기, 임시 저장
2. 협업하기 좋은 사람이 되기 위해 기본 협업 매너를 익힙니다.
3. Github 으로 다른 사람과 소통합니다 - 내 포트폴리오, 오픈소스

 

Commit 메세지 컨벤션

잘쓰인 commit 메세지는 더 좋은 로그 가독성, 더 나은 협업과 리뷰, 더 쉬운 유지보수를 가능하게한다. 이렇게 좋은 커밋 메세지를 작성을 위해서 약간의 가이드를 commit 메세지 컨벤션이라고 한다.

👉 [참조] Chris Beams의 How to Write a Git Commit Message [번역] https://meetup.toast.com/posts/106

👉 좋은 commit을 위한 영어사전 https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

 

Commit 메세지 구조

기본적으로 commit 메시지는 제목/본문/꼬리말로 구성하고 각 파트는 빈 줄을 두어서 구분해야한다.

type: [#issueNumber - ] Subject  

body 

footer

 

Commit 타입

타입은 어떤 의도로 커밋했는지 명시하는 것이다. 타입는 영어로 쓰되 첫문자는 대문자로 한다.

뒤에 : 를 붙여서 제목과 구별되게 한다.

태그이름	설명	구분
Feat	새로운 기능을 추가할 경우	기능
Fix	버그를 고친 경우	기능
Design	CSS 등 사용자 UI 디자인 변경	기능
!BREAKING CHANGE	(ex API의 arguments, return 값의 변경, DB 테이블 변경)	기능
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우	기능
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우	개선
Refactor	프로덕션 코드 리팩토링	개선
Comment	필요한 주석 추가 및 변경	개선
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore	빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우

 

Subject 제목

제목은 코드 변경 상항에 대한 짧은 요약을 나타낸다. 한글 커밋도 좋지만 보통은 English에 최적화 된 만큼 제목은 영문으로 작성하는것이 좋다.

1. 제목은 영문 기준 50자 이내로 작성
2. 제목 첫글자를 대문자로 동사 원형으로 시작
3. 제목 끝에 . ! ? 등 특수문자 금지
4. 제목은 명령조로 개조식 구문으로 작성

 

Body 본문

본문은 선택 사항이기 때문에 모든 commit에 본문내용을 작성할 필요는 없다.

하지만 부연설명이 필요하거나 commit의 이유를 설명할 경우 작성해준다.

1. 본문은 영문 기준 72자마다 줄 바꾸기
2. 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기

 

Footer 꼬리말

꼬리말은 선택 사항이기 때문에 모든 commit에 필요하지는 않다.  issue tracker ID를 작성할때 사용한다.

• 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.
• 여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
• 이슈 트래커 유형은 다음 중 하나를 사용한다.
  • Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용
  • Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)

 

커밋 메시지로 Github 이슈(issue)를 자동 종료시키기

Github에는 커밋 메시지에 특정한 단어를 사용해 자동으로 이슈를 종료시키는 편리한 기능이 탑재되어 있다.

간단하게 이슈가 한개라면 제목을 통해서 적용할수 있고, 여러개는 꼬릿말을 통해서 적용을 할수 있다.

키워드 #이슈번호

Github가 이슈 종료로 인식하는 키워드

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

 

Example - Commit 메세지

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

 

Commit 메세지 템플릿

################
# <타입> : <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
# 예) feat : 로그인 기능 추가

# 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)

################
# 본문(구체적인 내용)을 아랫줄에 작성
# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내)

################
# 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등)
# 예) Close #7

################
# feat : 새로운 기능 추가
# fix : 버그 수정
# docs : 문서 수정
# test : 테스트 코드 추가
# refact : 코드 리팩토링
# style : 코드 의미에 영향을 주지 않는 변경사항
# chore : 빌드 부분 혹은 패키지 매니저 수정사항
################

 

Commit에서 자주 쓰는 단어

👉 좋은 commit을 위한 영어사전 https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

 

 

깃모지 Gitmoji

gitmoji란 git + emoji를 합쳐서 부르는 말로 emoji를 이용하여 commit message를 작성하는 tool이라고 보면 될 듯하다.

지금까지 그냥 글로만 커밋 메세지를 써왔지만, 메세지에 이모지(이모티콘)을 더하면, 나중에 commit 메세지를 훑어볼때 훨씬 가독성 높게 읽기가 가능해니다. 사용된 이모티콘만 보고 커밋의 목적이나 의도를 쉽게 식별할 수 있게 된다.

gitmoji

 

아이콘	코드	설명	원문
🎨	:art:	코드의 구조/형태 개선	Improve structure / format of the code.
⚡️	:zap:	성능 개선	Improve performance.
🔥	:fire:	코드/파일 삭제	Remove code or files.
🐛	:bug:	버그 수정	Fix a bug.
🚑	:ambulance:	긴급 수정	Critical hotfix.
✨	:sparkles:	새 기능	Introduce new features.
📝	:memo:	문서 추가/수정	Add or update documentation.
💄	:lipstick:	UI/스타일 파일 추가/수정	Add or update the UI and style files.
🎉	:tada:	프로젝트 시작	Begin a project.
✅	:white_check_mark:	테스트 추가/수정	Add or update tests.
🔒	:lock:	보안 이슈 수정	Fix security issues.
🔖	:bookmark:	릴리즈/버전 태그	Release / Version tags.
💚	:green_heart:	CI 빌드 수정	Fix CI Build.
📌	:pushpin:	특정 버전 의존성 고정	Pin dependencies to specific versions.
👷	:construction_worker:	CI 빌드 시스템 추가/수정	Add or update CI build system.
📈	:chart_with_upwards_trend:	분석, 추적 코드 추가/수정	Add or update analytics or track code.
♻️	:recycle:	코드 리팩토링	Refactor code.
➕	:heavy_plus_sign:	의존성 추가	Add a dependency.
➖	:heavy_minus_sign:	의존성 제거	Remove a dependency.
🔧	:wrench:	구성 파일 추가/삭제	Add or update configuration files.
🔨	:hammer:	개발 스크립트 추가/수정	Add or update development scripts.
🌐	:globe_with_meridians:	국제화/현지화	Internationalization and localization.
💩	:poop:	똥싼 코드	Write bad code that needs to be improved.
⏪	:rewind:	변경 내용 되돌리기	Revert changes.
🔀	:twisted_rightwards_arrows:	브랜치 합병	Merge branches.
📦	:package:	컴파일된 파일 추가/수정	Add or update compiled files or packages.
👽	:alien:	외부 API 변화로 인한 수정	Update code due to external API changes.
🚚	:truck:	리소스 이동, 이름 변경	Move or rename resources (e.g.: files paths routes).
📄	:page_facing_up:	라이센스 추가/수정	Add or update license.
💡	:bulb:	주석 추가/수정	Add or update comments in source code.
🍻	:beers:	술 취해서 쓴 코드	Write code drunkenly.
🗃	:card_file_box:	데이버베이스 관련 수정	Perform database related changes.
🔊	:loud_sound:	로그 추가/수정	Add or update logs.
🙈	:see_no_evil:	.gitignore 추가/수정	Add or update a .gitignore file.

 

 

 

코드리뷰 code review로 피드백 주기

코드 리뷰란 한 개발자가 코드를 작성하면 다른 개발자가 정해진 방법을 통해 점검(examining)하고, 피드백을 주는 과정을 말한다.

코드 리뷰를 통해 본인이 발견하지 못한 실수를 다른 사람이 발견하여 코드의 부작용(Side effect)과 오류를 조기에 대응할 수 있으며, 개발 내 정해진 컨벤션 규칙을 유지하고 기술 부채를 줄일 수 있다. 또한 여러 명의 개발자가 참여함으로써 문제 해결을 위한 기술 구현 방법론에 대해 공유하기도 한다.

코드리뷰가이드

👉구글의 코드 리뷰 가이드 ttps://google.github.io/eng-practices/review/ 👉[번역] https://soojin.ro/review/

 

GitHub에서 코드리뷰하기

PR을 받았다면 PR 상세페이지에서 리뷰를 시작할 수 있습니다.

• Reviewers : 리뷰를 요청할 사람들을 지정
• Assigness : 현재 PR 작업의 담당자를 지정
• Labels : 해당 작업의 성격
• Development : 어떤 작업을 했는지 이슈와 연결.

 

해당 Pull Request내의 Commits 혹은 Files changed 탭에 들어가면 코드별로 리뷰를 남길할 수 있다.

코드 줄의 맨 앞 +를 클릭하면 해당 줄 별로 리뷰를 남길 수 있다. 클릭하는 대신 드래그를 하면 여러 줄에 대한 의견도 남길 수 있다.

 

의견을 다 남겼다면 우측 상단의 Finish your review 버튼을 클릭하여 리뷰를 끝마칠 수 있다.

마지막으로 일반적인 피드백을 주는 Comment , 이제 합쳐도 괜찮을 것 같다는 Approve , 확실하게 코드를 수정하고 넘어가야 하는 경우에는 Request changes를 선택하면 된다.