Let's learn about git

1. Git Concept 👩‍💻

Git 은 변경 내역을 추적 기록하는 증분 백업(Snapshots)으로 동작하며 이전 버전과 다음 버전의 변경 내역을 delta라고 한다. 따라서 Git Repository 를 Clone 한다는 것은 이 모든 delta를 풀어낸다는 것을 의미한다.

C0 라는 최초의 Base-commit 이 존재하고 여기에 2번의 커밋 을 했다고 해보자.

C0(Base) ⬅️ C1 ⬅️ C2((main*, HEAD))

C2 는 자신의 부모로 C1 을 가리키고, C1 은 다시 자신의 부모로 C0 를 가리킨다. 이렇게 최초의 Base-commit 으로부터 연결되는 Snapshot Chain 으로 이루어지며, 현재 Branch 의 마지막 커밋을 Head라 부른다.

---

2. Basic Git Commands 👩‍💻

1. Create New Branch and Checkout

Git 에서 Branch 는 단지 특정 커밋에 대한 Reference 에 불과하다. 즉, 새 브랜치를 만드는 것이 복제본을 생성하는 것이 아니므로 속도나 용량에 아무런 영향을 미치지 않고 매우 가볍게 동작할 수 있다는 것을 의미한다. 따라서 작업을 커다란 브랜치로 만드는 것 보다 작은 단위로 잘라 브랜치를 자주 만들어 작은 단위로 다루는 것이 좋다.

Syntax

# Create New Branch
git branch "branch_name"
# Move to the Branch
git checkout "branch_name"

Example

bugFix 라는 브랜치를 만들어보자.

git branch bugFix

C0(Base) ⬅️ C1 ⬅️ C2((main*, HEAD), bugFix)

C2 커밋에 또 다른 Reference 가 추가되었다. 아직 Current Branch 는 main 을 유지하고 있다. 이제 bugFix 브랜치로 이동해보자.

git checkout bugFix

C0(Base) ⬅️ C1 ⬅️ C2(main, (bugFix*, HEAD))

깃 트리는 위와 같이 변경된다. Current Branch 가 bugFix 로 변경되었으며, HEAD 가 bugFix 의 C2 커밋을 가리킨다.

2. Git Merge

Syntax

git merge "branch_name"

다음은 C2 커밋을 기준으로 main 브랜치와 bugFix 브랜치가 각각 하나씩 커밋을 한 상태를 나타낸다.

Current Branch 는 main 브랜치에 위치해 있다. 이제 bugFix 브랜치를 main 브랜치에 merge해보자.

git checkout main
git merge bugFix

3. Git Rebase

Rebase는 Merge와 달리 하나의 브랜치에서 개발한 것처럼 짓뭉개버린다. 위 2번의 트리 구조로 돌아가 Merge 대신 Rebase 를 해보자. 단, 이번에는 위와 트리 구조는 동일하지만 Current Branch 가 main 이 아니라 bugFix 라는 것에 주목하자.

Syntax

# "branch_from_name" 을 생략하면 암시적으로 "current_branch" 가 "branch_from_name" 가 된다.
# 따라서 "current_branch" 를 "branch_to_name" 뒤에 연결한다.
git rebase "branch_to_name"
# "branch_to_name" 뒤에 "branch_from_name" 를 연결한다.
git rebase "branch_to_name" "branch_from_name"

Example

git checkout bugFix
git reabse main

물론, main 쪽으로 Rebase 를 하는 것도 가능하다.

git checkout main
git rebase bugFix

를 하면 다음과 같은 트리 구조로 Rebase 된다.

C0(Base) ⬅️ C1 ⬅️ C2 ⬅️ C3 ⬅️ C4((main*, HEAD), bugFix)

---

3. Intermediate Git Commands 👩‍💻

1. HEAD

HEAD는 현재 Checkout 된 브랜치, 즉, 작업중인 깃 트리의 최신 커밋을 가리킨다. 깃 트리에 변화를 주는 Git 명령어들은 대부분 HEAD 를 변경하는 것으로 시작한다.

HEAD 를 분리한다는 것은 HEAD 를 브랜치 대신 커밋에 붙이는 것을 의미한다.

Syntax

git checkout "commit_hash"

Example

git checkout C3

2. Relative Reference

위 4번이 특정 커밋의 해시를 직접 Checkout 해서 HEAD 를 움직였다면, 깃 트리 구조에서 Chain 을 따라 이동하도록 할 수 있다.

Syntax

# ^ 한 커밋 위로 이동
git checkout "branch_name"^
# ~n n 커밋 위로 이동
git checkout "branch_name"~n

• 만약 부모가 2개 이상일 경우 git checkout "branch_name"^1, git checkout "branch_name"^2와 같이 각각 접근 할 수 있다.
• git checkout HEAD~^2~2와 같이 연속해서 사용할 수 있다.

Example 1

git checkout main^

Example 2

git checkout main~3

branch 와 HEAD 를 강제로 이동할 때 -f를 이용해 다음과 같이 활용할 수 있다.

git branch -f main HEAD~3
git branch -f main C5

3. Reset and Revert

깃에서 작업을 되돌리는 방법으로는 Reset 과 Revert 두 가지가 있다.

1 ) Reset

Reset 은 애초에 커밋을 하지 않은 것처럼 예전 커밋으로 브랜치를 옮긴다. 따라서 협업하는 Repository 인 경우 이미 Remote 에 올라간 커밋은 Reset 을 하면 안 된다. 아직 Remote 에 올라가기 전 Local 에 존재하는 커밋 또는 개인 Repository 에서만 사용해야한다.

Syntax

# 되돌아가려는 커밋 지점을 받는다
git reset "commit_hash"
git reset "branch_name"^
git reset "branch_name"~n

Example

git reset C3

2 ) Revert

Revert 는 깃의 delta를 역으로 되돌리는 커밋을 생성한다. 변경분을 되돌리는 새 커밋을 생성하는 것이기 때문에 협업시에도 사용이 가능하다.

Syntax

# 되돌리려는 커밋을 받는다
git revert "commit_hash"

Example

git revert C5

4. Cherry Pick

Rebase 가 원래 하나의 브랜치에서 개발한 것처럼 짓뭉개버린다고 했다. 그러면 특정 커밋만 뽑아서 Rebase 를 하고 싶다면 어떻게 해야할까? 이때 체리피커처럼 특정 커밋만 뽑아와서 자신의 트리 구조에 넣는 명령어가 cherry-pick이다.

Syntax

git cherry-pick "commit_hash1" "commit_hash2"

Example

git checkout main
git cherry-pick C4 C5 C78

5. Interactive Rebase

Cherry Pick 은 원하는 커밋의 해시값을 알 때 유용하다. 하지만 원하는 커밋을 명확히 모를 때는 Interactive Rebase 를 사용해 Rebase 할 커밋을 검토하는 과정을 추가할 수 있다.

Syntax

git rebase -i "branch_name"

-i 옵션을 추가하면 Rebase 처리 전 vim 과 같은 텍스트 편집기를 열어 각 커밋을 구분할 수 있는 해시와 메시지를 보여준다.
이때 처리 가능한 명령은 다음과 같다.

1. 커밋들의 순서 변경.
2. 원하는 커밋만 선택 pick을 이용.
3. 커밋들을 squash 처리.

Example 1

C0(Base) ⬅️ C1 ⬅️ C2 ⬅️ C3 ⬅️ C4 ⬅️ C5(main*)

git rebase -i HEAD~4

이때 커밋을 C2, C4, C5 만 pick 하고 순서를 C4 ⬅️ C5 ⬅️ C2 로 변경한다면 결과는 다음과 같다.

Example 2

이번에는 버리는 커밋 없이 모두 pick 하고 대신 C3~C5 를 squash 처리한다면 결과는 다음과 같다.

---

4. Use Cases 👩‍💻

1. Change Old Commit - Interactive Rebase

• 주어진 조건

‘newImage’ 와 ‘caption’ 브랜치에 각각의 변경 내역이 있고, 서로 약간의 관련이 있어 저장소체 차례로 쌓여 있는 상황

C0(Base) ⬅️ C1(main) ⬅️ C2(newImage) ⬅️ C3(caption*)

• 변경할 대상

깃 트리의 앞쪽에 있는 커밋 내용의 일부를 살짝 바꿔 달라는 요청이 들어왔다(i.e. newImage 의 크기를 변경해주세요).

• 해결 방법

1. git rebase -i 명령으로 바꾸려는 커밋을 가장 최근 순서로 변경한다.
2. git commit --amend 명령으로 커밋 내용을 정정한다.
3. git rebase -i 명령으로 원래 순서로 되돌린다.
4. main 을 위에서 수정을 완료한 트리로 이동한다.
   

1 ) 순서 변경

git rebase -i C1

이 때 C2 와 C3 의 순서를 변경한다.

2 ) 커밋 정정

git commit --amend

3 ) 순서 원래대로 재변경

git rebase -i C1

4 ) 깃 트리 main 을 수정한 브랜치로 이동

git branch -f main caption

2. Change Old Commit - Cherry Pick

이번에는 위와 동일한 문제를 Cherry Pick 을 이용해 해결해보자.?

• 해결 방법

1. git checkout 명령으로 변경하려는 커밋보다 이전 커밋으로 이동한다.

   (Cherry Pick 하려는 커밋이 현재 브랜치에 존재해서는 안 된다)

2. git cherry-pick 명령으로 변경하려는 커밋만 Cherry Pick 한다.
3. git commit --amend 명령으로 커밋 내용을 정정한다.
4. git cherry-pick 명령으로 나머지 커밋을 Cherry Pick 한다.

   (현재 HEAD 가 main 이므로 이대로 완료된다)

1 ) 변경하려는 커밋 이전 커밋으로 이동

git checkout main;

C0(Base) ⬅️ C1(main*) ⬅️ C2(newImage) ⬅️ C3(caption)

2 ) 변경하려는 커밋 Cherry Pick

git cherry-pick C2

3 ) 커밋 정정

git commit --amend

4 ) 나머지 커밋 Cherry Pick

git cherry-pick C3

3. Tag

깃의 Tag는 특정 커밋들을 브랜치로 참조하듯이 영구적인 Milestone으로 표시하기 위해 존재한다.

Syntax

# Commit Hashcode 를 생략하면 HEAD 에 Tag 를 붙인다.
git tag "tag_name"
# 특정 Commit Hashcode 에 Tag 를 붙인다.
git tag "tag_name" "commit_hash"

Example

다음과 같은 깃 트리가 있다고 가정해보자.

git tag v0 C1

이번에는 HEAD 를 이동시키고 특정 Commit Hashcode 대신 HEAD 에 바로 Tag 를 붙여보자.

git checkout C2
git tag v1

4. Describe

깃에는 현재 깃 트리를 자동으로 요약해 설명하도록 명령할 수 있는 Describe라는 명령어가 있다. 이때 이정표 역할을 해주는 것 중 하나가 Tag다.

Syntax

git describe <ref>

<ref>에는 커밋을 의미하는 어떤 것이든 사용할 수 있다. 만약 특정지어주지 않을 경우 현재 HEAD 를 사용한다.

출력되는 결과물은 다음과 같다 [Milestone][Commit 개수][Describe 대상]

• Milestone: Base or Tag
• Commit 개수: Milestone 과 Describe 대상 사이의 커밋 개수
• Describe 대상: HEAD or 특정 커밋

Example

다음과 같은 깃 트리가 있다고 가정해보자.

git describe main   # v0_2_gC2
git describe C2     # v0_2_gC2

git describe C3     # v1
git describe v1     # v1

Tag가 새 이정표를 만들어 Tag 부터 시작된다.

git describe C5     # v1_1_gC5
git describe C6     # v1_2_gC6
git describe bugFix # v1_2_gC6
git describe        # v1_2_gC6

---

5. Git Remote 👩‍💻

Syntax

"remote_name"/"branch_name"

일반적으로 origin/main으로 짓는다.

---

6. Git Origin 👩‍💻

1. Fetch and Pull

Pull 명령은 Fetch 명령과 Merge 명령을 합친 것과 같다.

git fetch; git merge o/main
git pull

Pull 명령에 Fetch 명령과 Rebase 명령을 합친 효과를 내려면 option 으로 --rebase를 설정한다.

git fetch; git rebase o/main
git pull --rebase

2. Control Tracking Branch - Checkout

Syntax

git checkout -b "branch_name" "tracking_branch_name"

• branch_name으로 브랜치를 생성한다.
• 이 브랜치가 tracking_branch_name를 추적하도록 설정한다.

Example

git checkout -b foo origin/main
git pull

C0(Base) ⬅️ C1(main) ⬅️ C2(foo*, origin/main)

main 이 아닌 foo가 origin/main을 추적한다.

git commit -m "commit_message"
git push

C0(Base) ⬅️ C1(main) ⬅️ C2 ⬅️ C3(foo*, origin/main)

마찬가지로 Push 역시 foo가 origin/main과 연결된다.

3. Control Tracking Branch - Branch

위에서 Checkout 을 이용해 Branch 의 Remote 트래킹을 연결했다면 이번에는 Branch 명령을 이용해 추적하도록 해보자.

Syntax

# "local_branch_name" 을 생략하면 암시적으로 "current_branch" 가 "local_branch_name" 이 된다.
git branch -u "origin_branch_name"
git branch -u "origin_branch_name" "local_branch_name"

Example

git branch -u origin/main foo

위에서 설명했듯이 현재 작업중인 브랜치가 foo 일 경우 생략할 수 있다.

git branch -u origin/main

5. Push

Syntax

# Remote 연결이 되어 있다면 단지 git push 만 입력해도 된다.
git push
git push "remote_name" "branch_name"

Example

다음과 같은 깃 트리가 있다고 가정해보자.

C0(HEAD) ⬅️ C1(origin/main, origin/foo) ⬅️ C2(main)   ↖️ C3(foo)

git push origin main

C1 에 (origin/main) 을 보고 이 녀석을 Push 하는 것으로 혼동하지 말자. 현재 Remote 가 다음 상태임을 나타내는 것이다.

• Remote 의 깃 상태

C0 ⬅️ C1(main, foo)

git push origin main 명령은 현재 C2(main)을 Remote 이름이 origin인 곳에 Push 를 하겠다는 것이다.
따라서 로컬의 main과 foo를 모두 origin에 Push 를 하면 다음과 같다.

6. Push - Destination

Syntax

git push "remote_name" "local_source":"remote_destination"

특정 커밋으로 Checkout 하지 않고도 Push 를 할 수 있다. Source 는 특정 커밋이 될 수도 있고, 브랜치가 될 수도 있다.
로컬의 A 를 Remote 의 B 로 Push 한다고 생각하면 쉽다.

Example

다음과 같은 깃 트리가 있다고 가정해보자.

다음과 같이 명령어를 입력해보자.

git push origin foo^:main

그러면 foo를 기준으로 부모 커밋(C2) 가 origin/main 에 Push 될 것이다.

만약 Remote 에 Destination 이 존재하지 않는다면 새 브랜치를 생성한다.

git push origin main:bar

만약 Local Source 를 비워두면 Remote Destination 을 제거한다

git push origin :bar

생각해보면 쉽다. 아무 것도 없는 것을 목적지에 Push 하겠다는 것이니까. 따라서, 실수로 삭제하지 않도록 주의해야한다.

7. Fetch - Destination

Syntax

git fetch "remote_name" "remote_source":"local_destination"

링크 Push - Destination 와 개념은 동일하다. 단지 순서가 Remote 에서 로컬 방향으로 반대가 될 뿐이다.
즉, Remote 의 A 를 로컬의 B 로 Fetch 한다고 생각하면 쉽다.

Example

다음과 같은 깃 트리가 있다고 가정해보자.

다음과 같이 명령어를 입력해보자.

git fetch origin foo~1:bar

그러면 Remote 의 foo를 기준으로 부모 커밋 C2 가 bar 로 Fetch 될 것이다.

만약 Local Destination 을 비워두면 현재 위치한 HEAD 에 새 브랜치를 생성한다

일반적인 동작은 아니다. 브랜치를 다루는 명령이 별도로 존재하니까… 단지 깃의 Fetch 가 어떤식으로 동작하는지 알아만 두고 사용할 일은 없다.

---

Reference

1. “Learn Git Branching.” Learn Git Branching. accessed Apr. 21, 2023, Learn Git Branching.