[Git] branch, reset, merge의 원리

1. branch의 원리

파일 구성도

.git파일 -> refs파일 -> HEAD파일 -> 최신 커밋한 브랜치 파일 -> object(최신 커밋) -> tree, parent object

 

* HEAD : 현재 사용하고 있는 btanch를 가리킴

현재 브랜치 : master

 

ex) 브랜치 파일 git branch [name]으로 하지 않고 생성하기

vim .git/refs/heads/exp

2. reset의 원리와 checkout

1) reset이란?

최신 커밋 시점을 변경하는 것

git reset --hard 8be853e6451aeaeb74dd708d8e121be915e46faf
// 3번 커밋을 최신 커밋으로 바꾸기

2) reset 실행 되돌리기

※ 여기서 reset을 사용해도 4번의 커밋은 실제로 제거되지 않음

: reset전에 ORIG_HEAD파일에 현재의 최신 commit 정보를 가리킨 후 reset됨

 

아래 명령어를 통해서 돌아갈 수 있음

// reset취소
git reset --hard ORIG_HEAD

// 명령들 확인 방법
git reflog

git reset HEAD@{0} 하면 이전의 reset명령 취소됨

3) reset의 범위

* 핵심 3가지 요소

working directory : 실제로 작업을 진행하는 곳

index : git add를 했을 때 추가되는 곳

repository : commit(버전)들이 저장되는 곳

 

<working directory와 index내용 비교>

git diff

 

4) checkout

- commit id를 브랜치로 가리킬 수 있음

git checkout [commit id]

3. confilict의 원리

- 실제 협업에서 많이 발생하는 일

 

해결 : 3-way merge

1) confilict

(아래 코드 흐름은 f1.txt를 각 브랜치 마다 수정하면서 커밋을 하는 과정)

(master) f1.txt
function(){
  return 'common';
}
<commit 1>

(exp) f1.txt
function(){
  return 'exp';
}
<commit 'common -> exp'>

(master) f1.txt
function(){
  return 'master';
}
<commit 'common -> master'>

* git checkout -b exp  : exp라는 브랜치를 만들고, exp로 checkout

 

만든 결과

 

<merge할 경우 confilict 발생>

- master, exp브랜치에서 둘 다 내용을 변경했는데, 파일의 이름이 같고 같은 부분의 내용을 수정한 경우

git checkout master
git merge exp

confilct 발생

파일 내용

vim f1.txt

2) 해결방법

- 어떤 부분인지 확인

git status

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   f1.txt

- 확인된 f1.txt파일 수정

4. 3 way merge

1첫째 행을 branch라고 하고

나머지 행을 변경된 내용이라 한다면,

* 여백 : 수정된 내용

 

*Base : 공통으로 갖는 코드

 Me : 현재의 브랜치

 Other : 다른사람의 브랜치

 

* Other의 브랜치를 Me로 병합하는 것

 

* 두 번째 줄 : other만 다른 것

  세 번째 줄 : 모두 같은 내용

  네 번째 줄 : 모두 바꾼 내용

  다섯 번째 줄 : Me만 다른 것

 

? : confilict(무엇이 맞는지 모르는 경우를 의미, 단 하나만 수정될 시 수정된 것으로 결정)

2 way merge : Base를 참고하지 않고 Me와 Other를 병합하는 방식

3 way merge : Base를 참고로 하여 Me와 Other를 병합하는 방식

 

3 way merge가 더 좋음