1. 얼마나 자주 commit 하십니까?
개인 프로젝트가 되었던 실무가 되었던 우리는 개발을 하면서 매일같이 commit을 합니다. 실제 코드를 작성하는것과 다르게 commit convention은 개발 커뮤니티에서 많이 다루어지지 않으며 인기가 있는 주제가 아닙니다.
commit은 기능적으로 게임의 ‘저장하기'기능과 다를게 없기 때문에 개인에 따라 정말 자주 하거나, 아니면 컴퓨터를 끄기 전 마지막에 하기도 합니다.
매 번 commit을 할 때마다 함께 협업 하는 사람과 미래의 자기자신이 이해 할 수 있도록 commit message를 작성하도록 되어있습니다. 서둘러 개발을 해야 한다는 마음이 지배를 할 수록 commit은 숙제처럼 느껴지게 되어질 것입니다.
자연스레 commit을 하는 기준은 본인의 기분에 따라 달라질 것이고 message의 내용은 단어 하나로 끝나게 될 것입니다. 아주 틀린 이유도 아닌것이, 우리가 과거 commit history를 보는 경우는 생각보다 자주 없습니다. 직접 고치는게 더 빠르기 때문인 것 같습니다.
현재 내 자신은 어떤 기준으로 commit을 할까요?
2. 커뮤니티의 의견
stack overflow에 commit은 얼마나 자주 되어야 하는지 질문에 대한 답변들입니다.
기가 찹니다. 저는 개인적으로 모두 동의가 되지 않습니다. 저런 기준들은 개인차가 너무 크기 쉽습니다. 만약에 5명의 팀이 한 프로젝트에서 ‘우리는 최대한 자주 commit을 하자'라는 기준으로 일을 한다면 2개월 후 어떤 방식으로 commit이 이루어질지 안봐도 뻔합니다.
5줄마다 commit을 하라고 정할 수는 없지만, 우리가 보편타당한 근거와 사실을 가지고 기준을 가져야 합니다. 팀으로 할때도 물론이지만, 개인 프로젝트를 할 때도 매우 중요합니다.
3. task별로 나누어서
리팩터링의 마틴 파울러는 고급 개발자일수록 일을 잘 쪼갠다고 가르침을 주십니다. 그외에 거의 모든 개발조상님들의 가르침은 큰 차이가 없습니다. 로버트 마틴의 클린 아키텍쳐에서도 같은 맥락의 얘기이며, 리액트가 풀고자 하는 가장 큰 문제중 하나도 응집도를 유지하면서 관심사 분리를 하는 것입니다.
그러기에 commit에는 task별로 하는게 보편타당한 방법이라고 느껴집니다. 마치 관심사분리를 하는 것처럼 말이죠. 최대한 commit끼리 서로 의존하지 않도록 말이죠.
우리가 프론트엔드에서 ‘로그인' 기능을 만든다고 생각해봅시다. 회사에서는 물론 ‘로그인 기능 추가해주세요~’라고 쉽게 요청이 들어오지만, 사실 매우 (귀찮고) 작은 task들이 있습니다.
아마 이런 작업들을 해야하지 않을까요
- 로그인에 필요한 폴더구조 설계
- 로그인에 필요한 컴포넌트 설계 및 생성
- 로그인에 필요한 라이브러리 import (ex: js-cookie, axios 등등)
- html 태그 마크업
- css 적용
- 로직 작성 (절대로 하나의 task로 끝나지 않습니다)
- api 붙이기
- 테스트코드 작성
- 리팩터링
이 마저도 크게 나눈 것들이고, 실제로 작업하게 되면 저 기준에서 더 작은 task들로 나누어지게 됩니다.
훌륭한 개발자는 최대한 적절하게 task별로 일을 나눌것입니다. 그리고 그에 맞추어 commit 작성을 하게 될 것입니다.
저같은 초보 개발자일수록 기분에 따라 만들고 commit 작성을 하겠죠 (일단 집에 가야하니까 commit을 하자 같은..). 유일한 기준은 개발자 본인의 기분이고, 사실상 본인이 뭘 하는지 잘 모르면서 일단 눈에 보이도록 만드는 그런 방식이겠죠.
4. 프로답게 commit하는 방법
아래 참조한 fcc의 비디오에서 크나큰 영감을 받았습니다. 저는 여지껏 아래 코드와 같이 살아왔습니다.
git add .
git commit -m 'chore: add a login feature'
git push -u origin login-feature위에 점을 찍을때 무언가 이상하다는 것을 느꼈어야 했는데 몰랐습니다. 사실은 파일별로 하는 것도 좋은 방법이 아닙니다.
추천 드리는 방법은 아래와 같습니다:
1. git add . 말고 git add -p를 씁니다.
$ git add -p2. git add -p를 사용하면 아래와 같이 안내가 나옵니다.
diff --git a/main.go b/main.go
index 2f16edb..793557c 100644
--- a/main.go
+++ b/main.go
@@ -11,4 +11,5 @@ func main() {
fmt.Println("hello world")
fmt.Println(mascot.BestMascot())
fmt.Println(quote.Go())
+ fmt.Println("this is git commit")
}3. 아래 옵션 중 하나를 고르면 됩니다. 모르겠으면 '?'를 누릅니다.
(1/1) Stage this hunk [y,n,q,a,d,e,?]?4. 이 옵션대로 코드 hunk별로 커밋을 진행하면 됩니다.
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
e - manually edit the current hunk
? - print help
git add -p 를 사용한다면 해당 task에만 적용되어지는 코드를 commit 할 수 있습니다.
commit 을 하는 더 좋은 방법은 아래와 같습니다.
1. git commit -m <message>를 사용하지 않는 것이 좋습니다.
git commit2. 아래와 같이 commit message를 사용하는 공간이 vim 에디터로 나옵니다.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/master'.
#
# Changes to be committed:
# modified: main.go3. commit message를 사용하는 방법은 이렇습니다.
<commit message header>
<빈칸>
<commit message body>
<빈칸>
<commit message footer>*** 빈 칸을 기준으로 git 이 알아서 header, body, footer를 인식합니다.
4. commit message 가이드
저는 최대한 자세하게 담는 것을 선호합니다. header에는 평소에 -m 플래그를 사용하여 하듯이 적는 것이 좋을 것 같습니다.
그리고 body에는 최대한 자세하게 적는 것이 좋을 것 같습니다.
- 어떠한 변화가 있었는지
- 어떻게 적용 되었는지
- 레퍼런스가 있다면 추가
- 이 commit을 기준으로 추가적으로 어떤 작업들이 이루어져야 하는지
footer에는 보통 BREAKING CHANGES: 로 시작하는 엄청난 변화가 있으면 작성을 합니다. 그 외로 관련된 issue ticket같은 것이 있으면 작성하는 것이 좋습니다.
5. 결론
이런 컨벤션을 지켰을 때 가장 큰 장점은 우리가 그 날의 기분대로 개발하지 않고, 풀어야 하는 문제별로 일을 할 수 있도록 강제를 시켜준 다는것에 가장 큰 의미가 있습니다.
사람마다 개발을 잘 하는 기준은 정말 많습니다. 풀어야 하는 문제를 명확하게 정의하고 최대한 효율적으로 풀 수 있도록 나누어서 작업을 하는것도 그 중 하나라고 저는 생각합니다. 그리고 그렇게 했을 때 몇 배로 올라가는 생산성을 경험하기도 했습니다.
지금 당장은 빠르게 작업하는 것 같다고 느껴져도 결국엔 아닌 경우는 무척 많습니다. commit을 이렇게 쪼개서 하는 작업이 당장은 귀찮을지라도 분명히 가치가 있을 것이라고 생각합니다. 특히나 문제가 복잡해지거나 팀의 규모가 커져 커뮤니케이션 비용이 많아질 수록 이런 약속들은 빛을 보인다고 믿습니다.
참조:
참조:
