Git 내부 동작 파헤치기 - Part 2

들어가며

안녕하세요. 원더월 모바일팀에서 앱 개발을 맡고 있는 이하연입니다.

지난번 포스트에 이어서 오늘은 Git에서 중요한 역할을 담당하는 명령어들에 대해서 더 자세히 살펴보려고 합니다. 만약 Part1을 보시지 못한 분들께서는 이전 포스트를 보고 오는 것을 추천드립니다!

0) Branch

---

branch란, 동일한 코드 베이스로부터 독립적으로 개발 작업을 수행하기 위한 기능입니다.

Git에서 master(main) 브랜치는 기본적으로 생성되는 첫 번째 브랜치이며, 일반적으로 개발 과정에서 가장 안정적인 코드가 있는 브랜치로 사용됩니다. 따라서 개발 과정에서 master 브랜치에서 작업하는 것은 권장하지 않고 다른 브랜치에서 작업한 내용을 master 브랜치로 병합하는 방식으로 코드를 관리하게 됩니다.

보통 branch는 새로운 기능을 추가하거나 버그를 수정해야 할 경우 생성합니다.

오늘은 바로 이 생성된 branch에서 각자 작업하면서 사용하는 명령어들에 대해 자세히 알아보고자 합니다.

1) log VS diff

처음으로 말씀드릴 내용은 branch의 정보 확인 및 차이를 알 수 있는 log와 diff입니다.

1-1) log

git log는 Git 저장소의 현재 브랜치에 대한 커밋 이력을 조회하는 명령어로 커밋 시간순으로 정렬되어 나타납니다. 각 커밋 이력에는 커밋의 해시값, 작성자, 작성일자, 커밋 메시지 등이 표시됩니다.

branch는 Git에서 커밋 이력을 가리키는 포인터입니다. 현재 브랜치와 같은 커밋을 가리키면 커밋 이력을 공유하며, 이후 브랜치에서 새로운 커밋이 추가되면 해당 브랜치의 포인터가 변경되어 다른 브랜치의 커밋 이력과 별개로 해당 브랜치 내에서만 이력이 관리됩니다.

이를 실습한 내용을 토대로 더 깊게 살펴보겠습니다. 아래 사진은 main에서 f1.text 파일을 생성 후 첫 번째 commit, 수정 후 두 번째 commit을 한 상태에서 git log를 한 결과입니다.

이 상태에서 새 브랜치 feature로 checkout 후 git log을 찍게 되면 어떻게 될까요?

main 브랜치와 마찬가지로 같은 상태인 것을 확인할 수 있습니다.

이 상태에서 f1.text의 내용을 다시 한번 수정 후 세 번째 commit을 하고 git log를 보면 아래와 같습니다.

또다시 git main으로 checkout 후 git log를 보면 아래와 같습니다.

이렇게 브랜치를 생성하면, 현재 작업 중인 소스 코드의 특정 지점을 가리키는 새로운 참조 포인트가 생성됩니다. 이때, 새로운 브랜치는 기존 브랜치의 이력을 그대로 이어받아 작업을 진행할 수 있어 각각의 개발자들이 동시에 작업을 진행할 때, 각자의 브랜치에서 독립적으로 작업을 진행할 수 있게 됩니다.

이번에는 아래와 같이 추가적인 작업을 한 후 log의 옵션들에 대해서 살펴보려고 합니다.

1. feature에 f1.text 내용 수정 후 commit(message : 4)을 하기 ( HEAD → feature )
2. main에 f1.text 내용 수정 후 commit(message : 5)을 하기 ( HEAD → main )

main에 있을 때 git log를 찍으면 main에 대한 커밋 이력만 나타납니다.

마찬가지로 feature로 체크아웃한 후 git log를 찍으면 feature에 대한 커밋 이력만 나타납니다.

만약 모든 브랜치의 커밋 내용을 보고 싶다면, --branches 옵션을 사용하면 됩니다.

git log --branches

만약 Git Log(브랜치 작업 흐름, 병합 등)를 시각적으로 확인하고 싶다면, --graph 옵션을 사용하면 됩니다.

--graph 옵션은 각 커밋의 해시값, 커밋 메시지, 작성자 등과 함께 브랜치 및 머지 이력을 그래프 형태로 출력되며 브랜치는 노드로 표시되고, 커밋은 간선으로 연결되어 Git 저장소의 이력을 시각적으로 확인할 수 있습니다.

만약 두 버전의 차이를 알고 싶다면, 비교할 두 개(A, B)의 브랜치 사이에 ‘..’ 연산자를 사용하면 됩니다.

A..B 형태로 사용하게 되면, B 브랜치에 존재하는 커밋 중에서 A에 존재하지 않는 커밋을 찾아주며

B..A 형태로 사용하게 되면, A 브랜치에 존재하는 커밋 중에서 B에 존재하지 않는 커밋을 찾아줍니다.

추가로, 사이에 옵션 p를 쓰면 버전별로 어떤 소스 코드 차이가 있었는지를 알 수 있습니다.

1-2) diff

이번에는 두 브랜치 사이에 있는 파일 혹은 디렉터리 간의 변경 내용을 파악해보겠습니다.

Git에서 파일의 변경 내용을 확인할 때 사용하는 명령어가 diff입니다.

예시를 살펴보기 전에 기호의 의미에 대해서 보면 ---는 이전 버전의 파일을, +++는 변경된 버전의 파일을 나타내며, -는 이전 버전에서 삭제된 내용, +는 변경된 버전에서 추가된 내용을 나타냅니다. 또한 @@ 기호는 변경된 부분의 위치를 나타내며, -와 +기호 옆에 위치한 숫자는 해당 내용의 위치 정보를 보여줍니다.

1. A..B 형태

diff의 결과를 분석해보면, a/f1.text와 b/f1.text파일 사이의 차이를 비교하고 있고, 파일간의 인덱스 정보를 보여주고 있습니다. --- a/f1.text: 원래 파일의 버전을 , +++ b/f1.text: 변경된 파일의 버전을 나타냅니다. @@ 이후에 나오는 -1,3은 변경 전 파일에서 첫번째 줄에서부터 세 줄을 의미하고 +1,4는 변경 후 파일에서 첫번째 줄에서부터 네 줄을 의미합니다. -f 는 원래 파일에서 삭제된 내용을 보여주고 +c,+d 는 변경된 파일에서 추가된 내용을 보여줍니다.

즉, f1.text파일의 3번째 줄에 있던 f 문자가 c로 변경되고, 4번째 줄에 d 문자가 추가된 것을 나타내는 결과를 diff를 통해 확인 할 수 있었습니다.

2. B..A 형태

A..B 형태와 마찬가지로, 두 브랜치 사이의 차이점을 비교하지만 B..A 형태는 B에서 A로 가는 변경 사항들을 보여줍니다. B 브랜치 입장에서 -c와 -d는 삭제된 내용이고, +f는 추가된 내용이라는 것을 알 수 있습니다.

정리하면, 앞서 설명드린 git log A..B는 두 브랜치 사이의 차이를 비교하여 B 브랜치에 존재하는 커밋들을 보여주는 반면, git diff A..B는 두 브랜치 사이에 있는 파일 또는 디렉터리 간의 변경 내용을 비교하여 변경된 내용을 보여준다는 점을 확인할 수 있었습니다.

2) HEAD 파일

위에서 살펴본 git log의 결과를 자세히 살펴보면 HEAD라는 표시가 계속 보였는데요. 과연 이 HEAD가 무엇인지 알아보겠습니다.

HEAD 파일은 .git 디렉터리가 생성될 때 자동으로 생성되는 파일이며, 이 파일은 처음에는 기본값으로 설정된 ref: refs/heads/main 란 파일을 가리키고 있습니다. 하지만 가리키고 있는 ref: refs/heads/main 파일은 어디에도 존재하지 않았습니다.

자, 이 상태에서 f1.text를 생성 후 add & commit(message: 1)을 해보겠습니다.

드디어 생긴 ref: refs/heads/main 는 첫 번째 커밋을 시작한 시점부터 생성이 되는 것을 확인할 수 있었고, 그 안을 살펴보니 commit 해시값을 가리키는 object의 정보가 들어있다는 것을 알 수 있었습니다.

한 번 더 변화를 관찰하기 위해 f1.text 내용을 수정 후 add & commit(message: 2)을 해보겠습니다.

ref: refs/heads/main 내용이 방금 커밋한 두 번째 commit 해시값을 가리키는 object Id로 변경된 것을 확인할 수 있었습니다.

이때 feature 브랜치를 생성하면 .git 디렉터리 내부의 변화는 어떻게 바뀔까요?

2개의 파일이 변화했는데, 그 중 ref: refs/heads/feature 파일이 생겼고 main과 동일하게 최신 커밋을 가리키는 것을 확인할 수 있었습니다.

이 .git/refs/heads/branch이름 파일은 현재 체크아웃한 브랜치의 최신 커밋을 가리키고 있는 파일로, 브랜치를 추적하고 관리하는 데 중요한 역할을 합니다. 그런데 이렇게 중요한 .git/refs/heads/feature 파일을 지우면 어떻게 될까요?

모든 브랜치를 목록을 보여주는 git branch를 실행하면, feature 브랜치가 사라진 것을 확인할 수 있습니다.

다시 최신 커밋 내용을 담은 .git/refs/heads/feature 를 생성하게 된다면? 다시 feature 브랜치가 생성된 것을 확인할 수 있습니다.

여기서 알게 된 놀라운 사실은 git에서 브랜치는 굉장히 중요하고 강력한 일을 하고 있지만, 단지 .git/refs/heads/ 하위에서 일반 텍스트 파일로 존재한다는 점이었습니다.

삭제 후 직접 파일을 생성하여 만들어진 feature로 checkout을 하게 되면 내부는 어떻게 변할까요? 예상했던 대로 HEAD가 feature를 가리키고 feature의 최신 커밋을 내용을 담고 있었습니다.

정리하면, git log에 표시되는 HEAD는 Git에서 현재 체크아웃한 브랜치나 커밋을 가리키는 포인터 역할을 합니다. 이를 통해 우리는 현재 작업 중인 브랜치나 커밋을 추적할 수 있고, Git 명령어를 실행할 때 HEAD를 기준으로 작업을 진행할 수 있습니다.

3) merge VS rebase

다음으로 살펴볼 내용은 두 개의 다른 브랜치를 하나로 합치는 작업하는 과정에서 쓰이는 명령어 merge와 rebase 입니다. 두 명령어 모두 여러 사람이 동시에 작업하고 있을 때, 각각의 작업 내용을 통합할 경우 쓰이나 작업 환경과 흐름 등 상황에 따라 적절한 방법을 선택해야 합니다.

merge, rebase의 동작에 대해서 간단하게 살펴보겠습니다.

3-1) merge

merge는 두 개의 다른 브랜치를 하나의 새로운 커밋으로 합치는 방법입니다.

1. 각 커밋 이력을 가진 main과 feature 브랜치가 있다고 가정해보겠습니다.

   

2. feature에 main의 내용을 가져오기 위해서 git checkout feature → git merge main을 실행하였습니다.

   

3. 그 결과 3-way 기법을 통해 main의 최신 커밋, feature의 최신 커밋을 공통 조상으로 하는 새로운 커밋(066b182)이 만들어졌습니다. 결과적으로, feature 브랜치에서 1번과 2번 부분 모두를 가진 하나의 커밋이 생성되면서 main 브랜치와 병합한 것과 동일한 결과를 얻게 됩니다.

   

merge는 히스토리가 병렬로 나아가서 두 브랜치의 변경 사항을 병합하고 병합된 커밋을 생성하고, 이 병합된 커밋은 각 브랜치의 변경 사항을 포함하고 있어 히스토리를 파악하기 어렵게 만들지만, 두 브랜치의 공통 조상 커밋을 기준으로 병합을 수행하기 때문에 두 브랜치에서 동일한 파일을 수정하여 발생한 충돌의 경우 해결하기 쉽습니다.

3-2) rebase

rebase는 다른 브랜치의 변경 내용을 현재 브랜치로 가져와서 변경 내용을 선형적으로 적용하는 방법으로, 현재 브랜치에서 가져온 변경 내용이 마치 현재 브랜치에서 일어난 것처럼 보입니다. rebase는 브랜치를 새로운 기준점으로 이동시키므로, 변경 이력이 깔끔하게 유지됩니다.

이름에서 볼 수 있듯이, rebase에서 base 의미는 두 개의 브랜치가 공통으로 가지고 있는 커밋을 의미하고, rebase를 한다는 건 base를 바꾼다는 것을 의미합니다. 아래와 같은 초기 상태을 만든 후 feature의 입장에서 base의 변화를 살펴보겠습니다.

현재 base는 master와 featrue의 공통 조상의 커밋인 b576179가 됩니다.

rebase 전

rebase 후

결과를 보면 feature는 b576179를 조상(base)으로 하는 브랜치였는데 rebase를 하고난 후 feature의 조상은 master가 위치한 1e05be4를 조상(rebase)으로 변경되었음을 확인할 수 있었습니다. 그래서 feature는 rebase 전까지는 master가 작업한 2개의 커밋이 포함되지 않았는데, rebase 후 M1,M2까지 내용이 포함된 브랜치가 된 것을 확인할 수 있었습니다.

이 상태에서 master가 feature 브랜치의 변경사항 (R1,R2)를 병합하고 싶다면 git checkout master 후 git merge feature 를 순차적으로 수행하면 아래와 같은 결과가 나타납니다.

rebase는 히스토리를 일렬로 나열하고 순서대로 다른 브랜치의 변경 사항을 현재 브랜치의 변경 사항의 뒤에 덧붙이는 방식으로 브랜치 간의 병합된 커밋이 생성되지 않아 히스토리를 깨끗이 유지할 수 있습니다. 하지만 변경 사항을 순서대로 적용하는 방식이기 때문에 브랜치 간의 같은 파일을 수정한 경우 충돌 발생 가능성이 커지고, 이 충돌을 해결하는 작업은 merge보다 어렵기 때문에 주의해서 사용해야 합니다.

이를 통해 merge와 rebase는 모두 여러 개발자들이 같은 코드 베이스에서 작업할 때 서로 다른 브랜치의 작업 내용을 통합하는 방법이지만, 두 명령어가 수행되는 과정에 차이가 존재하는 것을 알 수 있었습니다.

4) reset VS revert

마지막으로 Git의 과거 커밋을 다루는 명령어 reset, revert를 살펴보겠습니다.

4-1) reset

reset은 HEAD가 가리키는 브랜치의 버전을 바꾸면서 커밋 이후의 작업 내용이 취소된 효과처럼 보여주는 명령어입니다. 이 명령어는 히스토리에 기록되지 않기 때문에 잘못된 커밋을 수정하거나 특정 커밋으로 되돌아가고 싶을 때 사용됩니다.

reset 명령어는 되돌아가고 싶은 커밋의 id를 입력해야 하고, 이때 어떤 옵션(soft, mixed, hard)을 선택하는지에 따라 취소되는 대상이 달라집니다. (이전 포스트에서 얘기했던 working directory, index, repository의 개념을 가져와 설명하겠습니다)

자, “init”의 내용을 지닌 f1.text 파일을 생성 후 git add & commit ( message : 1 ) 한 상태에서 수정하고 reset 하면서 옵션에 따라 working directory, index, repository에서 각각 f1.text 내용이 어떻게 변화하는지 확인해보겠습니다.

먼저, “repository”로 내용을 수정한 f1.text 파일을 git add & commit ( message : 2 ) 하게 되면

working directory, index, repository의 f1.text의 내용은 모두 “repository”임을 확인할 수 있습니다.

working directory → repository

index → repository

repository → repository

---

그 다음 “index”로 내용을 수정한 f1.text 파일을 git add까지 한 상태에서 살펴보면 f1.text 내용은 아래와 같이 변경됩니다.

---

그 다음 “working directory”로 내용을 수정한 f1.text 파일을 add, commit 하지 않으면 f1.text 내용은 아래와 같이 변경됩니다.

이 상태에서 각각 옵션을 적용하여 7b7f…74로 reset 했을 때의 변화를 살펴보겠습니다.

1. soft 옵션

   먼저, soft 옵션을 사용하겠습니다.

   git reset --soft 7b7f9e441718f33183cbca20c8fcdf54792d5474

   결과를 보면, repository는 초기화되었으나 working directory, index의 내용에는 변화가 없었습니다.

   • working directory → 변화없음

   

   • index → 변화없음

   

   • repository → init 으로 초기화 됨

   

2. mixed 옵션

   ORIG_HEAD를 이용하여 다시 reset 하기 전의 상태로 되돌린 후 mixed를 해보겠습니다. ( ORIG_HEAD는 아래에서 보충 설명하겠습니다. )

   git reset --soft ORIG_HEAD
   
   git reset --mixed 7b7f9e441718f33183cbca20c8fcdf54792d5474

   이번에는, repository, index는 초기화되었으나 working directory의 내용에는 변화가 없었습니다.

   • working directory → 변화없음

   

   • index → init 으로 초기화 됨

   

   • repository → init 으로 초기화 됨

   

3. hard 옵션

   ORIG_HEAD를 이용하여 다시 reset 하기 전의 상태로 되돌린 후 hard를 해보겠습니다.

   git reset --mixed ORIG_HEAD
   
   git reset --hard 7b7f9e441718f33183cbca20c8fcdf54792d5474

   이번에는, repository, index, working directory 영역 모두 init으로 초기화되었음을 알 수 있었습니다.

   • working directory → init 으로 초기화 됨

   

   • index → init 으로 초기화 됨

   

   • repository → init 으로 초기화 됨

   

아래에 정리한 것처럼, 각 옵션을 선택하는 것에 따라 취소되는 대상이 다르다는 것을 확인할 수 있었습니다.

• soft는 repository는 초기화되나, working directory, index의 내용은 건들지 않습니다.
• mixed는 index, repository는 초기화되나 working directory의 내용은 건들지 않습니다.
• hard는 working directory, index, repository 내용이 모두 초기화됩니다.

---

이번엔 reset 명령을 실행하면 어떤 일이 일어나는지 살펴보고, 이를 바탕으로 이전 상태로 복원하는 방법까지 알아보겠습니다.

먼저 4개의 commit을 가진 main 브랜치가 있다고 가정해보겠습니다.

위 상태에서 reset —hard 옵션을 사용하여 커밋id가 6631….d6e로 돌아가게 되면 내부적으로는 어떻게 변할까요?

ref: refs/heads/main 파일의 내용이 취소한 커밋id로 변경되었습니다. 이를 통해 reset은 내부적으로 우리가 체크아웃하고 있는 브랜치의 최신 커밋을 바꾸는 행위만 하고 있었다는 것을 알 수 있었습니다.

그렇다면 취소한 커밋은 지워진 걸까요? 아닙니다. git은 웬만해서는 어떠한 정보도 지우지 않습니다.

이를 확인하기 위해 ORIG_HEAD 파일을 살펴보겠습니다.

./ORIG_HEAD에서 우리가 삭제한 commit id가 존재하는 것을 확인할 수 있었습니다.

“git reset —hard ORIG_HEAD” 를 하면 reset 하기 전의 상태로 원상 복구되는 것을 확인할 수 있습니다.

ORIG_HEAD 파일은 현재 브랜치의 헤더가 가리키고 있는 커밋을 기록해두고, 리셋 하기 전의 커밋이 무엇인가에 대한 정보를 가지고 있어 이를 이용하여 다시 reset 하기 전으로 원상복구 할 수 있습니다. 이때 별도의 옵션을 지정하지 않으면 default로 mixed 옵션이 적용되기 때문에 reset 할 때 사용한 옵션을 지정해주어야 합니다.

이렇게 reset의 옵션에 따라 어떤 영역에 영향을 끼치는지와 내부적으로 어떤 일이 일어나는지, 그리고 실수로 reset을 했을 때 어떻게 원상 복구할 수 있는지를 차례대로 살펴보았습니다.

4-2) revert

그런데 만약 실수한 것까지 기록으로 남겨놓고 싶을 때는 어떻게 해야 할까요? 바로 revert를 사용하면 됩니다.

revert는 커밋 이후의 작업 내용을 삭제하지 않고 현재 브랜치에서 작업하던 내용은 그대로 유지되면서 특정 커밋을 취소하는 명령어입니다. 이 명령어는 커밋 로그에 새로운 커밋으로 기록되기 때문에 과거 커밋을 수정하는 것이 아니라, 이전 커밋에 대한 취소 작업을 수행할 때 사용됩니다.

reset은 되돌아가고 싶은 커밋의 id을 입력해야 했다면, revert는 “취소하고 싶은 대상”을 입력해야 합니다.

reset과 동일하게 아래와 같은 초기 상태에서 revert를 했을 때의 변화를 관찰해보겠습니다.

현재 ./refs/heads/main 파일은 4번째 커밋을 가리키고 있습니다.

이때 네 번째 커밋을 취소하기 위해 “git revert c8f866..83”를 입력하면 “ba2d4a…7e”라는 새로운 커밋이 생성된 것을 확인할 수 있었습니다.

내부는 어떻게 변할까요?

./refs/heads/main 파일은 새로 생성된 커밋을 가리키는 것으로 변경되었음을 알 수 있습니다.

결론적으로, 두 명령어 모두 과거로 되돌린다의 개념이지만, reset은 특정 커밋 이후의 모든 작업 내용을 삭제하는 효과를 통해 과거 커밋으로 돌아가는 명령어이고, revert는 현재 브랜치에서 작업하던 내용을 유지하면서 이전 커밋을 취소하고 이를 새 커밋으로 추가되는 명령어라고 정리할 수 있겠네요.

위 실습한 내용을 토대로 reset, revert를 그림으로 정리한 모습입니다.

---

글을 마무리하며

이번 포스트에서는 Git의 Branch를 시작으로 log/diff의 차이, HEAD 파일, merge/rebase의 차이, reset/revert의 차이를 순서대로 살펴보았습니다. Git의 다양한 명령어를 직접 파고들면서 내부적으로 어떻게 동작하는지를 알게되는 좋은 경험을 했습니다. 또한, Git을 이용한 협업 작업에서는 목적과 상황에 맞게 각 명령어를 적절히 사용하는 것이 중요하다는 것을 깨달았습니다.

이 글을 보시는 분들도 한번쯤 Git의 내부를 분석해보는 것을 추천드립니다! 끝까지 읽어주셔서 감사합니다.