베스트 프랙티스

1. commit 하기 전에 git diff로 코드 리뷰 (버그 방지)

• git add --patch
• git diff --cached

2. 작고, 논리적인 커밋 (일찍 자주하기)

• 잘 관리된 저장소의 커밋 로그는 하나의 스토리다

• git status와 git diff로 변경사항 리뷰시 단일한 논리적 단위, 단순한 문장으로 설명 되어야함.

• 크게 뭉쳐있는 커밋의 단점

  • "이슈#123 : 비디오 시리즈를 위한 프로그레스바 추가" vs "이슈#123 : 프로그레스바를 위한 jQuery라이브러리 업데이트"
  • 코드의 히스토리가 무용지물이됨, 코드 개발 절차가 묻혀버림.
  • 디버깅시에 커밋 단위가 잘게 나눠져있는 편이 어떤 라인에서 버그가 발생했는지 알기 용이함

• 가이드라인

  • 절대 하나의 커밋에 여러개의 모듈들을 묶어 넣지 않는다. (여러 모듈이 타이트하게 커플링관계가 아닌 이상)
  • 새 모듈을 작성할때 그루터기 함수들을 먼저 작성하고, 돌아와서 그 것들을 채워넣는다.
  • 항상 API레벨의 함수들을 작성하고 커밋한다. (그 것들을 사용하는 함수들을 작성하고 커밋하기전에)
  • 브랜치와 관련없는 버그 픽스들을 새 브랜치의 별도의 커밋으로 분리한다.

3. 명령어를 위한 alise를 사용할 것 (~/.gitconfig에 추가)

[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr, %cn)%Creset' --abbrev-commit --date=relative
hist = log --graph --pretty=format:'%h %ad | %s%d [%an]' --date=short
last = log -1 HEAD
unstage = reset HEAD --
amend = commit --amend -C HEAD
co = checkout
ci = commit
st = status
br = branch

4. 깨끗한 커밋 히스토리를 남겨라 git merge를 많이 쓰게되면 커밋 히스토리를 읽기 어려워짐 (git rebase와 git merge의 조합을 사용할 것)

• push 전에 rebase

5. 용도에 알맞게 pull request를 사용하라.

• 팀원들이 무엇이 어떻게 돌아가는지 알 수 있게 해줌 (변경사항 추적, 커밋 연계, 개발 중 협업, 머지 전 코드 리뷰)
• 머지 커밋이 눈에 띄는게 유일한 단점이긴 하지만, 팀으로 일할 때 이 점은 상쇄된다.

6. 절대 공유된 커밋은 리베이스 하지 말라

• 규칙 : 한 번 원격 저장소에 푸쉬한 커밋은 리베이스하지 않기
• 이렇게 하면 다른 사람들의 코드를 망가뜨리지 않게 해주고, 내가 수정한 버그나 실수의 로그도 보존시켜준다.

--

http://kentnguyen.com/development/visualized-git-practices-for-team/

rebase 의 쉬운 정의 : 마지막 푸쉬 부터 로컬의 변경 사항들을 다른 사람들의 변경 사항들 앞에 놓는것. 브랜치 나누기, 자주 머지하고, 싱크를 유지하기

• 나중에 머지할때 복잡함을 방지하기 위해 지속적으로 master를 머지
• 커밋, 머지를 자주 할 것 http://kentnguyen.com/wp-content/uploads/2012/01/git_merge_often.png

좀 더 나은 Git 사용을 위한 명령어들

merging vs rebasing

git rebase는 git merge와 같은 문제를 해결하기 위한 것. 브랜치의 변경사항을 다른 브랜치에 병합. https://www.atlassian.com/git/images/tutorials/advanced/merging-vs-rebasing/01.svg 위 그림 처럼 master branch에서 갈라져 나온 이슈 브랜치에서 작업을 하고 있는데, Master 브랜치가 변경 되었다면 변경 사항 반영을 위해 rebase 또는 merge를 택할 수 있음

git checkout feature git merge master

이렇게 하면 머지됨 https://www.atlassian.com/git/images/tutorials/advanced/merging-vs-rebasing/02.svg

이런 형태로 추가적인 커밋이 하나 추가된 것을 볼 수 있음 머지의 장점은 비파괴적, 기존에 존재하던 브랜치는 아무것도 바뀌지 않았음.

rebasing이 가지고 있는 잠재적 위험 요인을 방지함. 반면에 정돈되지 않은 머지 커밋들이 늘어나면 다른 개발자가 히스토리를 읽기 어려워질 수도 있음.

리베이스의 경우

git checkout feature git rebase master

feature 브랜치 전체를 마스터 브랜치의 끝으로 이동하고, 마스터 브랜치의 모든 새로운 커밋을 반영함. 머지와 달리 새로운 커밋들을 생성하면서 히스토리를 다시 쓰게됨

https://www.atlassian.com/git/images/tutorials/advanced/merging-vs-rebasing/03.svg 이미지는 이와 같음

장점은 깨끗한 히스토리를 얻게됨, 완전히 선형적인 구조이기 때문에 git log, git bisect, git gitk등으로 탐색하기가 쉬움

이렇게 새 것같은 커밋 히스토리에는 트레이드오프가 있음 히스토리를 다시 씀으로 잠재적으로 협업 워크플로우에 큰 지장을 초래할 수 있음

--

인터랙티브 리베이싱 https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC-%EB%8B%A8%EC%9E%A5%ED%95%98%EA%B8%B0#_squashing

--

commit 을 가리키는 상대적인 방법 ^ : 부모 ^숫자 : 숫자번째 부모 (머지 커밋에만 사용 가능) ~ : 부모 ~숫자 : 숫자번째 부모 (조부모) 예제 : https://www.atlassian.com/git/images/tutorials/advanced/refs-and-the-reflog/02.svg

--

되돌리기 (reset, checkout, revert)

reset 브랜치의 끝을 다르 커밋으로 이동하는 것. 다음과 같이 커밋들을 지우는데 사용 가능함.

git checkout hotfix

git reset HEAD~2

이렇게 하면 끝의 두 커밋은 댕글링 커밋(가비지 컬렉션 대상)이 된다. https://www.atlassian.com/git/images/tutorials/advanced/resetting-checking-out-and-reverting/02.svg

--soft : 커밋 히스토리에만 영향을 주고, 스테이지나 워킹 디렉 토리에는 영향을 주지않음 --mixed : 기본값, 커밋 히스토리와 스테이지 영향을 줌 --hard : 커밋 히스토리, 스테이지, 워킹디렉토리 모두에 영향을 줌 .

가장 많이 쓰는 경우

• git reset --mixed HEAD^ : 최근 커밋 취소 (스테이징도 함께 취소)

--

checkout 브랜치 대신 커밋 주소를 통해 check out 가능. 브랜치의 경우와 마찬가지로 똑 같은 일을 함. HEAD참조를 특정한 커밋으로 옮김. 예를 들면 다음 명령은 현재 커밋의 조부모로 체크아웃 함.

git checkout HEAD~2

https://www.atlassian.com/git/images/tutorials/advanced/resetting-checking-out-and-reverting/05.svg

오래된 버전의 프로젝트를 살펴볼때 유용하지만, 현재 HEAD를 가리키는 브랜치 참조가 없어서 deteched HEAD 상태가 됨. 커밋을 하고 다른 브랜치로 스위칭을 하면 변경 사항들을 잃어버릴 수가 있음, 때문에 커밋할때 새로운 브랜치를 생성하는게 좋음.

--

revert 새로운 커밋을 생성하여 되돌리기를 하는 방법, 커밋 히스토리를 건드리지 않기 때문에 안전

git revert HEAD~2

https://www.atlassian.com/git/images/tutorials/advanced/resetting-checking-out-and-reverting/06.svg

--

stash https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Stashing%EA%B3%BC-Cleaning

--

참고자료

• https://sethrobertson.github.io/GitBestPractices/
• http://chriskottom.com/blog/2014/02/a-few-modest-best-practices-for-git/
• https://www.lullabot.com/articles/git-best-practices-workflow-guidelines