오늘 git 브랜치 관련한 특강을 받았다… 그동안 git 을 몰라도 너무 모르고 있었다는 생각이 들었다.
브랜치 생성
레드 마인을 사용하고 있다면 feature, bug 와 같이 생성된 이슈에 맞춰 새롭게 브랜치를 생성하자.
생성하는 브랜치 이름은 “feature/이슈번호-이슈제목”, “bug/이슈번호-이슈제목” 와 같이 지정하면 좋다.
브랜치 이름에는 브랜치를 생성한 이유가 나타나야 한다.
그리고 하나의 브랜치에서 너무 많은 작업들을 하려고 하는 것은 좋지 않다.
너무 큰 크기의 수정 작업은 잘게 잘라서 여러 개의 브랜치에서 나눠할 수 있도록 하자.
커밋
한번에 하나의 내용만을 지정하여 커밋을 하자.
Fixed a lot.
– Fixed many.
과 같은 내용은 정말로 좋지않다!!!(실은 내가 자주 그랬다.)
Fixed memory leak.
– valgrind test complete.
위와 같은 커밋을 보면 메모리 누수를 valgrind 를 통해서 잡았다는 것을 알 수 있다.
그러면 당연히 수정 내용에는 메모리 할당/해제와 관련된 내용만 있을 것이다.
만약 메모리 할당/해제가 아닌 다른 기능 추가와 같은 내용들이 들어가게 되면 이는 커밋의 내용과는 맞지 않는 것이다.
당연히 코드를 리뷰하는 사람의 입장으로서는 의문이 생기고 수정 내용이 이해가 안되게 된다.
각각의 브랜치는 저마다의 정확한 목적을 가지고 있어야 한다.
그리고 각각의 커밋은 커밋의 정확한 이유가 있어야 한다.
코멘트
소스를 수정한 구체적인 이유를 적자.
예를 들어 다음과 같은 예를 들어보자.
Added snom phone functionality
– Added snome specification
Added: snom_function.c, snome_function.h, aastra.c
위와 같은 커밋에서 코멘트는 snom phone 기능을 추가했다고 하였다. 하지만 추가된 소스코드에는 aastra.c 파일이 껴 있다.
이상한 일이다. snom 폰과 aastra 폰은 서로 다른 전화기 이기 때문이다.
잘못된 커밋 옵션으로 파일이 추가된 것일지도 모른다.
즉시 aastra.c 파일을 추가한 이유를 물어볼 수 있다.
