[Git] Branch

브랜치란?

가장 흔한 오해가 브랜치를 만들면 폴더가 복사된다고 생각하는 것이지만 커밋들은 서로 사슬처럼 연결돼 있고, 브랜치는 그중 특정 커밋에 붙여둔(가리키는) 이름표(포인터)일 뿐이다.

이미 브랜치(이름표)가 존재하는 커밋 지점에 다시 브랜치를 생성하면 단순히 같은 커밋을 가리키는 새로운 브랜치(이름표)가 추가된다.

그런데 두 브랜치에 각각 독자적인 커밋이 쌓이기 시작하면 공통 조상(분기점)으로부터 갈라져 나가는 실제 분기가 시작된다.

 

브랜치를 왜 쓰는가?

main 브랜치는 "언제든 정상적으로 동작하는 상태"로 유지하고, 새 기능이나 수정은 별도의 브랜치에서 진행한다. 
망하면 브랜치째 삭제하면 그만이고, main은 아무런 영향도 받지 않는다.
협업에서는 이게 필수라고 볼 수 있는데, 여러 명이 같은 브랜치에 동시에 커밋하면 서로의 코드를 계속 밟기 때문이다.

 

Step 1. 브랜치 목록을 확인해 보고 새로운 브랜치를 생성해 보자.

다음 명령어를 터미널에 입력하여 브랜치 목록을 확인해 보자.

git branch

* 표시는 현재 HEAD가 가리키고 있는 브랜치를 의미한다.

 

이번에는 다음 명령어를 입력하여 새로운 브랜치를 생성하고

git branch feature/login

 

이제 생성한 브랜치에서 작업을 진행할 것이기 때문에

다음 명령어를 입력하여 HEAD가 새 브랜치인 feature/login을 가리키도록 한다.

git switch feature/login

 

위의 브랜치 생성과 HEAD 이동에 대한 두 과정을 한번에 진행하려면 다음 명령어를 입력하면 된다.

git switch -c feature/login

브랜치가 main 에서 새로 생성한 브랜치인 feature/login으로 전환된 것을 볼 수 있다. (-c 는 create를 의미한다.)

HEAD가 main 브랜치를 가리키다가 새로 생성한 feature/login 브랜치를 가리킨다는 의미이다.

 

브랜치 목록을 확인해 보면

HEAD가 새로 생성한 브랜치를 가리키는 것을 볼 수 있고

 

git graph 확장 프로그램으로 확인해 보면

동일한 커밋 지점에 두 브랜치가 존재하는 것을 볼 수 있다.

 

Step 2. 새로 생성했던 브랜치를 삭제해 보자.

다음 명령어를 이용하여 HEAD를 main 브랜치로 이동한다.

git switch main

 

이제 다음 명령어를 통해 생성했던 브랜치를 삭제한다.

git branch -d feature/login

 

브랜치 목록을 확인해 보면

정상적으로 삭제된 것을 확인할 수 있다.

 

Step 3. 브랜치를 만들고 병합해 보기

현재까지의 작업을 정리하기 위해 먼저 다음 명령어를 통해

현재 작업 중인 파일들을 모두 스테이징 영역에 올린다.

git add .

 

그다음 커밋한다.

git commit -m "chore: 실습 환경 정리"

 

깃 로그를 확인해 보면

 

 

이제 새로운 브랜치를 만든다.

git switch -c feature/login

HEAD가 가리키는 main 브랜치의 커밋 지점에 feature/login 이라는 이름표를 하나 더 붙이고 HEAD가 feature/login을 가리킨다.

(main과 feature/login은 이름만 다를 뿐 같은 커밋을 가리킨다.)

 

다음 명령어를 입력하여 login.js 파일을 수정한다.

echo "console.log('로그인 성공')" > login.js

 

수정한 login.js 파일을 스테이징 영역에 올린 다음

git add login.js

 

커밋한다.

git commit -m "feat: 로그인 성공 메시지 추가"

새 커밋이 생기자 feature/login 이름표만 분기되어 나가고 main은 제자리에 안전하게 남아 있는다.

 

이제 VSCode 편집기에서 login.js 파일을 열어둔 채로 

 

HEAD 포인터가 main 브랜치를 가리키도록 한다.

git switch main

login.js 파일이 새로 커밋하기 이전 실습에서의 수정 전의 파일로 되돌아간 것을 볼 수 있다.

 

또 git log를 확인해 보면

최근 커밋 기록이 사라진 것을 볼 수 있다.

 

하지만 git graph 확장 프로그램으로 확인해 보면

방금 만든 커밋이 사라지지 않고 feature/login 브랜치에 그대로 남아 있는 것을 확인할 수 있다.

그렇다면 왜 이런 차이가 발생할까? 라는 생각이 들 수 있는데

 

먼저 VSCode 편집기에서 파일의 내용이 즉시 바뀐 이유는 
git switch는 단순히 HEAD가 가리키는 이름표만 바뀌는 게 아니라, 작업 폴더의 실제 파일들을 그 브랜치가 가리키는 커밋 상태로 통째로 교체한다. 그래서 브랜치를 전환하면 VSCode 편집기 내용도 즉시 바뀌게 된다.

 

또 git log로 커밋 기록을 보면 커밋 기록이 사라진 것처럼 보이지만 git graph  확장 프로그램으로 확인해보면 사라지지 않은 이유는
git log 명령어는 저장소의 모든 커밋을 보여주는 게 아니라, 현재 HEAD에서 부모 방향(역방향)으로 거슬러 올라가며 도달 가능한 커밋만 보여준다. 
따라서 main에서 출발하면 feature/login의 커밋은 앞쪽에 있어서 볼 수 없다. 하지만 그 커밋은 .git 안에 온전히 그대로 있고, feature/login이라는 이름표가 붙어 있다.

 

 

이번에는 다음 명령어를 입력하여 두 브랜치를 병합해 보자.

git merge feature/login

 

Git Graph 확장 프로그램으로 확인해 보면

main에서 feature/login이 분기된 이후 main에는 아무 커밋도 추가되지 않았기 때문에, main은 여전히 feature/login의 조상 커밋을 가리키고 있다.
즉, main에 커밋이 추가되지 않아 두 브랜치가 공통 조상으로부터 기록이 갈라지지 않았으므로 Git은 별도의 Merge Commit을 새로 만들지 않고, 단순히 main 브랜치(이름표)를 feature/login 브랜치가 위치한 커밋으로 전진시킨다.
이처럼 브랜치(포인터)만 앞으로 빨리감기하듯 전진시키는 병합 방식을 Fast-forward(빨리감기)라고 한다.

 

이제 다음 명령어를 입력하여 분기되었던 feature/login 브랜치를 정리한다.

git branch -d feature/login

 

Git Graph 확장 프로그램으로 확인해 보면

분기되었던 feature/login 브랜치가 삭제되고 main 브랜치 하나로 깔끔하게 정돈된 것을 볼 수 있다.