Git의 원리

 

git branch?

 git의 브랜치는 refs/heads 위치 아래에 위치 하나를 더 만드는 것을 의미한다. 따라서 파일 구조를 보면 만약 현재 브랜치가 'exp'라는 브랜치를 바라보고 있는 경우 refs/heads/exp라는 경로가 생기고 HEAD라는 파일은 이 경로를 참조한다. 또한 해당 경로에 커밋을 찍은 경우 해당 경로는 커밋ID을 갖고 있게 된다.

 

 

git branch 충돌?

 a브랜치에서 A파일을 만들고 b브랜치에서 B파일을 만든 후 두 파일을 머지했을 때 어떠한 충돌도 일어나지 않고 새로 생긴 커밋에는 두 개의 파일이 모두 존재한다. 같은 파일을 수정하고 병합했을 때도 같은 파일 내에서 각 브랜치에서 수정한 위치가 다르다면 정상적으로 머지가 가능하고 각 브랜치에서 수정한 내용이 존재하는 것을 확인할 수 있다.

 만약 다른 브랜치에 같은 파일의 같은 부분을 수정할 경우 어떻게 될까? 충돌이 일어난다. 충돌이 난 파일을 열어보면 <<<<<HEAD, =====, >>>>>[branch이름]과 같이 본인이 적지 않은 기호를 확인할 수 있다. 화살기호와 함께 HEAD라고 적혀진 부분부터 ====== 기호가 있는 영역이 현재 위치하고 있는 브랜치 파일에 적혀져있는 내용이고, ========부터 >>>>>>[branch이름]까지가 [branch이름]브랜치에 적혀져 있는 내용이다. 이때는 해당파일을 열어 수정하고 add 후 다시 commit하면 된다. 

 

git checkout? reset? 

• git checkout [commit ID] : commit ID의 상태로 돌아가기
• git checkout [commit ID] [file name] : filename의 파일만 commit ID 사태로 돌아가기

여태까지 checkout 명령어는 branch 위치 변경 외에도 commit했을 때의 상태로 변경도 가능하다.

 

• git reset --hard [commit ID] : commit ID를 기준으로 이전 커밋은 사라지고 [commit ID]는 살아있는 상태로 돌아간다.
• git reflog : 현재 브랜치의 모든 로그를 확인

 예를 들어 순서대로 commit ID가 a1 - a2 - a3 라고 가정했을 때 "git reset --hard a2"를 입력하고 git log를 확인해보면 커밋 a1은 사라지고 a2 - a3만 남아있는 걸 확인할 수 있다. 그러면 이때 a1에 대한 내용은 사라진걸까? 정답은 No.

 git은 위험한 명령어를 실행시킬 때 명령어를 실행시키기 전의 최신 커밋을 ORIG_HEAD에 저장한다. 그렇기 때문에 위에서 한번 reset한 내용을 취소하고 싶다면 "git reset --hard ORIG_HEAD"를 이용할 수 있다. 

 또한 reset된 내용은 logs/refs/haeds/[branch 명] 에서 확인할 수 있다. 이 경로에 있는 내용은 "reflog"라는 명령어를 통해 확인할 수 있다. 위에서 reset을 취소할 때 단순 ORIG_HEAD내용을 취소하는 것보다 log 내용을 확인하고 해당 커밋을 reset하는게 안전하다고 할 수 있다. 

 git reset에는 아래 종류가 있는데 강의들으면서 나중에 개념적으로 이해할 때 도움이 될 것 같다.

git reset 옵션

 

3 way merge?

 merge를 할 때 git은 3way merge 기법을 활용한다고 한다. 아래 표에서 보이듯 2 way의 경우 3둔에서 충돌이 일어나는 반면 3 way는 한 군데에서만 충돌이 일어난다. 아래에서 Base를 기존의 가지 Me, Other을 각각 다르게 수정한 브랜치로 생각하면 이해가 쉬울 것 같다. 각 각 C를 1과 2로 바꿀 경우 git은 그 부분에서만 충돌이 일어난다.

 

3 way merge

 

 

참조
지옥에서 온 Git