컨벤션(Convention)이란?

(...in 위키백과)

컨벤션(convention)이란 용어는 cum이라는 라틴어(together를 의미)에서 con과, 라틴어 venire(to come의 의미)에서 vene이라는 말에서 유래한 것으로 '함께 와서 모이고 참석하다'의 의미를 가지고 있다. 즉 컨벤션이란 다수의 사람들이 특정한 활동을 하거나 협의하기 위해 한 장소에 모이는 회의(meeting)와 같은 의미라 할 수 있으며 전시회를 포함하는 좀 더 포괄적인 의미로 쓰이기도 한다. 콘퍼런스(Conference)라고도 한다.

 

그렇다면, 개발 컨벤션이란 뭘까?

개발 컨벤션은 코드 작성 시 지켜야 할 규칙과 스타일을 정의한 것!!

 

개발 컨벤션, 즉 개발 규칙은 개발자들끼리 원활한 협업을 하기 위한 중요한 규칙이다.

개발자들마다 코드 스타일이 제각각인데, 서로의 코드를 클린하게 이해하기 위해서는 필수적인 요소이다.

혹은, 본인이 작성한 코드더라도 오랜만에 그 코드를 까봤을 때 낯설게 느껴지는 경우도 많다.

 

개발 컨벤션은, 개발에 `이름표(식별표)`를 붙이는 것이나 다름없다!

 

그 중, 커밋 메시지에 대한 컨벤션을 포스팅해보려 한다.

 

커밋 메시지 컨벤션의 구조

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • type: 이 커밋이 어떤 목적의 변경인지
  • scope (선택): 어떤 파일/모듈/기능 범위인지
  • subject: 한 줄 요약
  • body (선택): 상세 설명 (무엇을 왜 바꿨는지)
  • footer (선택): 관련된 이슈나 breaking change 정보

 

1. 커밋 Title

커밋 타이틀은 `type : Subject` 의 형식을 따른다.

Type은 영어로 쓰되, 첫문자는 대문자로 한다.

Subject는 최대 50문자를 넘기지 않으며, 특수문자를 사용하지 않는다. 동사는 원형으로만 작성한다.

// 대표적인 Type 의 종류

feat	 새로운 기능 추가
fix	 버그 수정
docs	 문서 수정 (코드 변경 X)
style	 포맷, 세미콜론, 들여쓰기 등 순수 스타일 변경
refactor	 리팩토링 (기능 변화 없음)
test	 테스트 코드 추가/수정
chore	 빌드, 설정, 라이브러리 등 변경
perf	 성능 개선
build	 빌드 시스템 또는 외부 종속성 변경
ci	 CI 관련 설정 변경 (GitHub Actions, Jenkins 등)

 

2. 커밋 Body

본문의 경우 한줄당 72자 내로, 양에 구애받기보다는 최대한 상세히 적도록 해야한다.

How 보다는 What 과 Why 에 초점을 맞춰서 작성해야 한다.

(즉, 코드 자체를 설명하기보단, 어떤 요구사항에 의해 개발한건지, 어떤 버그에 의해 수정된건지 작성한다.)

 

3. 커밋 Footer

꼬리말은 선택사항이다.

이슈 트래커 ID를 작성할 수 있다. 이슈트래커 ID는 `#이슈 번호` 형식으로 작성한다.

`유형:#이슈 번호` 의 형식으로 작성하는데, 유형은 다음과 같다.

 

이슈 트래커 유형은 다음 중 하나를 사용한다.

  • Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용
  • Related to: 해당 커밋에 관련된 이슈번호(아직 해결되지 않은 경우)
  • (ex) Fixes: #45 Related to: #34, #23

 

사용 예시

// 가장 기본적인 커밋
feat: 로그인 버튼 클릭 시 로그인 API 연동



// 기능 범위를 포함한 커밋
fix(login): 토큰 저장 오류 수정



// 본문과 이슈 연결까지 포함한 커밋

// 한 줄 요약 + 상세 설명 + 관련 이슈 연결
// GitHub PR이나 이슈에서 자동으로 #42 이슈를 닫아줌
feat(account): 비밀번호 변경 기능 추가

- 기존 API 명세에 따라 변경 요청 및 확인 로직 구현
- 버튼 클릭 시 확인 팝업 추가

Closes #42

 

 

커밋 메시지에 이모지를 사용할 수도 있다?!

https://gitmoji.dev/

 

gitmoji

:truck: Move or rename resources (e.g.: files, paths, routes).

gitmoji.dev

다음 사이트는 여러 이모지를 제공하는데, 이 이모지들은 커밋 메시지에서 사용이 가능하다! (!)

문자보다 더 직관적이게! 이모지로 커밋메시지의 타입을 구분할 수 있는 것이다!!!

 

깃 이모지 사용법에 대해서는 다음 블로그를 참고해보자. (너무 잘 정리되어 있다...)

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-Gitmoji-%EC%82%AC%EC%9A%A9%EB%B2%95-Gitmoji-cli

 

⚡️ Gitmoji 사용법 정리 (+ 깃모지 툴 소개)

Gitmoji 란? gitmoji란 git + emoji를 합쳐서 부르는 말로 emoji를 이용하여 commit message를 작성하는 tool이라고 보면 될 듯하다. 지금까지 그냥 글로만 커밋 메세지를 써왔겠지만, 메세지에 이모지(이모티

inpa.tistory.com

 

 

 

 

 

그외 참고 블로그

https://m.blog.naver.com/so_no7/223507064379

 

GraduART [트러블 슈팅(1)] - 협업 시 개발 컨벤션 정리하기(코드, 커밋, PR, Git 브랜치 전략)

오늘은 GraduART 팀프로젝트에서 개발을 진행하기 전에 개발 컨벤션에 대해 고민했던 부분들을 정리하...

blog.naver.com

 

git fetch 와 git pull 의 차이점은?

 

 

fetch 의 경우

나의 로컬 HEAD 에 원격저장소의 변경내용을 붙여주는 형식으로 가져오게 된다.

 

 

 

pull 의 경우

나의 로컬 HEAD 와 원격저장소의 변경내용을 merge를 동시에 하면서 가져오게 된다.

0. 사건의 발생

원격저장소에서, 그리고 내 로컬저장소에서 둘다 같은 파일을 수정하게 되었다.

이러한 상황에서 내가 푸시를 하게 된다면 어떻게 될까?

그렇다! 컨플릭트가 발생할 것이다!

같은 파일을 수정했는데 각자 수정한 내용이 달랐기 때문이다.

이런 상황에서 해결할 수 있는 방법 몇 가지를 소개하고자 한다.

 

1. 원격저장소의 내용은 무시해버리기

// 강제로 내 로컬저장소의 내용만을 남기는 방법이다.
// -f 는 force 의 약자인 옵션이다.
git push -f

 

2. merge 처럼 처리하기

mergetool 을 이용하여 conflict 난 부분을 수정해주는 방법

 

3. 애초에 원격저장소에서 내 로컬로 pull 할시에 rebase 이용하기

git pull --rebase

위와 같은 명령어를 실행하게 되면 원격저장소에서 내 로컬로 파일을 가져올 때,

원격저장소에 내 현재 HEAD 커밋을 붙여주는 형식으로 가져오게 된다.

conflict 를 해결해주고 나면, merge로 처리했을 때처럼 지저분하지 않고, 깔끔하게 push를 진행할 수 있다.

0. 질문의 발생

어느정도 깃허브를 사용할 줄 알게 되면, 이제 궁금증이 생기게 된다.

그냥 습관적으로 사용하던 push 에서 origin 은 도대체 왜 붙이는 거지?

git repository 에 존재하는 master branch 에 push 하는 명령어인건 알겠는데, origin 은 뭐지?

 

 

 

1. origin 의 정체

origin 은 바로 (어느정도는 눈치챘듯이) 원격저장소의 이름이다!

그러나 왜 origin 으로 이름을 지정하였는가 하면 통상적으로 첫 주인의 원격저장소는 그렇게 지정하기 때문이다.

 

 

 

2. 그렇다면, 다른 원격저장소도 추가할 수 있는 건가?

그렇다.

 

 

2-1. 현재 연결되어있는 원격저장소 확인하기

// 연결된 원격저장소의 목록을 확인할 수 있는 명령어
git remote

// 연결된 원격저장소의 주소까지 확인할 수 있는 명령어
git remote -v

 

 

 

2-2. 연결시킬 원격저장소 추가하기

git remote add (원격저장소명) (원격저장소url)

새로운 원격저장소 명을 만약에 server 로 하게 된다면,

이후에 git remote 명령어를 실행했을 때 실행결과는 다음과 같이 나올 것이다.

> git remote

origin
server

 

 

 

3. 특정 원격저장소의 정보를 더 자세하게 조회하는 방법

git remote show (원격저장소명)

// 예시
git remote show origin

0. 전통적인 방법

// 수동적 방법 : 해당 파일 직접 열어서 수정해주기
open (컨플릭트난 파일)

 

1. visual studio code 이용하기

// git config 파일에 다음과 같은 코드를 추가해준다.
[merge]
	tool = vscode
[mergetool "vscode"]
	cmd = code --wait $MERGED

다음과 같은 명령어를 실행하면 vscode 가 자동적으로 실행되면서

수정할 수 있는 창이 뜬다.

git mergetool

 

 

2. p4merge 툴 이용하기

>> 현업 개발자들이 많이 사용하는 p4merge 툴 다운받는 링크
https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge

// git config 파일에 다음과 같은 코드를 추가해준다.
[merge]
	tool = p4merge
[mergetool "p4merge"]
	path = C:/Program Files/Perforce/p4merge.exe
[mergetool]
	prompt = false

다음과 같은 명령어를 실행하면 p4merge 가 자동적으로 실행되면서

수정할 수 있는 창이 뜬다.

git mergetool

 

0. git switch/restore 명령어 탄생배경

그 이유는 하나의 명령어인 checkout 이 가진 기능이 너무 많기 때문이다.

더 명확한 명령을 위해서 명령이 세분화 되게 되었다.

 

1. git switch

깃 브랜치 전환하기

// 특정 브랜치로 이동하기
git checkout (브랜치명)
git switch (브랜치명)

// 특정 브랜치를 생성한 다음 이동하기
git checkout -b (브랜치명)
git switch -C (브랜치명)

 

 

2. git restore

작업 중인 파일을 복원하기

// 특정 파일의 변경사항 되돌리기
git checkout -- (특정 파일)
git restore (특정 파일)

// stage에 이미 넣은 내용 되돌리기
git reset HEAD (특정 파일)
git restore --staged (특정 파일)

 

0. git tag 란?

말그대로 특정 중요한 커밋에다가 책갈피를 추가한다고 생각하면 된다.

실제 협업에서는 프로젝트가 릴리즈된다던가 하는 중요한 사건이 일어날 때 이 tag 를 추가한다.

 

1. git tag 의 일반적인 format

major 버전 : 특정한 크고 전체적인 기능이 추가되었을 때

minor 버전 : 세부적인 기능이 추가되었을 때

fix 버전 : 특정 기능의 오류를 수정했을 때

 

2. 현재 상주하고 있는 커밋에 tag 다는 방법

git tag (태그명)


3. 특정 커밋에 tag 다는 방법

git tag (태그명) (특정 커밋의 해쉬코드)

// 예시
git tag v1.0.0 (해쉬코드)

 

 

4. tag 에 메시지 추가하기

git tag (태그명) (해쉬코드) -am "Release note ..."

-a 옵션 : annotate 의 약자로써 해당 해쉬코드를 가진 태그에 정보를 추가하겠다는 의미이다.

-m 옵션 : 메시지를 추가하겠다는 옵션이다.

 

 

5. 내가 만든 tag 확인하기

// 모든 태그 확인
git tag

// 특정 태그 확인 예시
git tag -l "v1.0.*"

 

 

6. 태그 삭제하기

git tag -d (태그명)

 

 

7. 태그를 이용해서 커밋 이동하기

git checkout (태그명)
// 그렇다. 브랜치 이동과 동일하다.

// tag 를 checkout 하면서 새로운 브랜치 부여하기
git checkout -b (브랜치명) (태그명)

 

 

 

8. 태그 푸시하기

git push origin (태그명)

// 생성한 모든 태그 한꺼번에 푸시하기
git push origin --tags

// 원격 저장소의 특정 태그 삭제하기
git push origin --delete (태그명)

0. git log 명령어 기본 형태

git log

// 결과화면

 

 

 

 

 

 

1. git log 에 옵션 넣어서 다양한 형태로 로그 출력하기

 

-p 혹은 --patch 옵션

git log --patch
// 혹은
git log -p

// 결과화면

p 옵션을 사용하면 파일을 어떻게 수정했는지에 대한 세부 내용까지 보여준다.

 

 

--oneline 옵션 (그리고 --reverse 옵션)

git log --oneline

 

한 커밋당 한 줄씩 간단하게 볼 수 있다.

가장 최근 커밋부터 출력이 된다.

 

git log --oneline --reverse

--reverse 옵션까지 추가하면, 가장 처음 커밋부터 역사 순서대로 출력이 된다.

 

 

 

그 외 자주 쓰이는 다양한 옵션들

// 가장 최근 커밋 중에서 3개만 뽑아서 확인한다.
git log -3

// 커밋을 작성한 사람이 jinn_o 인것만 뽑아서 확인한다.
git log --author="jinn_o"

// 커밋 작성 시점이 2021년 7월 9일 이전의 것만 확인한다.
git log --before="2021-07-09"

// 커밋 메세지에 "hello" 라는 문자열이 포함된 것만 확인한다.
git log --grep="hello"

// 커밋한 코드 안에 "hello" 라는 문자열이 포함된 것만 확인한다. (-p를 넣으면 코드까지 확인가능)
git log -S --grep="hello" -p

// 현재 상주하고 있는 커밋의 2번째 부모의 로그를 확인한다.
git log HEAD~2

// 특정 커밋의 내용만을 확인하고 싶을 때
git show (해쉬코드)

// 특정 커밋의 내용 중 특정 파일의 내용만 확인하고 싶을 때
git show (해쉬코드):(특정파일명)

// 특정 브랜치들 사이의 변경 사항만 확인하고 싶을 때
git log (시작 브랜치의 해쉬코드)..(끝 브랜치의 해쉬코드)

 

 

 

 

 

2. git log 포매팅하기 (git log 를 내 마음대로 이쁘게 만들기) feat. 정규표현식

>> git log formatting 공식문서 (중간쯤 스크롤을 내려야 나온다.)
https://www.git-scm.com/docs/git-log
// 사용 예시
git log --pretty=format:"%h %an %ar %s"

%h : 해쉬코드

%an : 누가 커밋했는지

%ar : 커밋된 시간

%s : 커밋 내용

( 더 많은 %옵션들에 관해서는 공식 문서에 자세히 설명이 되어있다. )

 

 

 

 

 

 

3. git log graph 로 가시적으로 branch 로그 보기

git log --oneline --graph --all

 

 

 

 

 

 

4. alias 설정해서 정규표현식을 이용하여 내 입맛에 맞게 log 명령어 만들기

// 예시 코드 (정규식)
git log --graph --all --pretty=format:"%C(yellow)[%ad]%C(reset) %C(green)[%h]%C(reset) | %C(white)%s %C(bold red){{%an}}%C(reset) %C(blue)%d%C(reset)" --date=short

이 명령을 일일히 매번 다 적을 수는 없기 때문에 명령어 alias 를 이용하여 명령 별칭을 따로 만들면, 한번 이쁘게 만들어놓은 명령어를 계속해서 가져다가 사용할 수 있다.

 

 

 

 

 

 

5. Source Tree 로 로그 확인하기 (히스토리 메뉴)

git diff 기본 명령어

git diff

 

// 결과 화면

a/ => 변경 이전 파일을 의미한다.

b/ => 변경 이후 파일을 의미한다.

 

index 번호는 커밋의 고유 해쉬코드를 의미한다.

 

-1,5 의 의미는 첫번째 줄부터 시작해서 5개의 라인을 보여준다는 의미인데,

빨간색으로 표시되어 있는 라인에 있는 코드가 삭제(-) 되었다는 것을 의미한다.

+1,5 의 의미는 첫번째 줄부터 시작해서 5개의 라인을 보여준다는 의미인데,

초록색으로 표시되어 있는 라인에 있는 코드가 추가(+) 되었다는 것을 의미한다.

 

 

 

git diff 명령을 좀 더 가시적으로 활용하기 (VSCode 활용)

>> VS Code 를 활용해서 git config 파일을 edit 하는법 (git config 에 대해서 알아보자.)
https://jinn-o.tistory.com/35
// 먼저 VSCode를 활용해서 git confing 파일을 열어준다.
git config --global -e

// git config 파일 안에 다음과 같은 코드를 작성해준다.
[diff]
	tool = vscode
[difftool "vscode"]
	cmd = code --wait --difftool $LOCAL $REMOTE

 

코드를 작성해 주었다면, 그 다음부터는 git difftool 명령어를 사용할 때, 자동으로 vs code가 실행된다.

// git difftool 결과화면

y 를 입력하고 엔터를 누르면 VS Code 가 자동으로 실행된다.

 

// VS Code 실행화면

파란색으로 라인이 그어져있는 줄이 변경된 줄이다.

좀더 가시적으로 파일 변경 내용을 확인할 수 있다.

git add .  VS git add * 의 차이

git add . 의 경우 .gitignore를 고려해서 무시할 파일들은 무시하고 add 명령어를 수행한다.

반면 git add * 의 경우 .gitignore를 고려하지 않고 모든 파일들에 대해 add 명령어를 수행한다.

 

git ignore가 뭔데?

git 이 tracking 하지 않았으면 좋겠는 파일들의 목록을 작성한 파일이다.

말그대로 ignore 의 목록에 해당되는 파일들은 "무시"하라는 것이다.

보통 이 목록에 추가되는 파일들은 개인정보나 기밀 파일들이 주로 포함되는 경향이 있다.

 

git ignore 사용 예제

// git ignore 파일 내부

// 추가하고 싶지 않은 특정 파일 확장자
*.(확장자_이름)
// 예시
*.css

// 추가하고 싶지 않은 특정 폴더
(폴더명)/
// 예시
build/

// 추가하고 싶지 않은 특정 폴더에 들어있는 특정 확장자 파일들
(폴더명)/*.(확장자_이름)
//예시
bulid/*.css

 

git ignore 의 몇 가지 패턴 정리

# (주석) # 주석에 해당하는 줄은 적용되지 않는다.
* (와일드 카드) *.css 처럼 쓰이며 css 파일은 모두 무시한다.
! (무시를 무시) *.css 적용 후에 !style.css 를 사용하면, 모든 css 파일은 무시하기로 했지만 style.css 파일만 예외적으로 무시하지 않음을 의미한다.
/ (path를 표기) /build 라고 작성하면 루트 디렉토리 아래에 있는 build 폴더를 무시한다.
build/ 라고 작성하면 build 디렉토리 아래에 있는 모든 파일들을 무시한다.
build/*.css 라고 작성하면 build 디렉토리 아래에 있는 css 파일들만을 모두 무시한다.

 

스테이지에 올라간 모든 파일들을 다시 취소하는 방법

git rm --chached

 

 

+ Recent posts