git branch stregagy & case study

Branch Strategy & Case Study

NHN NEXT 김우진

GIT Structure

Working Directory

Staging Area

Local Repository

add commit

Remote Repository

Offline����������� ������������������  

Online

push

fetch  clone

checkout  merge

pull

Branch Strategy

Master

Develop

Feature

Time

: 최종 릴리즈된 안정된 브랜치(항상존재)

: 개발이 적용되고 진행되는 브랜치(항상존재)

: 특정 기능을 개발하기 위한 브랜치(이벤트성 브랜치)

HotFix Branch(긴급수정)

Case Study 1

변경내용을 확인하고 싶을 때$  git  diff  [-­‐-­‐word-­‐diff]

수정했지만 아직 Staged 상태가 아닌(add를 안한) 파일을 비교 해 볼 수 있음 Unstaged 상태인 것들만 보여준다! --word-diff : 단어단위로 보여줌

$  git  diff  -­‐-­‐staged

로컬 저장소에 커밋한 것과 Staging Area(add 한)에 있는 것을 비교해 보여줌

Case Study 2

변경내용을 로컬 저장소에 커밋하고 싶을 때$  git  commit  -­‐m  “commit  message”

커밋 메세지를 인라인으로 첨부하여 커밋할 때

$  git  commit  -­‐a  -­‐m  “commit  message”

Staging Area를 생략하고 커밋 할 때 git 에서 추적하고 있는 파일이 바뀌었을때 add를 생략하고 커밋 할 수 있음

$  git  commit  -­‐-­‐amend

완료한 커밋을 수정하고 싶을 때(파일을 빼먹거나, 메세지를 고치고 싶을 때)

Case Study 3 Staging Area에 이미 올려진 파일을 삭제하거나 이동하고 싶을 때

$  git  rm  [-­‐f]  [-­‐-­‐cached]  <file>

Staging Area에서 파일을 삭제하고 싶을 때(실제로도 지워짐, 추적 안함) 그냥 파일을 삭제하면 Unstaged(deleted)상태로 바뀜 -f : 강제로 삭제 --cached : 실제로 안지우고 싶을 때(사용자 정보같은 파일을 잘못 add했을 때)

$  git  mv  <file_from>  <file_to>

Staging Area에서 파일을 이동하거나 이름을 바꾸고 싶을때(실제로도 바뀜)

Case Study 4

커밋 히스토리를 조회하고 싶을 때$  git  log  [-­‐p  [-­‐-­‐word-­‐diff]]  [-­‐2]

로컬 저장소의 커밋 히스토리를 조회 할 때 -p : 각 커밋의 diff결과를 보고 싶을 때 --word-diff : 단어단위로 diff결과를 보고 싶을 때 -2 : 최근 2개의 결과만 보고 싶을 때

$  git  log  [-­‐-­‐stat]  [-­‐-­‐oneline]  [-­‐-­‐graph]

--stat : 히스토리의 통계를 보고 싶을 때(요약정보는 가장 뒤쪽에) --oneline : 각 커밋을 한줄로 보고 싶을 때 --graph : 브랜치와 머지 히스토리를 보여주는 그래프를 보고 싶을 때

$  git  log  [-­‐-­‐since=2.weeks]  [-­‐-­‐author=woogenius]

--since=2.weeks : 최근 2주의 커밋만 조회하고 싶을 때 after, until, before 도 쓸수 있고 “2008-11-01”같은 날짜도 쓸 수 있음

--author=woogenius : woogenius의 커밋만 조회하고 싶을 때

Case Study 5

파일상태를 되돌리고 싶을 때$  git  reset  HEAD  <file>

Staging Area에 있는 파일을 Unstage상태로 변경하고 싶을 때(실수로 add)

$  git  checkout  -­‐-­‐  <file>

수정된 파일을 최근 커밋한 내용으로 되돌리고 싶을 때

커밋개체����������� ������������������  깃에서 커밋을 하면 저장되는 커밋 개체는 이전 커밋에대한 포인터를 포함한다.

브랜치����������� ������������������  브랜치란 특정커밋을 가리키는 포인터다.

브랜치는 해당 브랜치에서 커밋을 하면 바뀐다.

HEAD����������� ������������������  HEAD라는 포인터는 지금 작업하는 로컬브랜치를 가리킨다.

Branch?

Case Study 6

브랜치를 만들고 이동하고 삭제하고 싶을 때

$  git  branch  <branch>

현재 브랜치에서 파생된 브랜치를 만들고 싶을 때(이동하지 않음)

$  git  branch  -­‐d  <branch>

merge를 했거나 필요없어진 브랜치를 삭제하고 싶을 때 특정 커밋을 가리키는 포인터를 지우는 것(다시 그상태로 갈 수 없음)

$  git  checkout  <branch>

현재브랜치에서 다른브랜치로 이동하고 싶을 때

$  git  checkout  -­‐b  <branch>

현재 브랜치에서 파생된 브랜치를 만들고 그 브랜치로 이동하고 싶을 때 branch와 checkout명령을 합친 것

Case Study 7

두개의 브랜치를 합치고 싶을 때$  git  merge  <branch>

현재 브랜치와 대상 브랜치를 합치고 싶을 때 각 브랜치가 가리키는 커밋 두개와 공통조상 하나를 사용하여 3-way Merge함 결과를 별도의 커밋으로 만들고 해당 브랜치가 그 커밋을 가리키도록 이동시킴 Merge로 생성된 커밋은 부모가 여러개임

C4에 있던 master브랜치에서 iss53브랜치를 Merge하면

Case Study 8

깔끔하게 Merge하고 싶을 때

$  git  rebase  <base  branch>  [<topic  branch>]

<topic branch>를 <base branch>에 rebase하는 명령 topic branch에서 topic branch를 생략 할 수 있음 변경사항을 patch로 만들어 base branch에 적용하는 식으로 Merge함 Merge와 결과는 같지만 커밋 히스토리는 다름 이미 push한 커밋을 rebase하면 문제가 생길 수 있음(혼자만 쓰기!)

$  git  rebase  master  experiment     (Rebase)

$  git  checkout  master  $  git  merge  expreiment     (Fast-­‐Forward)

C3에 있던 experiment 브랜치에서 실행

Merge VS Rebase

Merge Rebase

<<<<<<<  HEAD:index.html  <div>  contact  :  email.support@github.com  </div>  =======  <div>  please  contact  us  at  support@github.com  </div>  >>>>>>>  iss53:index.html

충돌이 일어나면?

git status에서 파일이 unmerged 상태가 된다. 그 파일을 열어서 수동으로 해결한다.

위아래 내용 중 고르거나 새로작성하여 Merge한다.

<div>  please  contact  us  at  email.support@github.com  </div>

Case Study 9

브랜치를 목록을 보고 싶을 때

$  git  branch  [-­‐v]  [-­‐a]  [-­‐r]

로컬 브랜치의 목록과 현재 HEAD의 위치를 보여줌 -v : 브랜치마다 마지막 커밋 메세지도 함께 보여줌 -a : 리모트 브랜치와 로컬 브랜치 목록을 모두 보여줌 -r : 리모트 브랜치 목록만을 보여줌

$  git  branch  -­‐-­‐merged

merge한 브랜치 목록을 보고 싶을 때 *이 붙어있지 않은 브랜치는 이미 merge된 것이므로 삭제해도 됨

$  git  branch  -­‐-­‐no-­‐merged

merge하지 않은 브랜치 목록을 보고 싶을 때 merge하지 않은 브랜치를 강제로 삭제하려면 git branch -D로 삭제함

Local Branch !

로컬 저장소에만 존재 !형식

<branch> !

마음대로 조종 가능 !

git push <remote> <branch> 명령으로 서버에 전송한다.

!로컬저장소에만 있는 브랜치를

만들 수 있다.

Remote Branch !

로컬과 리모트 저장소에 존재 !형식

<remote>/<branch> !

마음대로 조종 불가 !

git fetch <remote> 명령으로 로컬과 리모트 저장소를 동기화 시킨다.

!fetch하기 전엔 로컬과 리모트 저장소의 리모트 브랜치가 다를 수 있다.

로컬과 리모트 브랜치는 독립적이다!

Case Study 10

리모트 브랜치를 수정, 삭제하고 싶을 때

$  git  push  <remote>  <branch>

로컬 브랜치를 서버에 저장하고 싶을 때 서버에 로컬 브랜치와 이름이 같은 브랜치가 있다면 반영되고 없다면 새로만듦

$  git  push  <remote>  <local  branch>:<remote  branch>

로컬 브랜치를 다른이름의 리모트 브랜치로 저장하고 싶을 때

$  git  push  <remote>  :<remote  branch>

리모트 브랜치를 삭제하고 싶을 때 <local branch>부분을 비웠으므로 빈 브랜치를 <remote branch>에 넣어라 가 됨

Case Study 11

리모트 브랜치를 로컬로 가져오고 싶을 때

$  git  fetch  <remote>

리모트 브랜치정보를 로컬 브랜치에 동기화 시키고 싶을 때

$  git  pull  [-­‐-­‐rebase]  <remote>  <branch>

리모트 브랜치를 가져와 로컬 브랜치에 Merge시키고 싶을 때 fetch 와 merge를 한꺼번에 함 --rebase : fetch 후에 rebase를 함

$  git  merge  <remote  branch>

새로받은 리모트 브랜치의 내용을 현재 브랜치에 merge하고 싶을 때

$  git  checkout  -­‐b  <branch>  <remote  branch>

리모트 브랜치를 추적하는 로컬 브랜치를 만들고 싶을 때(수정하고 싶어서) 트랙킹 브랜치는 연결고리가 있어서 pull, push의 장소를 명시 할 필요 없음

Fetch VS Pull

C0 C1 C2 C3 C4

master

Remote Repository

Local Repository

C0 C1 C2 C5 C6

origin/master

master

Local Repository

C0 C1 C2

C3 C4origin/master

C5 C6

master

Local Repository

C1 C2

C3 C4

origin/master

C5 C6 master

C7

Fetch Pull

Working Directory의 내용이 바뀌지 않으므로 차례로 확인하며 Merge하고싶을때 사용한다.

Working Directory의 내용이 바뀌므로 수정을 안했거나 수정한 내용이 명확할때 사용한다.

Pull Rebase?

C0 C1 C2 C3 C4

master

Remote Repository

Local Repository

C0 C1 C2 C5 C6

origin/master

master

Local Repository

Pull����������� ������������������  --rebase

C0 C1 C2 C3 C4 C5’ C6’

master

origin/master

참고자료http://git-scm.com/book/ko/

http://nvie.com/posts/a-successful-git-branching-model/