Git best practice

<커밋>

커밋 시 깔끔하게 단 하나의 목적으로 하자

어떤 한 가지(오류 수정, 기능 개발 등)의 작업을 할 때 유혹에 넘어가지 말자

버그를 수정할 때 또 다른 버그가 발견이 되면 그 버그도 하나의 커밋에 담으려고 한다.

결국엔 스노우 볼이 굴러가 하나의 커밋에 너무 많은 변경 사항이 적용된다!

다음과 같은 이유로 커밋을 작게 하는 것이 좋다

• 다른 팀원들이 코드 리뷰를 하는데 훨씬 보기 쉬워진다.
• 커밋을 롤백해줘야 하는 경우 더 쉬워진다.
• 변경 사항 추적이 쉬워진다.

의미있는 커밋 메시지를 남기자

좋은 예
feat: add beta sequence
^--^  ^---------------^
|     |
|     +-> 현재형으로 간추린다.
+-------> Type: chore, docs, feat, fix, refactor, style, or test...

커밋을 일찍 자주하자

깃은 작업들을 자주 커밋하는 것이 좋다.

커밋이 완변히 될 때까지 기다리는 대신, 작은 덩어리로 나누어 커밋을 하는 것이 좋다.

이미 올린 커밋을 다시 변경하지 말자

커밋이 업스트림 디폴트 브랜치(develop branch)에 머지가 되면 해당 커밋을 변경하지 않는 것이 좋다.

Git은 branch history를 변경할 수 있지만, 다른 팀원에게 또는 오픈소스 프로젝트 인 경우에는 문제가 될 수 있다.

git-rebase 는 유용한 기능이지만, 오직 혼자 작업하는 브랜치에 사용해야 한다.

만약 꼭 필요하다면 주의가 필요하다!

생성된 파일들을 커밋하지 말자(e.g. django 테스트시 생기는 미디어 파일)

.gitignore 에 넣어두자

커밋 시 author를 구성하자

적어도 커밋시 이메일과 이름은 구성하도록 하자

커밋은 커뮤니케이션 툴이기 때문에, 누가 작성했는지 추척할 수 있어야 나중에 도움이 된다.

git blame <file_name> : 코드라인별로 변경사항 보기

╭─ ~/Documents/GitLab/Project base --- 13:21:24
╰─❯ git blame Dockerfile
# | 마지막 커밋 | 커밋의 author | 타임 스탬프            순으로 확인이 가능하다
a65b3d7e (wookkl 2021-08-18 17:35:18 +0900  1) FROM ubuntu:18.04
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  2)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  3) MAINTAINER wookkl
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  4)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  5) ADD . /code/
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  6)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  7) RUN pip install -r /code/requirements/prod.txt
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  8)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900  9) RUN chown -R www-data:www-data /code
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 10)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 11) RUN ln -s /code/nginx.conf /etc/nginx/sites-enabled/
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 12) RUN ln -s /code/supervisor-app.conf /etc/supervisor/conf.d/
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 13)
b27773d1 (wookkl 2021-08-20 00:03:07 +0900 14) RUN mkdir -p /var/log/django/ && \
b27773d1 (wookkl 2021-08-20 00:03:07 +0900 15)     mkdir -p /var/log/gunicorn/
b27773d1 (wookkl 2021-08-20 00:03:07 +0900 16)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 17) RUN touch /var/log/django/user_request.log
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 18) RUN chown www-data:www-data /var/log/django/user_request.log
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 19)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 20) WORKDIR /code
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 21)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 22) EXPOSE 80 22
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 23)
8cec8207 (wookkl 2021-08-18 16:48:00 +0900 24) CMD supervisord -n

깃헙이나 깃랩 경우에는 알아서 누가 커밋했는지 이력이 남음

작업 브랜치를 주기적으로 rebase하자

항상 최신의 코드를 유지하기 위해 rebase하는 것은 중요하다.

• 버그를 고치고 있는 와중애 누군가 이미 고쳤을 수도 있다.
• 버그, conflict 방지 등을 예방해야 한다.

로컬 구성 파일을 커밋하지 말자

각각 로컬의 환경하다 세팅이 다를 수 있기 때문에 로컬용 구성 파일을 올리지 않는 것이 좋다

e.g. QA와 프로덕션 환경의 로컬 구성은 다를 수 있다.

커밋 하기전에 꼭 테스트를 하자

코드에 변경사항이 있을 떄 꼭 테스트 해야 한다.

테스팅은 하나의 보안 계층 으로 보자!

hash값으로 커밋을 참조하자

어떠한 이유로 해당 커밋은 언급할 일이 있을 땐 해당 commit의 hash을 참조해서 커밋 메시지에 적는 것이 좋다.

 

커밋 메세지에 링크다는 법

Autolinked references and URLs - GitHub Docs

---

<Pull Request>

• '내가 작업한 코드가 있으니 pull해서 확인 후 머지해주세요' 라는 의미

하나의 풀 리퀘스트는 하나의 이슈만 담자

풀 리퀘스트는 아토믹하게 하나의 기능만 담아 요청해야한다. 좀 더 효율적으로 코드 리뷰를 받을 수 있고 팀 내에 생산성이 향상된다.

풀 리퀘스트를 미루지 말자

풀 리퀘스트를 미루게 되면 코드 퀄리티는 줄어들며, conflict가 날 확률이 높아진다.

풀 리퀘스트를 올리기 전에 작업을 모두 완료하자

작업을 다 마치지 않은 상태에서는 풀 리퀘스트를 올리지 말자

그리고 풀 리퀘스트가 커질 경우, 기능 단위로 나누자

---

<작은 팀을 위한 best practices>

로컬 레포지토리의 코드 베이스를 깔끔하게 유지하자

깃 커맨드로 레포지토리를 깔끔하게 유지할 수 있다.

• git-gc: 저장소에 필요없는 파일을 삭제하고 남은 파일을 압축해준다. (기본적으로 git 이 자동으로 해줌)
• git-prune: 로컬에서 모든 참조하지 않는 파일들을 정리해준다

git prune

diff 를 사용하자

커밋 전에 항상 변경사항을 확인하도록 한다.

• 새로운 변경사항이 정확히 무엇인지 이해하는데 도움이 된다.

git stash 할 때 메시지와 함께 사용하자

git stash save “Your meaningful stash message”.

→ 실제로 stash list 볼 때 헷갈릴 때가 가끔 있었음

기능 추가할 때 리팩터링 커밋을 섞지 말자!

신입 개발자가 하는 최악의 행동은 새로운 기능 추가 커밋에 리팩터링을 하는 것이다.

해결할 수 없는 conflict가 생길 가능성이 높아진다!

---

깃을 게임처럼 배울 수 있는 사이트

Learn Git Branching

참조
https://deepsource.io/blog/git-best-practices/

https://acompiler.com/git-best-practices/