[프로젝트 방법론] 프로젝트 시작할 때 팀원들과 맞춰야 하는 몇 가지(feat. git, github, 애자일, Agile)

개발자를 희망하는 사람으로서 프로젝트를 진행하게 될 일이 굉장히 많았다. 그러나 많은 경험에 비해 매번 아쉬웠던 점들이 많았는데 특히나 이 프로젝트를 기획하는 단계와 시작 단계에서 어떤 규약을 정하지 않았던 것이 가장 컸던 것 같다. 

 

그래서 이번 포스팅에서는 프로젝트를 시작할 때 팀원들과 고려해야할 점들과 그에 대한 상세한 설명을 정리하여 두고두고 보면서 적용할 수 있는 나만의 가이드라인을 만들어보려 한다.

 

요구사항을 구현하는 데 도움이 되는 각종 문서 작업이 이루어지는데 이 과정이 어떻게 진행되는지 세부적으로 알아볼 것이다.

 

임의의 프로젝트인 게시판 서비스 만들기라는 목표를 가지고 여러 준비 과정들에 대해서 적용할 것이다.

 

 

0. 주제 정하기 (+개발 목적 이해하기, 마인드 세팅)

프로젝트의 시작은 당연히 주제 정하기이다.

 

그 이후의 과정은 이 프로젝트 성격에 맞는 것들로 구성을 해야 진행하기가 편해진다.

 

주제가 이미 정해져 있는 프로젝트도 있을 것이고 그렇지 않은 프로젝트도 있을 것인데 여기서 이에 대해 자세한 사항은 다루지 않도록 할 것이다.

 

한 가지 중요한 점은 주제를 팀원과 한번 정하고 나서 조금의 피벗(pivot, 아이디어를 바꾸는 작업)을 진행하는 것은 좋은데 너무 많이 바꾸다보면 점점 갈팡질팡하게 되고 일정에 지연이 생기기 마련이었다. 그렇기 때문에 정한 주제에 확신을 갖고 쭉 밀어붙이다가 그 위에 추가적인 기능을 얹는 것이 좋을 것 같다.

 

물론 이는 정해진 기간 내에 완수해야 하는 프로젝트에 대해서만 해당하고 무기한이라면 마음에 드는 아이디어가 나올 때까지 주제를 생각해도 상관은 없다.

 

개발의 목적 - 고객의 문제를 해결 (+하는 과정을 공부)

취업을 준비하는 입장에서 프로젝트를 임할 때 마인드는 가상의 고객을 두고 해당 고객의 문제를 해결한다는 방향으로 가야 한다.

 

첫번째로 고객의 니즈와 문제를 정리를 해야할 것이다.

고객이 원치 않거나 고객의 문제를 해결해줄 수 없는 개발은 의미가 없다. 공부가 목표인 프로젝트인만큼 실패가 용인되기 때문에 실제 현업에 투입되기 전에 미리 자유롭게 연습을 해 보는 것이 좋을 것이다.

 

이렇게 해서 고객의 니즈를 정리하면 문제로부터 요구사항이 나올 것이고 이 요구사항을 하나하나 구체적으로 단위 기능(feature)로 도출하여 이 기능을 어떻게 구현해 낼 것인지 기획을 한 후에 개발 계획을 수립하고 이를 실제로 개발을 실행하는 프로세스로 진행이 된다.

 

보통 프로젝트 특성에 따라 기술 스택을 정하기도 하는데 각자 본인이 하고 싶거나 이미 공부해 온 기술 스택을 쓰기 때문에 어느 정도의 제약 사항은 있으나 해당 기술에 대해 프로젝트 경험을 쌓는 것이 중요한 것이기 때문에 크게 신경쓰지는 않아도 된다.

 

1. 기술 스택 및 개발 환경 잡기

실제 프로젝트에 들어가면 백엔드, 프론트엔드, AI 등 여러 업무에 따라 나뉘어 개발에 들어갈 것이다.

 

프로젝트 주제를 정했다면 가장 먼저 해야 할 일은 물론 프로젝트 개발을 할 기술 스택과 해당 기술에 대해 각각의 개발 환경을 구축하는 일이다.

 

실제 프로젝트 시에 사용했던 기술 스택

 

 

개발도구:

개발 도구로는 보통 IDE라고 말하는 것들이며 vscode, Intellij IDEA Ultimate 2022.1, eclipse 등이 있다.

 

---

 

 

소스 코드 관리(형상 관리 툴):

소스 코드 관리는 대부분 Git 이라는 것을 사용하며, 나는 현재 기준 2.36.1 버전을 사용한 이력이 있다.

기존에 우리가 문서를 작업한다고 하면 그 문서는 보통 항상 최종 버전의 모습이 보여지기 마련이다. 그런데 이 중간 단계 편집 과정을 기록, 기억하고 싶은 개발자들의 니즈가 있었고 이런 니즈에 따라 만들어진 것이 바로 git이다.

 

git을 통해 중간에 어떤 편집 지점으로든 이동하여 다시 열람해 볼 수 있고 원한다면 최신 상태를 그 지점으로 바꾸는 것도 가능하며 변경사항과 변경사항 사이의 차이점을 쉽게 비교해 볼 수도 있다.

 

https://git-scm.com/

---

 

Git 호스팅:

이렇게 git을 통해 형상 관리를 하다보면 그 내용은 로컬 컴퓨터에 저장이 되어 있을 것인데 이 정보를 같이 협업하는 개발자들과 공유하기 위해서는 해당 내용이 인터넷에도 같이 올라가 있으면 좋을 것이다.

 

그래서 인터넷에 올리기 위한 호스팅 컴퓨터가 필요한데 이렇게 git을 호스팅 해 주는 기업에는 여러가지(Github, Gitlab, Bitbucket...)가 존재하지만 일반적으로 Github을 많이 사용한다.

 

 

협업에서 github 사용은 그 프로젝트가 얼마나 꼼꼼하고 세세하게 진행했는지 한 눈에 볼 수 있으며 실제로 면접 때 본인의 github 주소를 달아놓기도 한다.

 

그래서 이 이후에 내용도 github로 어떻게 하면 프로젝트를 효율적이고 그럴 듯하게 할 수 있을 지에 대한 것들이다.

 

 

---

 

Git GUI:

Git은 커맨드 기반(CLI, Command Line Interface)이기 때문에 아무래도 초보자들이 사용하기에 어렵고 git에 익숙한 사람이 쓰더라도 규모가 커질수록 눈에 보이는 GUI(Graphic User Interface) 기반의 git 프로그램을 선호한다.

git GUI에는 SourceTree(무료), GitKraken(유료 시 기능 추가) 등이 있다.

 

 

+ 테스트와 배포 - 고객에게 제품을 보여주고 성과를 확인하는 순간

개발 계획을 세웠던 요구사항이 모두 구현되었는가, 구현된 요구사항이 오류없이 동작하는가를 확인하기 위해서 테스트를 진행하고 이 테스트를 어떻게 할 것인지도 생각을 해 놔야 할 것이다.

 

실제로 배포를 진행할 때도 깃헙 릴리즈를 작성하고 클라우드 서버에 배포(헤로쿠, AWS, Azure)하는 등 여러가지 고려해야 할 점들이 많기 때문에 이를 미리 생각해 놓는 것도 나쁘지 않은 작업이다.

 

 

---

2. 다양한 형태의 문서 작업

다양한 형태의 문서 작업은 곧 원활한 협업의 초석이다.

 

우리는 문서를 통해 개발할 프로젝트의 목적, 내용, 진행상황을 공유하는데 무엇보다 왜 하는지가 특히 더 중요하다고 할 수 있다.

 

• 무엇을, 어떻게: 업무의 가이드. 동료의 생산성을 높여줌
• 왜: 함께 움직이는 원동력, 동료가 더 나은 방법을 제안하거나, 내 생각의 오류를 잡아줌

내용이 구체적일 수록, 동료들의 프로젝트 개발 내용이 잘 동기화되고 진행이 막히지 않을 것이다.

 

다만 주의해야 할 점은 과도한 정보의 범람이나 업데이트되지 않았거나 잘못된 정보가 주는 혼란인데 이 역시 체계적이고 미리 팀원들과 말을 맞추어 최소한으로 되게끔 할 수 있다.

또한 체계적인 문서 작업은 백업이 용이한데 문서는 지나간 일을 다시 꺼내야 할 때 쉽게 찾게 도와주기 때문이다. 기억은 짧고 왜곡되지만, 문서는 수정 가능하고 발전하며 오래 가는 것을 명심하자.

'왜'라는 것을 생각해야 하는 이유가 나중에 해당 문서를 들여다 봤을 때 '왜'에 대한 부분이 자세히 설명되어 있으면 곧바로 다시 작업을 수행하기가 원활할 것이기 때문이다.

 

마지막으로 내가 한 업무 기록을 남김으로써 업무 진척 상황과 내 성과가 잘 드러나도록 할 수 있는 장점도 갖추고 있다.

 

소개할 문서 작업

이번 포스팅에서 소개할 문서 작업 몇가지가 있다.

 

• diagrams.net (구 draw.io):
  • 도메인과 ERD 설계, 유즈케이스 작성
• 구글 시트:
  • API 디자인(API 명세서)
• 깃 + 깃헙:
  • 커밋 메시지 작성, 프로젝트 관리 및 협업 환경 꾸미기(git flow, commit convention), milestone 관리, project 기능

 

 

3. 필요한 기술 정리하기

필요 세부 기술 목록을 뽑는 방법은 두 가지 정도로 함축된다.

• 미리 사용 기술을 모두 파악한 후 처음부터 프로젝트에 넣는 방법
• 기능 하나를 만들 때마다 필요한 기술을 추가해 나가는 방법

보통 개발을 진행하면서 필요한 점들이 눈에 보이기 때문에 2번 방식으로 많이 진행하기는 한다.

 

 

예상하는 세부 기능들(예시)

• 게시판, 댓글 도메인의 설계
• 도메인 데이터를 DB 에 저장
• JSON API 로 데이터 제공
• 사용자에게 웹 화면으로 서비스 제공 + 디자인 요소
  
  • 게시판 페이지
  • 게시글 페이지
  • 로그인 페이지
• 적절한 입출력 데이터의 검증
• 인증 기능
• 생산성에 도움이 되는 도구들 선택

 

이러한 기능들을 뽑아 놓고 봤을 때 필요한 기술들을 미리 정할 수도 있긴 하다. 그럼 다음과 같이 필요 기술들에 대한 리스트 역시 정리가 될 것이다.

• Java + Spring Boot 기반에서 선택
• 웹 서비스 제공 -> Spring Web
• 도메인의 설계와 DB 저장 -> Spring Data JPA, H2 Database, MySQL Driver
• JSON API 로 데이터 제공 -> Rest Repositories, Rest Repositories HAL Explorer
• 웹 화면: 목표에 맞춰 서버 사이드 렌더링으로 접근 -> 템플릿 엔진 -> Thymeleaf
• 디자인 요소 -> Bootstrap 5.2
• 적절한 입출력 데이터의 검증 -> Validation
• 인증 기능 -> Spring Security
• 생산성 -> Lombok, Spring Boot DevTools, Spring Boot Actuator

 

Spring을 사용하는 경우 https://start.spring.io/ 에서 해당 기술이 이 포함된 프로젝트 디렉터리를 만들 수도 있다.

 

 

4. 깃헙 프로젝트의 이슈 정리하기

이제 그렇다면 이제 깃헙을 활용하는 방법에 대해 배워보겠다. 깃헙에는 프로젝트(Project)라는 것을 활용하여 협업 일정이나 업무를 효율적으로 관리할 수 있다.

 

 

4-1. 깃헙 레파지토리(Repository) 만들기

먼저 깃헙 프로젝트 실습을 위한 레파지토리를 생성해 준다.

 

1. Repository name 설정

레파지토리 이름 설정

레파지토리 이름은 현재 내 계정의 레파지토리 이름과 중복되는 것이 있는지 체크를 하기 때문에 유의하여 작성한다. 되도록 해당 프로젝트의 속성이 드러나도록 정하는 것이 좋다.

 

2. Description (optional)

대부분 대충 작성하거나 넘어가는 부분으로 해당 레파지토리는 어떤 프로젝트를 다루고 있는지 간략한 설명을 넣는 공간이다.

 

3. Public / Private

그 다음으로 설정할 부분은 공개범위로써 Public과 Private이 있다. Public은 전체 공개, Private은 나만 보기라고 생각하면 된다. Private으로 설정해도 무방하지만 여타 써드파티 기술들(GitKraken, slack...)과 연동을 할 때 제약이 존재할 수 있기 때문에 이를 유념하여 설정하여야 한다.

 

 

그 다음으로는 이 저장소(repository)를 어떻게 초기화할 것인지를 설정하는 부분입니다.

 

4. Add a README file 옵션

첫화면을 만들기 위해 README file을 만드는 옵션이다. 체크 시 자동으로 저장소에 README file이 만들어지면서 commit과 함께 push된다.

그렇지 않으면 우리가 직접 만들고 commit해도 상관없다.

 

※ 참고로 README 파일을 만들어 commit 될 때 깃헙에서는 자동으로 default branch 이름을 main으로 바뀌지만 그렇지 않다면 master branch가 될 것이다.

 

 

5. Add .gitignore 옵션

.gitignore 템플릿

.gitignore를 자동생성하는 옵션이다. 프로젝트를 관리하다 보면 우리가 직접 작성한 소스코드나 프로젝트와 직접 관련이 있는 파일들 외에 부수적으로 만들어지는 파일이 있을 수 있다.(메타데이터 파일, 숨겨진 파일 등)

특정 IDE를 사용하면 생기는 .idea와 같은 폴더들이 있는데 해당 IDE를 사용하면 개발하는 컴퓨터에는 존재해야 하지만 그 IDE를 사용하지 않는 사람이 그 저장소의 코드를 사용하기 위해선 그 IDE를 사용하지 않아도 되기 때문에 .idea 파일까지 저장소에 포함되면 안된다.

이때 .gitignore에 해당 파일명 혹은 폴더명을 작성하면 해당 폴더나 파일은 git이 인식하지 않아 commit의 대상에서 제외되는 기능을 도와준다.

 

해당 프로젝트에서 사용하는 툴에 맞춰 템플릿을 깃헙에서 제공하고 있으니 해당 템플릿을 default로 지정하여 저장소를 생성하면 그에 맞는 .gitignore와 함께 만들어진다.

 

혹은 https://www.toptal.com/developers/gitignore/ 라는 사이트에서 특정 운영체제, IDE(개발환경), 프로그래밍 언어에 맞는 gitignore 파일을 만들어 주니 이를 참고하는 것도 좋은 선택이다.

 

 

6. Choose a license

라이센스를 만드는 옵션이다. 우리가 오픈소스 프로젝트를 진행한다면 그와 어울리는 라이센스를 지정해 주어야 한다.

제일 유명한 라이센스로는 MIT Licenese가 있으며 아무 제약없이 누구나 공개된 상태를 이용할 수 있는 라이센스의 한 종류이다.

 

 

그렇게 해서 create repository를 클릭하면 레파지토리가 만들어진다.

 

만약 초기에 commit을 하지 않고, 즉 README file을 만들지 않고 생성하였다면 이를 GitKraken과 연동 시 알아서 initialize를 하라고 뜨고 만들어진 README 파일을 그대로 push하면 README 파일을 생성하겠다는 옵션과 똑같은 상태가 된다.

 

 

initial commit 직후 상태

 

4-2. 깃헙 레파지토리 협업 관련 탭

Code

Code에는 우리가 작성한 코드가 들어가게 된다.

 

Issues

Issues에는 우리가 할 업무(혹은 안건)에 대한 상세 내용이 들어간다. 이슈에는 누구에게 할당된 업무인지(Assignees), 어떤 유형의 업무인지(Labels)를 설정가능하고 Project(이후에 나옴), Milestone(이후에 나옴) 과 연동할 수 있다.

 

 

마일스톤

개발일정을 어떻게 할 것인지 시각적으로 나타내는 기법 중에 하나이다. 이를 깃헙에서 제공하고 있으며, 많이들 들어봤을 'Jira'라는 툴을 통해서 많이 사용하기도 한다.

 

깃헙에서는 마일스톤이라는 것을 만들고 그 전에 만든 이슈와 연동하면 이슈가 끝날 때마다 마일스톤의 게이지가 채워지게 되는 식이다.

 

Pull requests

Pull requests는 내가 다른 브랜치에서 진행한 작업에 대해 main 브런치(혹은 특정 브랜치)로 합쳐달라고 요청하는 기능이다. 

이 부분에서 코드 리뷰가 진행되며 코드 리뷰 이후에 실제로 반영하겠다 결정하면 merge를 진행하게 된다.

 

 

Actions

이곳은 빌드와 배포의 자동화 마련을 주 목적으로 사용된다.

 

Projects

이미 어떤 회사에서 주니어 개발자로 일을 하고 있거나 미리 사용해 봤다면 애자일 소프트웨어 방법론에서 들어본 적이 있을 것이다.

 

애자일 소프트웨어 방법론?

간단히 말해 소프트웨어 엔지니어링에 대한 개념으로 프로젝트를 진행할 때 생명주기(Lifecycle)동안 반복적인 개발을 촉진하도록 하는 방법론 중 하나이다.

더 자세한 내용은 아래 링크에서 확인할 수 있다.

애자일 소프트웨어 개발 - 위키백과, 우리 모두의 백과사전

 

애자일 소프트웨어 방법론에는 칸반 보드라는 것이 있다.

진행을 계획하는 업무부터 현재 진행 중인 업무, 이미 완료한 업무 등을 특정 보드에 붙이고 각 상태에 맞는 곳에 떼었다 붙였다 하면서 시각적으로 현재 프로젝트의 진행 상황을 보기 위한 도구이다. 

 

물론 우리는 컴퓨터를 사용하기 때문에 하나하나를 마우스로 드래그 앤 드랍하여 이동할 수 있다. 이는 깃헙 Projects 탭에서 할 수 있으며 Jira라는 툴을 사용하는 경우도 있다. 

깃헙을 사용하면 이슈와 연동할 수 있기 때문에 그만의 이점을 가지고 있기도 하다.

 

 

Project 생성

깃헙 Projects에서는 새로운 project를 하나 만들면 여러 템플릿 중에 하나를 고를 수 있는데 보통 Team backlog를 사용하여 칸반 보드의 확장 버전으로 사용할 수 있기 때문에 해당 템플릿으로 만든다.

 

※ 참고로 프로젝트를 생성할 때는 특정 저장소(repository)에 대해서 만드는 것이 아니기 때문에 추후 레파지토리 Project 탭에서 다시 Link를 해 주는 과정을 진행해야 한다.

 

 

칸반 보드에서 다양한 상태(State)들

그러면 일반적인 칸반 보드 스타일을 깃헙 스타일로 만들게 된다.

 

여기서 'New'라는 곳에 어떤 업무를 할 지 생각해 보는 곳이다. 이 중에서 하기로 결정하면 다음 단계로 넘어가고 그렇지 않다면 그냥 삭제하면 되기 때문에 자유롭게 놓을 수 있는 것이다.

 

그래서 New 부분에 item을 하나 추가하게 되면 이것은 프로젝트에 바로 종속되는 것이 아니다.

그렇기 때문에 위 세개의 아이템은 어떤 저장소에도 저장되어 있지 않는 것이고 여기서 드래그 앤 드랍해서 할 일 목록으로 옮길 수도 있으며 그 중에서 하기로 결정된 일, 예를 들어 backlog나 new에 있는 업무 중에서 이번주나 다음주에 내가 하고자 하는 일이 있다면 Ready 상태로 옮겨 놓습니다. 보통 Ready는 Todo라고도 합니다.

 

 

Issue로 변환? Draft로 남겨놓기?

그 후 내가 하기로 결정하여 Ready에 있는 업무를 클릭하면 위 사진의 하단 부분에 보이는 Convert to issue를 클릭하여 해당 안건을 Issue로 바꿀 수 있다.

 

하지만 업무 결과를 팀원들과 공유할 필요가 없는 경우에는 그냥 Draft 그대로 놔두면 된다. 

 

보통 Issue의 body 부분은 description, todo 등의 내용으로 채우는데, description은 해당 업무가 어떤 업무인지 간략히 설명하는 것이고 todo에는 markdown 문법 중 todo 리스트를 만드는 것이 있는데("- [ ]") 업무를 소단위로 쪼개 여러 개의 할일로 소분화하여 계획을 한다.

 

그 후 해당 할 일을 실제로 개발에 들어가게 되면 In progress 상태로 바꿔주면 된다.

 

 

그 외 설정

또한 Workflows 세팅을 통해 칸반 보드에서 상태 변경을 할 때 자동화를 시킬 수 있는 부분 또한 존재한다.

 

보통 In progress의 작업을 마치면 해당 브랜치를 push를 하여 pull request를 만들게 되는데 projects에서 pull request가 만들어지면 알아서 자동으로 In review로 가도록 한다면 매번 일일히 옮겨줄 필요가 없어지기 때문에 해당 부분은 그렇게 설정하는 것이 좋다.

 

또한 어떤 작업이 Done 상태로 가면 이제 완전히 끝난 것이기 때문에 해당 작업과 관련된 Issue를 Close되기도 해야 한다. 따라서 어떤 작업의 Issue를 Close했거나 Pull request가 close되면 자동으로 Done 상태로 옮겨지도록 설정한다.

 

 

그리고 프로젝트가 활발히 진행되게 되면 업무가 무수히 넘칠 것이기 때문에 filter 기능을 활용할 수도 있다.

 

 

변경된 내용 저장 및 불러오기

해당 Project 페이지는 여러 팀원이 함께 사용하는 것이기 때문에 자유롭게 수정이 가능하다. 그러나 변경한 설정이 있다면 반드시 save changes를 통해 저장을 해줘야지 모든 팀원들에게도 반영이 되기 때문에 유의해야 한다.

 

 

Wiki

위키피디아, 나무 위키처럼 우리 프로젝트 만의 위키 페이지를 만드는 공간이다. 관련된 지식들을 쌓아놓는 문서함으로 사용할 수도 있고 보통 confluence wki라는 것이 가장 유명한 예이다.

 

Table of Contents Macro | Confluence Data Center and Server 8.0 | Atlassian Documentation

 

그리고 다른 깃헙 프로젝트를 보니까 해당 페이지를 기획 단계에서부터 트러블 슈팅에 대한 내용을 적는 공간으로 활용하기도 하는 것 같으니 팀원들과 상의를 하여 해당 공간을 어떻게 사용할지 결정하는 것이 좋겠다.

 

 

 

5. 깃 브랜치 전략 세우기

깃 브랜치(git branch)를 만드는 데 큰 제약은 없지만 협업을 진행하면서 더 원활한 관리를 위해 브랜치 명을 논의하는 전략을 세운다.

 

해당 전략에는 두 가지 정도의 방식이 있다.

gitflow는 master, develop, feature, release, hotfix등의 브랜치를 설정하고 운영하는 방식이고,

github flow는 main(master), feature 브랜치만으로 운영하는 방식이다.

 

gitflow는 꼼꼼하고 자세하지만 그렇기 때문에 어렵고 알아야 할 것이 많다. github flow는 이에 더욱 단순한 형태로 github에서 제시되는 방식으로 주요 production에 대한 main 브랜치와 실제 개발을 하는 develop 브랜치인 feature 브랜치 두 개만 두고 운영하는 방식이다.

 

프로젝트의 규모가 클수록(대기업) gitflow가 안전하고 효율적이기 때문에 잘 사용되고 그다지 크지 않다면(스타트업) 개발의 방해가 되지 않도록 단순한 github flow를 사용하는 편이다.

 

 

브랜치 전략을 세우는 이유와 요령

하나의 프로젝트 소스코드를 여러 개발자가 다루면서 발생하는 각종 부작용을 해결하고자 하여 브랜치 전략을 세우는 것이며 개발 협업을 원활하게 하기 위한 일종의 사전 약속이라고 볼 수 있다.

 

전력을 세울 때 고려할 수 있는 요소들로는 다음과 같은 것들이 있다.

• 이 브랜치는 제품으로 내보낼 수 있는가? (master or main)
  • 언제든 빌드가 가능해야 하고, 언제든 테스트가 성공해야 하고, 고객에게 보여줄 수 있는 상태
• 이 브랜치는 빌드 실패를 허용하는가?
• 이 브랜치는 테스트 실패를 허용하는가?
• 이 브랜치는 임시로 운영하는가? 유지하지 않고 수시로 삭제하는가?

 

아래에 첨부한 reference는 위와 관련하여 참고하면 좋은 내용이기 때문에 수시로 확인하면 도움이 될 것이다.

GitHub - nvie/gitflow: Git extensions to provide high-level repository operations for Vincent Driessen's branching model.

 

A successful Git branching model

 

GitHub flow - GitHub Docs

 

 

6. Git 커밋 메시지 컨벤션

이제 커밋 메세지를 작성할 때 팀원끼리 협의하는 컨벤션에 대해서 말해보도록 하겠다.

 

6-1. Commit Message 구조

기본적인 커밋 메세지의 구조는 아래와 같이 제목, 본문, 꼬리말로 구성된다.

type : subject

body

footer

 

6-2. Commit Type

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 등
• refactor: 코드 리팩토링
• test: 테스트 코드, 리팩토링 테스트 코드 추가
• chore: 빌드 업무 수정, 패키지 매니저 수정

등이 존재하며, 임의로 추가하거나 빼거나 하여 프로젝트 특성에 맞는 유형들을 선택하면 된다.

 

 

6-3. Subject - 주제

제목은 50자를 넘기지 않도록 하고, 대문자로 작성하며 마침표를 붙이지 않는다.

또한 과거 시제를 사용하지 않고, 명령형으로 작성한다.

• "Fixed ~ " -> "Fix ~ "
• "Added ~ " -> "Add ~ "

 

6-4. Body - 본문

본문 같은 경우 선택사항이긴 한데 사실 안 적는 경우가 많고 모든 커밋에 본문 내용을 작성할 필요가 없다. 그래서 오히려 Subject 부분에 해당 커밋이 무엇을 의미하는 지 자세히 적는 경우가 더 바람직하다고 할 수 있다.

 

 

6-5. footer

이 또한 선택사항으로 모든 커밋에 꼬리말을 작성할 필요는 없으며 보통 issue tracker id를 작성할 때 사용한다.

#[이슈번호] 형식으로 작성하며 여러 개의 이슈 번호가 있는 경우 쉼표(,)로 구분한다.

 

 

 

6-6. Autolinked references and URLs

깃헙에서는 Autolinked referneces and URLs를 제공한다.

 

관련 내용은 아래에서 자세히 볼 수 있다.

Autolinked references and URLs - GitHub Docs

 

간단히 말하면 Issue나 pull request의 URL은 보통 github의 도메인에 해당 경로까지 타고 들어가기 때문에 굉장히 긴 URL인데 이를 #26과 같이 쓰면 해당 문자가 URL로 바뀌어 referencing 된 곳으로 이동이 가능하다.

 

그래서 커밋 메세지를 작성할 때 해당 커밋이 어떤 이슈와 관련된 것인지를 명시하기 위해 "#[issue-id]" 와 같은 문자를 넣어준다.

 

 

그외 - 커밋 메시지 Emoji(Gitmoji)

Emoji	Description
🎨	코드의 형식 / 구조를 개선 할 때
📰	새 파일을 만들 때
📝	사소한 코드 또는 언어를 변경할 때
🐎	성능을 향상시킬 때
📚	문서를 쓸 때
🐛	버그 reporting할 때, @FIXME 주석 태그 삽입
🚑	버그를 고칠 때
🐧	리눅스에서 무언가를 고칠 때
🍎	Mac OS에서 무언가를 고칠 때
🏁	Windows에서 무언가를 고칠 때
🔥	코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜	파일 구조를 변경할 때 . 🎨과 함께 사용
🔨	코드를 리팩토링 할 때
☔️	테스트를 추가 할 때
🔬	코드 범위를 추가 할 때
💚	CI 빌드를 고칠 때
🔒	보안을 다룰 때
⬆️	종속성을 업그레이드 할 때
⬇️	종속성을 다운 그레이드 할 때
⏩	이전 버전 / 지점에서 기능을 전달할 때
⏪	최신 버전 / 지점에서 기능을 백 포트 할 때
👕	linter / strict / deprecation 경고를 제거 할 때
💄	UI / style 개선시
♿️	접근성을 향상시킬 때
🚧	WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎	New Release
🔖	버전 태그
🎉	Initial Commit
🔈	로깅을 추가 할 때
🔇	로깅을 줄일 때
✨	새로운 기능을 소개 할 때
⚡️	도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡	새로운 아이디어, @IDEA주석 태그
🚀	배포 / 개발 작업 과 관련된 모든 것
🐘	PostgreSQL 데이터베이스 별 (마이그레이션, 스크립트, 확장 등)
🐬	MySQL 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🍃	MongoDB 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🏦	일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)
🐳	도커 구성
🤝	파일을 병합 할 때

 

예시