[지옥에서 온 Git] 3. 브랜치 - 원리, branch, merge, checkout, fast-forward, Auto-merging&CONFLICT, stash, reset

3. 깃과 브랜치

3.1 브랜치란?

브랜치 branch
: 버전 관리 시스템에서, 여러 갈래로 퍼지는 데이터 흐름을 가리키는 말.
(나뭇가지 - 나무가 가지에서 줄기를 뻗는 모양처럼.)

브랜치의 동작원리

• 깃으로 버전관리를 시작하면 기본 브랜치인 main브랜치가 만들어진다.
  • main브랜치 = (구) master브랜치.
• HEAD는 현재 작업중인 브랜치를 뜻한다.
  • HEAD -> master : 현재 작업중인 브랜치가 master브랜치임을 뜻함
• *브랜치는 커밋을 가리키는 포인터이다.
  사용자가 커밋할 때마다 main브랜치는 최신 커밋을 가리킨다. *

포인터pointer : (프로그래밍) 다른 변수(의 메모리 공간 주소)를 가리키는 변수를 뜻함.

간접 참조 - 값을 직접 쓰는 게 아닌 특정 메모리번지의 값을 읽어서 쓰도록 하는 것.

포인터는 서로 다른 함수 내의 변수를, 주소를 통해 제어할 수 있게 한다.

*분기(branch) *
: main브랜치에서 뻗어나오는 새 브랜치를 만드는 것.

• 새 브랜치를 만들면, 기존 파일 내용을 main브랜치에 유지하면서
  기존 파일을 수정하거나 새로운 파일을 추가할 수 있다.

*병합(merge, 머지) *
: 분기했던 브랜치를 main브랜치에 합치는 것.

• 새 브랜치에서 원하는 작업을 끝낸 후, 새 브랜치의 파일을 main브랜치에 합친다.

3.2 브랜치 만들기 / 확인하기 (branch)

• git branch
  : 브랜치를 확인하는 명령어.
  • 현재 사용 중인 브랜치에 *가 표시된다.
  • 아무 브랜치도 생성하지 않았다면 master만 조회된다.
• git branch 브랜치명
  : 현재 브랜치에서 해당 이름을 가진 브랜치를 생성하는 명령어.
  • git branch apple : apple이라는 브랜치를 생성한다.
  • 생성 후 git log : (HEAD -> master, apple)
    • master, apple : 브랜치가 master와 apple이 있다.
    • HEAD -> master : 현재 master브랜치에서 작업 중이다.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (master)
$ git log
commit 80e828572041dac3ffbf45d66e8aa59c8639cfbe (HEAD -> master, ms, google, apple)
Author: Haina <bibi6666667@kakao.com>
Date:   Mon Feb 8 23:51:16 2021 +0900

    work3

• master, ms, goolge, apple 브랜치가 work3커밋 상태에서 만들어졌다.
  (master, ms, google, apple브랜치에서도 최신 커밋이 work3이다)

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (master)
$ git log --oneline
dffeb82 (HEAD -> master) master content 4
80e8285 (ms, google, apple) work3
9c6f763 work2
4353937 work1

• HEAD -> master : 현재 브랜치는 master이다
• dffeb82 (HEAD -> master) master content 4 : master브랜치의 최신 커밋
• 80e8285 (ms, google, apple) work3 : ms, google, apple브랜치의 최신 커밋

브랜치 사이 이동하기 (checkout)

여러 브랜치 사이를 오가면서 작업할 수 있다.

• git checkout 브랜치명 : 현재 브랜치에서 해당 브랜치로 이동.
  • apple브랜치로 이동 : git checkout apple = apple브랜치로 체크아웃.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (apple)
$ git log --oneline
80e8285 (HEAD -> apple, ms, google) work3
9c6f763 work2
4353937 work1

• (HEAD -> apple, ...)
  : 현재 apple브랜치를 사용 중이다.
• apple브랜치 분기 전까지 master브랜치에 있던 커밋들은 그대로 apple브랜치에 복사되었다.

3.3 브랜치 정보 확인

여러 브랜치에서 각각 커밋할 떄 어떤 관계가 되는지 파악해야 한다.
또, 브랜치 사이의 차이점을 확인할 수 있어야 한다.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (apple)
$ git log --oneline
e55ae67 (HEAD -> apple) apple content 4
80e8285 (ms, google) work3
9c6f763 work2
4353937 work1

• (HEAD -> apple) : 현재 apple브랜치에 체크아웃한 상태이다.
• e55ae67 (HEAD -> apple) apple content 4 : apple브랜치의 최신 커밋은 해시가 e55ae67인 커밋이다.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (apple)
$ git log --oneline --branches
e55ae67 (HEAD -> apple) apple content 4
dffeb82 (master) master content 4
80e8285 (ms, google) work3
9c6f763 work2
4353937 work1

git log --oneline --branches : 각 브랜치의 커밋을 한꺼번에 한 줄로 조회함.

• e55ae67 (HEAD -> apple) apple content 4 : 현재 apple브랜치 사용 중이며, 최신 커밋은 e55ae67해시인 커밋이다
• dffeb82 (master) master content 4 : master브랜치의 최신 커밋은 해시가 dffeb82인 커밋이다
• 80e8285 (ms, google) work3 : ms브랜치와 google브랜치의 최신 커밋은 해시가 80e8285인 커밋이다.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (apple)
$ git log --oneline --branches --graph
* e55ae67 (HEAD -> apple) apple content 4
| * dffeb82 (master) master content 4
|/
* 80e8285 (ms, google) work3
* 9c6f763 work2
* 4353937 work1

git log --oneline --branches --graph : 모든 브랜치와 커밋의 관계를 그래프 형태로 표시함

• |와 /이 커밋과 커밋의 관계를 나타낸다.
• apple브랜치에서는 work1, work2, work3 다음에 apple content 4가 만들어졌다.
• master브랜치에서는 work1, work2, work3 다음에 master content 4가 만들어졌다.
• apple브랜치와 master브랜치는 같은 부모 커밋(work3)을 가지고 있다.
  • apple과 master는 work3 커밋까지는 같고, 그 이후 브랜치마다 다른 커밋을 했다.

브랜치 사이의 차이점 확인

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (apple)
$ git log master..apple
commit e55ae678491ed0bf9d47e54738f351009c565ede (HEAD -> apple)
Author: Haina <bibi6666667@kakao.com>
Date:   Tue Feb 9 11:38:09 2021 +0900

    apple content 4

rnala@DESKTOP-SL978IQ MINGW64 ~/manual (apple)
$ git log apple..master
commit dffeb8201be8fb9e31efb4b0befafe40ce643659 (master)
Author: Haina <bibi6666667@kakao.com>
Date:   Tue Feb 9 11:09:30 2021 +0900

    master content 4

git log 브랜치1..브랜치2 : 브랜치1기준으로 브랜치2와 비교함

• git log master..apple : master브랜치 기준으로 apple브랜치와 비교함
  • master브랜치와 비교했을 때 apple브랜치에만 있는 커밋 apple content 4 출력됨
• git log apple..master : apple브랜치 기준으로 master브랜치와 비교
  • master브랜치에만 있는 커밋 master content 4 가 출력됨

3.4 브랜치 병합하기 (merge)

• 병합(merge)
  : 브랜치에서 작업을 끝내고 기존 브랜치와 합치는 것.

• 브랜치를 병합하려면 가장 먼저 master브랜치로 체크아웃해야 한다.

  git checkout master

서로 다른 파일 병합하기

• git merge 브랜치명 : 해당 브랜치를 현재 브랜치에 병합한다.

• merge수행 시 자동으로 빔이 켜지고 커밋메시지가 나타난다.

  • 메시지를 수정할 수도 있고, 그대로 사용할 수도 있다.

• git merge 브랜치명 --no-edit : 빔으로 커밋메시지를 편집하지 않고 그대로 사용하고 싶을 때.

• git merge 브랜치명 --edit : 위의 --no-edit설정을 해제하고 싶을 때.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual-2 (o2)
$ git log --oneline --branches --graph
* 804ba7b (HEAD -> o2) o2 work 2
| * da9f226 (master) master work 2
|/
* a85fbbe work 1
// 이 상태에서..

rnala@DESKTOP-SL978IQ MINGW64 ~/manual-2 (master)
$ git log --oneline --branches --graph
*   c782675 (HEAD -> master) Merge branch 'o2' into master
|\
| * 804ba7b (o2) o2 work 2
* | da9f226 master work 2
|/
* a85fbbe work 1

• o2브랜치의 o2 work 2커밋이 master브랜치에 병합되고,
  Merge branch 'o2' into master 커밋이 새로 생겼다.

fast-forward merge 빨리감기 병합

• master브랜치에서 브랜치를 분기한 뒤에, master브랜치에 아무 변화가 없다면 (새로운 커밋이 없다면) : 분기한 브랜치의 최신 커밋을 master브랜치가 가리키도록 하면 끝이다.
• 이 경우 Fast-forward메시지가 나타나고, 커밋 해쉬가 업데이트된다.
  • updating 커밋해쉬1..커밋해쉬2
Fast-forward
• 단순히 포인터만 움직인 것이므로 커밋 메시지 창은 열리지 않는다.

같은 문서의 다른 위치를 수정했을 때 병합하기 (Auto-merging)

똑같이 git checkout master, git merge 브랜치명 으로 병합한다.

$ git merge o2
Auto-merging work.txt
Merge made by the 'recursive' strategy.
 work.txt | 1 +
 1 file changed, 1 insertion(+)

• Auto-merging 파일명 : 병합 완료 메시지.
  같은 문서의 다른 위치를 수정했기 때문에 (겹치는 수정사항이 없기 때문에)
  자연스럽게 하나의 파일로 자동으로 합쳐진다.

같은 문서의 같은 위치를 수정했을 때 병합하기 (CONFLICT)

깃은 줄 단위로 변경여부를 확인하기 때문에,
서로 다른 브랜치가 같은 파일의 같은 줄을 수정한 후 병합하면 브랜치 충돌(conflict)이 발생한다.

똑같이 git checkout master, git merge 브랜치명 으로 병합한다.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual-3/manual-4 (o2)
$ git checkout master
Switched to branch 'master'

rnala@DESKTOP-SL978IQ MINGW64 ~/manual-3/manual-4 (master)
$ git merge o2
Auto-merging work.txt
CONFLICT (content): Merge conflict in work.txt
Automatic merge failed; fix conflicts and then commit the result.

rnala@DESKTOP-SL978IQ MINGW64 ~/manual-3/manual-4 (master|MERGING)
$

• CONFLICT (content): Merge conflict in work.txt Automatic merge failed; fix conflicts and then commit the result.
  : work.txt를 자동 병합하는 동안 충돌이 발생했음을 의미함.
  충돌이 생긴 문서는 자동으로 병합되지 않으므로(Automatic merge failed;)
  사용자가 직접 충돌 부분을 해결한 후 커밋해야 함.

1. 빔에서 해당 문서를 열어 직접 수정한다.
   문서에는 충돌이 일어난 두 브랜치의 내용이 한꺼번에 나타나 있다.

# title
content
<<<<<<< HEAD
master content 2
=======
o2 content 2
>>>>>>> o2
# title
content

• <<<<<<< HEAD
master content 2
=======
  : 현재 브랜치에서 수정한 내용.
• =======
o2 content 2
>>>>>>> o2
  : o2브랜치에서 수정한 내용.

2. 내용을 원하는 대로 수정한 후, <<<<<<< HEAD, =======, >>>>>>> o2 를 삭제하고 문서를 저장한다.

3. 수정한 문서를 add, commit한다.

머지 및 충돌 해결 프로그램
: 머지와 충돌을 자동으로 해결해 주는 프로그램들.

병합 알고리즘 중 2way merge / 3way merge(권장)를 지원하는 프로그램을 사용한다.

P4Merge, Meld, Kdiff3, Araxis Merge 등.

병합이 끝난 브랜치 삭제하기

병합 후 더 이상 사용하지 않을 브랜치는 삭제한다.
*단, 브랜치를 삭제하더라도 같은 이름의 브랜치를 다시 만들면 예전 내용을 볼 수 있다.
사실상 삭제가 아닌, 깃의 흐름에서 감추는 것 뿐이다.

• git checkout master : 브랜치 삭제를 할 때도 가장 먼저 master브랜치로 체크아웃해야 한다.
• git branch -d 브랜치명 : 해당 브랜치를 삭제한다.
• git branch -D 브랜치명 : 해당 브랜치를 삭제한다. 해당 브랜치가 master에 병합되지 않았다고 해도 삭제한다.
• 결과 메시지 : Deleted branch o2 (was 커밋해시)

3.5 브랜치 관리하기

깃과 브랜치를 편하게 관리하기 위한 명령들.

브랜치에서 checkout와 reset의 작동 원리

브랜치가 여러 개일 때 checkout 사용하기 -HEAD 제어

• git checkout은 HEAD를 제어해 브랜치를 이동할 수 있다.

• HEAD는 현재 작업 트리가 어떤 버전을 기반으로 작업 중인지 가리키는 포인터이다.

  • HEAD는 기본적으로 마스터 브랜치를 가리킨다.
  • 브랜치를 변경할 때 사용했던 git checkout 명령어는 곧,
    HEAD가 가리키는 것을 제어하는 명령어이다.
    git checkout sub처럼 브랜치를 sub로 변경하면, HEAD는 sub를 가리킨다.

• 각 브랜치는 기본적으로, 브랜치의 커밋 중 가장 최신의 커밋을 가리킨다.

  • 새로 생성된 브랜치 역시 복사된 커밋들 중 가장 최신의 커밋을 가리킨다.

브랜치가 여러 개일 떄 reset사용하기

• git reset은 HEAD가 가리키는 브랜치의 최신 커밋을 원하는 커밋으로 지정할 수 있다.

• 현재 브랜치가 아닌 어떤 브랜치에 있는 커밋이든 골라서 최신 커밋으로 지정할 수 있다.
  git reset 커밋해시 (다른 브랜치의 커밋해시를 넣는다)

• 결과 메시지 : Unstaged changes after reset: 파일명

• 브랜치와의 연결이 끊긴 커밋은 삭제된다.

수정 중인 파일 감추기 및 되돌리기

stash
: 작업 트리에서 파일 수정 후, 아직 커밋하지 않은 상태에서 다른 파일을 커밋해야 할 때
아직 커밋하지 않은 파일을 잠시 감춰두는 방법이다.

• git stash (또는 git stash save)
  : 커밋하지 않은 작업트리의 수정 내용을 잠시 보관하는 (감춰두는) 명령어.

  • 파일들이 사라지는 것이 아닌 잠시 감춰두는 것일 뿐이다.
  • 결과 메시지 : Saved working directory and index state WIP on 브랜치명: 커밋해시 파일명
  • git stash 이후 git status로 조회하면, 커밋할 것이 없다고 나온다.
    (nothing to commit, working tree clean)

• git stash list
  : stash된 파일들의 목록을 확인하는 명령어.
  stash list는 스택 방식으로 저장되어 stash stack이라고도 한다.

  • stash@{0} 에 항상 가장 최근에 추가된 파일이 담긴다.
  • 새로운 항목이 추가되면 기존 파일은 stash@{1}로 밀려나고, 새 파일이 stash@{0}이 된다.

급한 작업을 마치고, stash해둔 파일을 다시 꺼내서 작업할 수 있다.

• git stash pop
  : stash list에서 가장 최근 항목 (stash@{0})을 되돌린다. (stash 이전 상태로)
• git stash apply
  : stash list에서 가장 최근 항목을 되돌리지만, 저장 내역을 그대로 남겨둔다.
  • stash list의 수정내용을 나중에 또 사용할 수 있을 때 활용함.
• git stash drop
  : stash list에서 가장 최근 항목을 삭제한다.