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

Git 꿀팁

  • 1.
  • 3.
    Git? • 뜻 머저리 • 가이드  지옥에서 온 깃 (Git from hell) • 리누스 토발즈가 사랑하고 아끼는 리눅스 커널 개발에 쓰기 위 해 만듬. 열심히 개밥먹기 중. • 참고로 리누스 토발즈는 요즘도 가끔 linux kernel GitHub repo에 풀리 퀘스트를 날리는 사람들에게 점잖은 비난(예전엔 욕설을 했다고 함)을 하는데, linux kernel은 GitHub의 풀리퀘스트를 사용하지 않고 자체 풀 리퀘스트 시스템에 있어서라고 한다. 일단 리누스 토발즈는 자신의 아 름다운 커널을 건드리는 사람을 굉장히 싫어한다. NVIDIA에 뻐큐를 날 린 적도 있다. 이상 잡설…
  • 4.
    Git? • DVCS(Distributed VersionControl 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개)
  • 12.
    어떤 커밋의 변경사항만 가져오고 싶어! • git cherrypick
  • 13.
    커밋 메시지 수정 •git log • git rebase --interactive <SHA1> • pick  edit (파일 수정 안하고 커밋 메시지만 수정) • git add • git commit --amend • git rebase --continue
  • 14.