원칙
원칙 1. staging 시 절대 git add . 을 하지 않는다.
최소한 git status 명령어를 통해 현재 staging 된 파일이 어떤 것인지 반드시 확인할 것. 커밋 전에는 add 한 내용들을 취소할 수 있으니 신중하게 커밋해야 한다.
- git reset HEAD [file] 명령어를 통해 staging 된 파일들을 취소할 수 있다.
https://gmlwjd9405.github.io/2018/05/25/git-add-cancle.html
git add . 은 무책임한 스테이징이다. 그 명령어 부터가 그냥 오늘 한 작업을 전부 커밋하겠다. 정도의 의미이다. 커밋은 최대한 쪼개야 한다. 두 가지 작업을 한 파일에서 동시에 작업하는 일이 없어야 한다.
처음부터 내가 할 업무를 명확하게 지정해놓고, 그 부분만 코딩하려고 해야 한다. 그리고 그 작업이 끝나고 테스트까지 완료한다면, 지금까지 작업한 파일들을 확인하면서, 어떤 변경이 있었는지 확인한다. 그리고 영향 없는 코드를 건드리거나 했다면 반드시 스테이지에서 제외해주어야 한다. 코드를 짜다가 관련 없는 수정을 하는 일이 없지 않다.
그러므로 스테이징을 할 때 부터 이 변경된 파일들을 확인하는 과정이 필요하다.
원칙 1-1. staging은 커밋을 하게 될 파일과 연관된다면 반드시 함께 커밋할것.
파일을 하나하나 확인하면서 현재 커밋 내용과 관련된다면 반드시 staging에 파일을 포함시켜야 한다. 놓치기 쉬운 부분이 파일명이 바뀌었거나 할 때, 다른 파일에서 import를 바꾸지 않아서 변경 파일로 안 잡힐 수가 있다. 이런 부분을 잘 파악해서 반드시 함께 staging 해주어야 한다.
원칙 2. 커밋 시 git commit -m "" 이 명령어 쓰지 말 것.
커밋을 할 떄 git commit -m "message" 이 명령어를 터미널 창에서 실행하게 되면 커밋 메시지가 길어져 한 줄 이상 입력될 경우, 돌아가서 수정이 불가능하다. 다시 다 써줘야 하는데, 사람 마음이 당연하게, 하 그냥 대충 커밋하자로 가게 된다. 특히 커밋은 업무의 마지막 과정인 경우가 많기 때문에, 얼른 끝내고 쉬고 싶은 마음이 커진다. 이렇게 되면 커밋을 대충 만드는 습관이 들게 되고, 굳어지게 된다. 차라리 업무를 시작할 때 이를 커밋하는게 낫다고 생각한다. staging 된 내용들을 확인하며 커밋 메시지를 작성해 커밋을 하고, 다음 작업을 시작하는 것이다.
원칙 2-1. 커밋 메시지 워딩(커밋 컨벤션)을 지킬 것.
prefix
feat: features
docs: documentations
conf: configurations
test: test
fix: bug-fix
refactor: refactoring
ci: Continuous Integration
build: Build perf: Performance
이 커밋이 어떤 내용을 담고 있는지 한번에 알 수 있게 하는 prefix를 사용해야 한다.
예시
feat: Create server.py to start flask project
docs: Create README.md
conf: poetry init
test: User model CRUD test complete
원칙 2-2. 대부분의 테스트 단위는 커밋 단위이다.
커밋 단위를 쪼갰는데, 테스트가 힘들어질 것 같다면 유닛테스트 단위를 잘 못 쪼갰거나, 커밋을 잘 못 설정한 것이다. 모든 커밋 단위에 유닛 테스트를 작성하고(테스트 코드가 필요할 경우), 만약 테스트 코드가 커밋 단위에 맞지 않다면, 더 쪼개거나 수정을 해야 한다.
테스트 코드를 적절하게 작성했다면, 테스트 코드를 커밋한다. 그리고 이 테스트 코드에 맞는 코드를 구현한 후 테스트를 완료하면 바로 커밋을 할 수 있다.
이렇게 커밋 단위를 맞추는 습관을 들이면 자연스럽게 TDD 까지 할 수 있게 될 것이다.
원칙 2-3. 기타
- 모두가 이해할 수 있는 log를 작성할 것.
- Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를따라 쓸 것.
- 제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가설명 할 것.
- 제목과 내용은 한 줄 띄워 분리할 것.
- 내용은 이 commit의 구성과 의도를 충실히 작성할 것.
원칙 3. ReadMe 를 작성, gitignore 신경 쓸 것.
마크다운 랭귀지에 익숙해져야 한다. 어떤 집을 가도 대문이 더럽고 지저분하면 들어가기 싫어질 것이다. 그 내부가 아무리 예쁘고 잘 되있더라도.
gitignore 을 제대로 해놓지 않으면 무신경한 사람이라는 느낌이 난다. node_modules 가 다 올라와있는 리포지토리를 보면 클론을 하고싶은 마음이 안든다. 땡겨오는데 하루종일 걸린다. 또한 gitignore을 신경쓰지 않으면 보안적으로 치명적인 파일이 딸려갈 수도 있다. aws의 암호키라던가 보안 관련된 문제가 생길 수 있다.
