4. git branch 이해하기!

git Branch

왜 쓰지??

이렇게 열심히 개발을 하고 있는데!!

ㅇㅋㅇㅋ는 개뿔 ㅋㅋㅋ 이거 사실 굉장히 난감한 상황이다. 

버그가 있어서 빨리 고쳐야 되는데 이미 내 코드는 내가 새롭게 개발하는 내용들이 수두룩... 하기 때문이다. 그럼 내가 버그 수정한답시고 고치고 반영해버리면 내가 지금 개발하던 내용들까지도 전부 반영이 되는 것이다. ㅎㄷㄷ....

이건 당하게 되면 ... 진짜 개발자로서 한숨이 나오면서

"누가 정한거냐?" 부터 시작해서 " 의사소통은 누구랑 했느냐", "왜 결정됐느냐" 부터 시작해서 엄청 열받는 상황인것 뿐 아니라. 브랜치를 안 쓰고 그냥 master branch 에 코드를 전부 때려박는 경우 코드를 찾아서 되돌리는게 정말 보통일이 아니게 된다...

이때 git branch 전략을 잘 짜서, 잘 사용하면 이러한 문제를 어느정도 해결할 수 있다.

(말 그대로 전략을 잘 짜고, 잘 써야한다. 팀에서 아무런 기준도 정하지 않고 막 쓰면 이런 효과를 절대 볼 수 없을 것이다.

git branch 사용하기

➜  git-study git:(master) git branch
* master
➜  git-study git:(master) cat .git/refs/heads/master 
b8985fa4ba72d7797cd0f66934c38bdb6313ad05
➜  git-study git:(master) git branch license
➜  git-study git:(master) git branch
  license
* master
➜  git-study git:(master) git checkout license 
Switched to branch 'license'
➜  git-study git:(license) git branch
* license
  master
➜  git-study git:(license) git checkout master
Switched to branch 'master'
➜  git-study git:(master) git branch
  license
* master
➜  git-study git:(master) git checkout -b teaser
Switched to a new branch 'teaser'
➜  git-study git:(teaser) git branch
  license
  master
* teaser
➜  git-study git:(teaser) cat .git/refs/heads/teaser 
b8985fa4ba72d7797cd0f66934c38bdb6313ad05

지금 위에 branch 목록들의 refs 를 찍어보면 master의 id 를 가르킨다는 것을 알 수 있다. license 브랜치를 만들때 HEAD 를 참조하고 HEAD 가 master 를 참조하니까, teaser 브랜치를 만들때 HEAD 를 참조하고 HEAD 가 master 를 참조하니까! 같은 id 를 가르킨다.

➜  git-study git:(license) git branch
* license
  master
  teaser
➜  git-study git:(license) vi LICENSE
➜  git-study git:(license) ✗ git add LICENSE 
➜  git-study git:(license) ✗ git status
On branch license
Changes to be committed:
  (use "git reset HEAD ..." to unstage)

	new file:   LICENSE

➜  git-study git:(license) ✗ git commit -m "add LICENSE file"
[license 87fd830] add LICENSE file
 1 file changed, 1 insertion(+)
 create mode 100644 LICENSE
➜  git-study git:(license) git status
On branch license
nothing to commit, working directory clean
➜  git-study git:(license) git checkout master
Switched to branch 'master'
➜  git-study git:(master) ls
README.md
➜  git-study git:(master) git merge license
Updating b8985fa..87fd830
Fast-forward
 LICENSE | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 LICENSE
➜  git-study git:(master) ls
LICENSE   README.md

위 작업에 대한 설명을 하자면

1. license branch 로 이동한다.

2. LICENSE 라는 파일을 만들어 작성후 저장한다. project home ( git project root folder ) 에서 ls 로 파일 리스트를 보면 LICENSE 라는 파일이 추가 됨을 볼수 있다.

3. 다시 master 브랜치로 와서 보면 LICENSE 파일은 없다.

4. merge 를 하면 LICENSE "Updating b8985fa..87fd830" 라는 메시지가 뜨며 파일이 추가 됨을 볼 수 있다.

Updating b8985fa..87fd830 이 메시지의 의미가 굉장히 중요한데... 이건 두 브랜치의 base 브랜치가 동일한 경우에 이러한 프로세스가 진행된다. 이러한 merge 를 fast forward merge 라 한다.

3-way merge commit

 - 현재 HEAD 는 master branch 를 가르키고 있음

 - 각각의 작업을 동시에 작업하기 위하여 각 작업을 위한 branch 를 별도로 생성

➜  git-study git:(speaker) git status
On branch speaker
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

	modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")
➜  git-study git:(speaker) ✗ git add index.html 
➜  git-study git:(speaker) ✗ git commit -m "edit index.html"
[speaker f7f3b11] edit index.html
 1 file changed, 204 insertions(+), 4 deletions(-)
➜  git-study git:(speaker) git checkout master
Switched to branch 'master'
➜  git-study git:(master) git merge speaker
Merge made by the 'recursive' strategy.
 index.html | 208 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 204 insertions(+), 4 deletions(-)

사실 지금의 경우 auto merge 가 되었는데 동일 파일이 수정된 경우 conflict 가 날 수도 있다. 이때는 파일에 <<<<<<< HEAD 과 같은 표시로 되며 이 경우에는 conflict 가 난 실제 파일을 직접 수동으로 보고 고쳐야 한다.

바로 직전에 커밋 변경하기 ( --amend )

실수로 일부 파일이 누락되어 커밋된 경우

커밋 메세지를 잘못 작성한 경우 등

$ git commit --amend

merge commit에는절대 사용지 말것

커밋 되돌리기

Working tree 를 유지하며 되돌리기 ( --mixed ) < default option

$ git reset {commit_id}

즉, 지금가지 커밋쳤던 여러개의 커밋들을 변경된 파일을 unstaged 상태로 되돌려, 다시 하나의 커밋 메시지로 통합하고 싶을 때 유용함.

Working tree, index( staging area) 를 유지하며 되돌리기

$ git reset --soft {commit_id}

만약에 git reset 을 하고 git add --all 을 어차피 할거라면 차라리 --soft 명령어를 써서 index 저장소 변경된 내용이 저장된 상태로 되돌리도록 하자. 즉, soft 옵션은 변경된 내역을 index 에 저장시켜 놓는 방법이다.

$ git rm -rf {{파일 or 폴더 }} --cached

해서 cached 옵션을 주면 index 에서만 지운다.

Working tree, index 모두

$ git reset --hard {commit_id}

작업중인 파일 되돌리기

작업중이던 파일 복구하기

$ git checkout {file_path}