[Git] 기초문법 - Commit Template 설정해보기 및 IntelliJ에서 Git commit template Plugin 사용하기 - 02
ohnyong
2023. 7. 23. 13:50
https://ohnyong.tistory.com/127에서 Commit 메시지를 작성하는 규칙들에 대해서 인지하고 해당 양식처럼 사용하려고 노력하고 있다. 하지만 항상 해당 양식을 복사, 붙여 넣기 하는 것은 비효율적이었다. 이미 자동화된 template 같은 게 있지 않을까? 생각했다.
--system Git은 먼저 /etc/gitconfig 파일을 찾는다. 이 파일은 해당 시스템에 있는 모든 사용자와 모든 저장소에 적용되는 설정 파일이다. git config 명령에 --system 옵션을 주면 이 파일을 사용한다.
--global 다음으로 Git은 ~/.gitconfig 파일을 찾는다. 이 파일은 해당 사용자에게만 적용되는 설정 파일이다. --global 옵션을 주면 Git은 이 파일을 사용한다.
--local 마지막으로 현재 작업 중인 저장소의 Git 디렉토리에 있는 .git/config 파일을 찾는다. 이 파일은 해당 저장소에만 적용된다. git config 명령에 --local 옵션을 적용한 것과 같다. (아무런 범위 옵션을 지정하지 않으면 Git은 기본적으로 --local 옵션을 적용한다)
각 설정 파일에 중복된 설정이 있으면 설명한 “순서대로” 덮어쓴다. 예를 들어 .git/config 와 /etc/gitconfig 에 같은 설정이 들어 있다면 .git/config에 있는 설정을 사용한다.
2. Commit Message template 설정
커밋 시 Git은 commit.template 옵션에 설정한 template 파일을 보여준다. 커밋 메시지 template을 지정하면 커밋 메시지를 작성할 때 일정한 스타일을 유지할 수 있다.
template 파일 생성하기 .git이 있는 현재 폴더 위치에서 아래 명령을 실행해 .gitmessage.txt 파일을 생성한다.
touch .gitmessage.txt
template 파일 작성하기 에디터를 통해 해당 파일 열기(CLI환경은 VI에디터(VIM설치필요), GUI환경은 아무거나 상관없다.)
vim .gitmessage.txt
파일 내용 수정
#파일내용수정
i
# <타입> : <제목> 형식으로 작성하세요
################
# 타입 설정하기
## feature : 새로운 기능 추가
## fix : 버그 수정
## docs : 문서 수정
## test : 테스트 코드 추가
## refactor : 코드 리팩토링
## style : 코드 의미에 영향을 주지 않는 변경사항
## chore : 빌드 부분 혹은 패키지 매니저 수정사항
# 제목 설정하기
## 제목 작성 후 공백 한줄을 포함해야, 제목과 본문이 구별됨
## 제목 첫 글자는 대문자로 작성, 마침표를 사용하지 않음
## 제목은 명령문으로 사용, 과거형을 사용하지 않음
## 제목은 50글자로 제한
################
##### 제목을 아랫줄에 작성하세요 #####
################
# 본문 설정
## 본문 작성 후 공백 한줄을 포함해야, 본문과 Resolves가 구별됨
## 본문의 각 행은 72글자로 제한
## 본문은 "왜"와 "무엇을"위주로 작성
## 본문은 행으로 구분되어야 함
## 본문의 내용은 *으로 시작함
################
##### 본문(추가 설명)을 아랫줄에 작성하세요 #####
################
# Resolves 설정
## Resolves 작성 후 공백 한줄을 포함해야, Resolves와 See also가 구별됨
## Resolves의 내용도 *으로 시작함
## 해결한 이슈는 닫을 수 있도록 함.
# 이슈 종료 방법
## '키워드 #이슈번호'
# issue 종료 키워드 (github)
## * close - 일반 개발 이슈
## * closes
## * closed
## * fix - 버그 fix 이슈
## * fixed
## * resolve - 문의 요청사항 이슈
## * resolves
## * resolved
################
##### Resolves를 작성하세요 (생략 가능) #####
################
# See also 설정
## 연관된 이슈의 경우 이슈 번호와 연관 이슈 내용을 입력
## See also의 내용도 *으로 시작함
################
##### See also를 작성하세요 (생략 가능) #####
################
# Remember me ~ Commit Message 규칙
## 1. 제목과 본문을 빈 행으로 구분한다.
## 2. 제목을 50글자 내로 제한
## 3. 제목 첫 글자는 대문자로 작성
## 4. 제목 끝에 마침표 넣지 않기
## 5. 제목은 명령문으로 사용하되, 과거형을 사용하지 않는다.
## 6. 본문의 각 행은 72글자 내로 제한
## 7. 어떻게 보다는 무엇과 왜를 설명
################
#저장하고VI에디터종료
ESC
:wq
VI에디터 말고 GUI 에디터로 수정해도 상관없다. 정상적으로 작성되었는지 GUI로 확인해 보았다.
3. 작성한 template을 git에 설정하기
<1. Git Config> 내용을 이해한 상태로 git commit 명령을 실행할 때 위 작성된 template을 적용하게 해야 한다.
template 파일을 설정한다는 것은 commit.template에 .gitmessage.txt 파일을 등록한다는 의미다. <경로>부분에 .gitmessage.txt가 위치한 경로를 적어준다.(생성위치일 것이다.) 우선 내 작업 PC범위인 --global 범위까지만 적용하기로 했다. 이러면 내 PC에서 생성하는 Repository들은 해당 설정이 적용된다. --local은 해당 Repository만 적용한다는 내용이니 나중에 변경이 필요하면 --local로 적용해야겠다.
<3. template 설정> 내용을 진행한 상태로 정상적으로 git config에 해당 template이 설정되었는지, 적용이 되는지 확인해야 한다.
git config 설정을 확인하는 커맨드는 아래와 같다.
git config --list
아래와 같이 template로 설정한 파일이 commit.template에 경로가 등록되었다.
해당 설정을 삭제하는 커맨드는 아래와 같다.
git config --global --unset commit.template
5. template 적용 테스트 CLI
현재 작업 폴더에서의 변동사항이 2개 있다.
git status
그중 java/org/example/Main.java라는 샘플 코드가 불필요하게 생성되어 있어서 삭제하는 변동 작업을 우선 스테이지에 올렸다. 해당 삭제한 변동 사항을 커밋할 때 위에서 설정한 template이 작동하는지 테스트하고자 한다.
원하는 변동 사항만 스테이지에 올라간 상태로 커밋 커맨드를 입력한다.
git commit
즉시 VI 에디터로 설정한 template이 열리는 것을 확인할 수 있다. 작성해 둔 주석 가이드에 따라 지정된 라인에 커밋 메시지를 입력한다.
모두 편집하고 VI에디터를 저장 종료하면 다음과 같이 커밋이 완료된다.
해당 커밋 내용이 Template에 맞추어 정상적으로 기입되었는지 확인한다.
git log
log 한줄보기 옵션으로도 정상적으로 나타난다.
git log --oneline
이제 성공적으로 template을 활용하여 Commit 메시지를 양식, 규칙에 맞추어 통일 할 수 있게 되었다.
7. git을 위해 GUI vs CLI 어떤 인터페이스를 사용할까?
이제 기초적으로 CLI 환경에서 테스트가 완료되었다. 하지만 개발 작업 자체를 GUI로 구성된 IDE를 사용하기 때문에 좀 더 효율적으로 사용하기엔 IDE에서 제공하는 내부 프로그램을 활용하는 것이 편리하다.
어떤 GUI 툴을 사용할 것이냐의 문제가 발생한다. 직접적인 코드 에디터들인 VSCode, Eclipse, STS처럼 내가 과거 사용해 본 IDE들은 Git, Docker 등 주변 프로그램들과의 호환을 위해서 자체적으로 연동되는 내부 플러그인들이 있었다. 그런데 나는 Git 관리는 IDE외부의 데스크톱 프로그램인 주로 Sourcetree를 사용했고 이전에는 Github Desktop을 사용해보기도 했었다. 처음 Git을 배울 때 실습했던 프로그램이기 때문에 익숙해서 사용했지만 계속 사용하다보니 이런 IDE 외부 데스크탑 프로그램들을 사용 할 때 장점과 단점이 존재했다.
데스크탑 프로그램 장점(Sourcetree, Github Desktop 등)
Git을 처음 CLI로 익숙해지다가 CLI 환경과 GUI 환경이 어떻게 같은지 대입하여 이해하기 쉬움 CLI에 비하여 매우 쉽게 구성 가능 GUI로 Branch의 분기, Commit 진행 방향, 내가 선택하고 있는 Branch(workspace)를 눈으로 확인하기 쉬움
데스크탑 프로그램단점
VSCode, Eclipse, IntelliJ와 같은 IDE의 내부 git 기능과 중복됨 중복된다는 것으로 불필요한 작업 PC의 메모리, CPU 등 성능저하 생각보다 옛날 프로그램이라서 GUI라는 것만 빼고 보면 편의기능이 다양하지 않음 Mac은 Sourcetree가 비정상적으로 작동하는 경우가 많음 그나마 Intel Chipset은 Windows처럼 돌아가긴 하지만 M1, M2는 더 심각함 가끔 IDE git과 데스크톱프로그램 git의 상태 변화가 동시에 일어나면 동기화 과정이 중복되면서 충돌도 발생하고 강제종료가 빈번함
CLI 이용의 불편함? 필요성, 중요성
분명 현재 배우는 입장으로 GUI를 이해하는 데 있어서 기본적으로 CLI로 어떻게 진행되는지 이해할 필요는 있다고 생각한다. 왜냐하면 이미 git에 존재하는 기능이고 나에게 필요한 기능이 있는데 GUI 프로그램에서 해당 부분을 구현 한 부분이 찾기 어렵게 되어 있으면 결국 CLI에서 기능을 찾아보고 GUI는 해당 기능이 어딨는지 찾아봐야 하는 경우가 자주 발생했다. 더하여, NAS 서버를 활용해 보면서 CLI로 git을 사용하는 것 또한 무조건적으로 필요하다고 느꼈다. NAS의 OS자체가 DSM이라는 해당 제조사의 OS기 때문에 Sourcetree, Github Desktop 같은 널리 퍼진 GUI 프로그램도 지원하지 않는 상황이었다. 그래서 Git, Docker 등을 사용할 때 사용 할 수 있는 인터페이스가 제한적이거나 내가 보던 것과 다른 경우도 있었다. 분명히 동일하게 작동할 것인데 말이다. 그나마 NAS의 필살기인 Docker로 어찌 저찌 익숙한 GUI 프로그램을 가상으로 띄워서 활용해서 할 수 있겠지만 기본적으로 ubuntu 터미널을 통해서 근본적인 CLI를 통해서 해결하는 것이 가장 직접적으로 해결하는데 큰 도움이 되었기도 하다.
Sourcetree를 무조건 고집해서 사용할 필요는 없다.
내 로컬 작업 PC 환경에서는 위 언급한 데스크톱 프로그램의 단점이 있는데도 Sourcetree까지 별도로 열어서 git 작업을 해야하는가? 분명 작업트리를 전체적으로 보는 시인성은 뛰어나다. 하지만 이미 어느 브랜치를 선택한 것을 내가 인지하고 있는 상황에서 매번 작업할 때 커밋을 날리는 것에 궂이 작업 컴퓨터에 부담을 줄 필요는 없다고 판단했다. 특히 강제 종료되거나 오류가 발생하고 있는 상황에서도 말이다. 내 개발 환경과 데스크탑 프로그램의 불안정성은 나에게 "외부 GUI 데스크탑 프로그램을 사용해야 하는가?"라는 의문이 들었다.
CLI도 무조건 고집해서사용할 필요는 없다.
CLI도 분명 다른 시점으로 불편함이 있다. IDE 내에서 git 기능이 연결되어 모두 처리할 수 있는데 굳이 시인성, 편집성이 안 좋은 IDE CLI를 사용해야 하는가? 몇 줄 안 되는 커밋 메시지지만 개선 방법을 찾아보자. 애초에 동일한 원리로 돌아가는 것이며 말 그대로 보이는 인터페이스의 차이이다. 근본보다는 당장 내 작업 방법에서 편리한 것을 찾는 것이 중요하다.
8. 내 작업의 편리성을 위해 IDE에 GUI를 활용하자.(실전용)
결론적으로 주로 사용하게 될 GUI로 구성된 IDE에서 해당 기능을 제공하거나 좀 더 나은 확장 프로그램에서까지 제공한다면 그 안에서 처리하는 것도 나쁘지 않다. 전제는 배우는 입장에서는 CLI로 기능을 사용해 보고 과정을 이해한 후 GUI를 사용하는 것이다.
직전 Python실습에서 VSCode를 사용할 때는 계속 왼쪽 사이드바에 git 기능이 있는데 알트탭으로 Sourcetree를 열어보는 나를 보고 이게 맞나 생각이 들었다. 이번에 IntelliJ IDE를 처음 사용해 보면서 전보다 개선된 내 작업 환경을 만들어보고 싶었다. 기능을 배울 땐 정석을 이해해야 되므로 CLI로 천천히 공식 문서를 참고하면서 이해하려 했다. 이번엔 편리한 도구가 있기 때문에 사람이기에 도구를 사용해서 편하게, 심플하게 처리하려 한다. 그러기 위해서는 원하는 기능 자체가 존재하는지부터 찾아봐야 한다.
stackoverflow에서 검색을 통해서 나와 같은 고민을 하는 글을 검색했고, 두 가지 답변을 확인했다.
첫 번째 답변은 IntelliJ 자체적으로 기능이 적용되어 있다는 답변이다.
jetbrains사의 공식 IntelliJ 2021 버전 업데이트에서 Git commit templates를 지원한다는 업데이트가 있었다고 답변이 있었다. 그럼 애초에 template 기능을 가지고 있나? 공식 릴리즈 뉴스를 참고하고 직접 IDE의 이곳저곳을 살펴봤다. IDE내부 Git 기능에서 Commit을 위한 GUI로 들어가 보면 내가 git config로 설정한 template이 준비돼있는 모습을 볼 수 있다. 이 상태도 충분하지만 template을 수정한다면 경로를 config로 전달하는 GUI는 찾아보기 어려웠다. 조금 다른 것은 없을까?
9. 내 작업의 편리성을 위해 IDE에 Plugin을 활용하자.(번외)
두 번째 답변은IntelliJ의 마켓플레이스에서 Git Commit Template라는 플러그인을 추천한다는 답변을 보았다.
답변에서 추천한 것처럼 Git Commit Template Plugin을 다운로드하였다.
Plugin을 설치한 후내부 Git 관련 툴의 Commit 부분에 새로운 아이콘이 나타났다.
해당 아이콘을 누르면 다음과 같은 양식이 나타난다. 양식에 따라 메시지를 입력하고 확인을 누르면
원하는 대로 Commit message가 지정된 양식에 따라 맞춰져서 입력된다.
결과적으로 해당 plugin은 첫 방식과는 조금 차이점이 있다.
첫 방식은 공식적으로 git config 자체에서 설정하는 것으로 양식을 문서화시킬 수도 있다. 또한 system, global, local로 template 적용 범위를 선택할 수 있다. 하지만 조금 번거로울 수 있다. 관리가 필요하다.
Plugin 사용 방식은 등장하는 폼이 Commit message 텍스트 자체를 생성시켜주는 역할만 한다. 통일화시켜주는 서포트 정도의 역할은 해줄 수 있다고 본다.
두 가지 방법 모두 편리한 기능이기 때문에 잘 활용하여 앞으로 위 규칙을 최대한 맞춰보면서 정리된 Commit message를 날려보고자 한다.
