커밋객체
를 저장한다. 따라서 현재 커밋이 이전 커밋을 바라보고있어 어떤 커밋을 기준으로 바뀌었는지 알 수 있다.git의 브랜치는 커밋사이를 가볍게 이동할수있는 어떤 포인터같은것이다.
git branch [브랜치01]
현재 작업하고있던 마지막 커밋을 기준으로 새로운 브랜치01 을 생성한다.
git은 HEAD라는 특수한 포인터가 현재 작업중인 로컬 브랜치를 가르킨다.
git log --decorate
--decorate
옵션으로 브랜치가 어떤 커밋을 가르키는지 확인할수있음.
git checkout [브랜치02]
git commit -m "C4"
HEAD를 브랜치02로 이동한다.
이때 이동한 브랜치02에서 commit을 하게되면 HEAD가 C4로 이동한다.
만약 다시 브랜치01으로 체크아웃한다면 HEAD도 C3으로 이동하게된다.
git checkout [브랜치01]
만약 이 상황에서 브랜치01에서 추가 작업을 커밋한다면 브랜치가 분기될것이다.
git commit -m "C5"
git checkout -b [이슈53]
// git branch [이슈53]
// git checkout [이슈53]
위와같이 이슈 53브랜치를 생성과 동시에 체크아웃할수있다. 아래와 같은 상황을 가정해보자.
이때 master에 급하게 수정해야 할 사항이 생겼을떄 hotfix 브랜치를 만들어서 고쳐야한다.
git stash
git checkout master
git checkout -b hotfix
그런 다음 master로 체크아웃한다음 git merge를 해준다
fast-forward
로 merge하는데 이는 C4가 C2기반으로 만들어졌기때문에 브랜치과정에서 merge를 생략하고 최신 커밋으로 이동한다(?). git checkout master
git merge hotfix
이후 hotfix 브랜치는 삭제한다
git branch -d hotfix
그런 다음 이슈 53으로 체크아웃한뒤 커밋을 하고, master에 이슈53을 merge 하는 경우는 3-way-merge를 하게된다
git checkout [이슈53]
git commit -m "C5"
git checkout master
git merge [이슈53]
3way Mergerk 실패할때도있는데 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하게되면 충돌이 발생한다.
이때 git staus를 사용해 충돌 내역을 확인할수있다.
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git com
....
이때 개발자가 수동으로 충돌부분을 해결해야한다. 충돌난 부분은 아래처럼 표기된다.
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git com
이때 git mergetool을 사용해 다른 merge 도구를 사용가능하다.
git ls-remote
로 조회가능
기존의 origin remote의 master브랜치를 clone했을때 내 로컬에는 origin/master
라는 리모트 트래킹 브랜치가 생성되며 이는 remote 의 master브랜치를 가르킨다.
다른 동료가 remote에 커밋을 push하면 origin/master포인터와 리모트의 master의 히스토리는 달라진다.
이때 git fetch origin으로 동기화 할 수 있다.
로컬 브랜치의 데이터를 명시적으로 push해야 업데이트됨.
git push <remote> <branch>
로 사용하며 로컬브랜치명과 리모트 서버 브랜치명이 다를때
git push origin serverfix:awesomebranch
형태로도 쓸 수 있다
위는 기존의 3way merge인데, experiment브랜치에서 master를 rebase 하면
git checkout experiment
git rebase master
아래처럼 공통된 C2커밋으로 부터 각 브랜치의 diff를 임시공간에 저장한뒤, 그런다음 experiment가 master의 커밋을 가르키게한뒤 변경사항을 차례대로 병합한다.
병합하면 아래처럼 두 브랜치가 같은 커밋을 바라보게되고 마지막으로 fast-forward
병함시키면된다
git checkout master
git merge experiment
아래 원칙만 지키면 rebase는 문제될게없다.
이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라
rebase의 활용예시는 이해가 안되어 다시 읽어보겠음..