3. Git?
• 뜻 머저리
• 가이드 지옥에서 온 깃 (Git from hell)
• 리누스 토발즈가 사랑하고 아끼는 리눅스 커널 개발에 쓰기 위
해 만듬. 열심히 개밥먹기 중.
• 참고로 리누스 토발즈는 요즘도 가끔 linux kernel GitHub repo에 풀리
퀘스트를 날리는 사람들에게 점잖은 비난(예전엔 욕설을 했다고 함)을
하는데, linux kernel은 GitHub의 풀리퀘스트를 사용하지 않고 자체 풀
리퀘스트 시스템에 있어서라고 한다. 일단 리누스 토발즈는 자신의 아
름다운 커널을 건드리는 사람을 굉장히 싫어한다. NVIDIA에 뻐큐를 날
린 적도 있다. 이상 잡설…
4. Git?
• DVCS(Distributed Version Control System) = branches
• Filesystem의 스냅샷을 저장
• 거의 모든 명령어를 로컬에서 처리
무튼 빠르고 여러 버전의 코드를 동시에 분산해서 관리할 수
있게 해준다.
근데 대용량의 바이너리를 처리하기엔 잼병이라는 단점이 있다.
Git LFS가 있긴 하지만 역부족… 그래서 Microsoft에서 GVFS(Git
Virtual File System)이라는 걸 만들었다. 현재 베타.
5. Git 꿀팁 목록
• 커밋 메시지 작성 요령
• Fetch? Pull?
• 커밋 변경 사항을 두고 다른 브랜치로 체크아웃하고 싶어!
• 실수로 이상한 걸 커밋해버렸어.
• 여러 커밋을 하나로 합치고 싶어.
• 어떤 커밋의 변경 사항만 가져오고 싶어!
• 커밋 메시지 수정
6. 커밋 메시지 작성 요령
• 영어로 작성시
• 제목은 명령형으로 작성한다. 50자 이내.
• 본문은 최대한 상세하게 문장형으로 서술한다.
• 한글로 작성시
• 제목은 명사형으로 작성. 50자 이내.
• 본문은 영어와 마찬가지
7. 여기서 잠깐
커밋 메시지를 영어로 작성하느냐 한국어로 작성하느냐는 사람
마다 회사마다 아직도 왈가왈부가 많다. 왜 한국 사람이 영어로
작성해야 하느냐부터… 사대주의다… 등등 다 맞는 말이다. 이건
전적으로 회사의 특성과 환경에 달려있는 문제이다. 그 회사에 영
미권 개발자가 입사할 가능성이 충분히 있거나 커밋 메시지를 읽
어야 할 사람 중 영어가 편한 사람의 비중이 클 경우는 영어로 하
는 게 좋다. 그렇지 않으면 한국어로 작성해도 상관없다. 요점은
제목은 깔끔하게. 본문은 상세하게이다.
8. Fetch vs Pull
• Fetch: Remote branch의 최신 커밋들을 로컬로 가져옴
• Pull: Fetch + ff(fast forward) to HEAD
9. 커밋 변경 사항을 두고 다른 브랜치로 체크아웃하고 싶어!
• git stash
• git stash list: 스태시 목록 출력
• git stash pop: 스태시를 다시 불러와 적용하고 리스트에서 삭제
• git stash apply: 스태시를 다시 불러와 적용
10. 실수로 이상한 걸 커밋해버렸어
• git reset
OR
• git log
• git rebase --interactive <SHA1>
• pick edit
• git add
• git commit --amend
• git rebase --continue
11. 여러 커밋을 하나로 합치고 싶어
• git rebase –i HEAD~4 (현재 커밋부터 4개)