Git 회사발표 자료입니다.

1. git?

2. 리눅스 커널 프로젝트 소스 관리
patch 및 압축 Bitkeeper git
2002 2005
• 초기 부터 2002년까지 패치 및 압축으로 소스 관리
• 2002년 부터 DVCS를 사용(Bitkeeper)
• Bitkeerper와 관계가 틀어짐
• 리누스 토발즈가 git 개발
• 2005년부터 지금까지 git 사용

3. git의 목표
• 빠른속도
• 단순한 구조
• 비선형적인 개발 ( 동시 다발적인 브랜치)
• 완벽한 분산
• 리눅스 커널 같은 대형프로젝트에 유용할 것

4. 그래서 왜 git을 써야하는데?

5. SVN 구조
저장소사용자
commit

6. SVN 구조
저장소사용자
commit

7. git 구조
저장소
local
commit

8. git 구조
저장소
local
commit
원격 저장소
push

9. git 구조
저장소
local
commit
원격 저장소
push

10. SVN 파일 저장방식
각 파일에 대한 변화(델타)를 저장하는 방식
델타 : A파일과 B파일사이의 다른부분
델타파일 = 패치파일
델타

11. git 파일 저장방식
파일의 변화를 스냅샵으로 저장
변경하지 않는 파일은 이전 스냅샷 링크
이전 스냅샷 링크 스냅샷

12. 1kb
0.1
kb
0.1
kb
0.1
kb
0.1
kb
1kb 1kb1kb1kb 1kb
1.4 kb
5 kb
SVN
git
파일크기

13. 1kb
0.1
kb
0.1
kb
0.1
kb
0.1
kb
1kb 1kb1kb1kb 1kb
1.4 kb
5 kb
SVN
파일크기
1kb
git
gzip(delta file)
특정시점에 GC가 발생
마지막 리비젼 스냅샷만두고
델타파일로 변경 후 gzip 압축

14. SVN : version 4 가져오기
기초파일을 기준으로 지금까지 변경한 델타 파일을 비교하면서 파일 완성
기초파일

15. git : version 4 가져오기
스냅샷 파일만으로 완성
이전 스냅샷 링크 스냅샷

16. 깃은 빠르다
git 공식홈페이지 참조

17. git 3가지 상태
Working
Directory
Staging
Area
.git directory
Repository
git add
git commit
git checkout
git commit -a
modified staged committed
• untracked : 추적하지 않는 신규 파일
• tracked : 추적하는 파일
• modified : 파일이 수정된 후 add / commit 하지 않은 상태
• staged : 현재 파일을 곧 commit 할것이라고 표시한 상태
• committed : 안전하게 repository에 반영된 상태

18. Staging area ?
• Index area
• 이건 왜 필요한가?
• 일부분만 commit 할 때
• 충돌을 해결할 때
• commit을 다시 할 때

19. add
commit
merge
rebase
reset
pull
push
log
stash
config
init
checkoutbranch
diff
clone
fetch
remote
cherry-pick
status

20. git fetch
commit-0 commit-1
master
commit-2
commit-3
commit-4
FETCH_HEAD
commit-5
pull = fetch + merge

21. HEAD
현재 브랜치의(작업중인)
마지막 commit
commit-0 commit-1
master
commit-2
commit-3
HEAD
dev
commit-4

22. git status
로컬 저장소의 상태를 확인
변경된 파일의 상태
현재 브랜치 이름

23. git stash
• 워킹 디렉토리에 있는 unstaged 파일을 백업하고 워킹디렉토리를
깨끗한 상태로 만드는 명령어
• git stash list
• git stash pop (or apply)

24. merge
commit-0 commit-1
master
HEAD
commit-2
git commit
git commit
git commit

25. merge
commit-0 commit-1
master
commit-2
git checkout -b dev
git commit
git commit
commit-3
HEAD
dev
commit-4

26. merge
commit-0 commit-1
master
commit-2
git checkout master
git merge dev
HEAD
dev
commit-4commit-3
fast-forward

27. merge
commit-0 commit-1
master
commit-2
commit-3
HEAD
dev
commit-4
commit-5
master 브랜치에서도 새로운 commit이 발생!

28. merge
commit-0 commit-1
master
commit-2
commit-3
HEAD
dev
commit-4
commit-5
merge
commit
불필요한 commit object가 생성
git checkout master
git merge dev

29. rebase
commit-0 commit-1
master
commit-2
commit-3
HEAD
dev
commit-4
commit-5
commit-3의
base commit

30. rebase
commit-1 commit-2
master
commit-5
HEAD
dev
commit-4commit-3
commit-3의
base commit
fast-forward
git checkout dev
git rebase master

31. 그건 이미 알겠고
그래서 왜 git을 써야하는데?

32. branch
모든 버전 관리 시스템은 브랜치를 지원한다.
개발을 하다보면 코드를 여러개로 복사해야하는 일이 자주생긴다.
코드를 통째로 복사하고 나서 원래 코드와 상관없이 독립적으로 개발을 진행 할수 있는데
이렇게 독립적으로 개발 하는것이 브랜치다.
pro git

33. 메인라인 브랜치
master
충현
branch
길주
branch
동주
branch

34. 기능별 브랜치
master
통합
branch
feature1
branch
feature2
branch

35. 상태 브랜치
pu
branch
next
branch
master
branch
maint
branch
git 프로젝트에서 사용하는 브랜치
개발자
branch
pu : 기능 제안 관련 커밋 포함
next : master 브랜치에 포함되기전 안정성 테스트 할 커밋을 포함
master : 다음 릴리즈에 추가 할 커밋을 포함
maint : 가장 최신화 된 릴리즈버젼의 git 코드와 유지보수용 추가 커밋을 포함

36. 브랜치 전략
master hotfix stage dev feature1 feature2

37. dev, feature
dev feature1 feature2
merge

38. stage
dev feature1 feature2
merge
stage
merge

39. master
dev feature1 feature2stage
merge
master
merge
merge
merge

40. hotfix
dev feature1 feature2stagemaster hotfix

42. The End