Git이란? (4) - branch란?

branch 란?

모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다.

 

위는 git-book에서 설명해 놓은 branch에 대한 설명이다.

git의 branch는 다른 VCS들과의 몇 가지 차이 점을 가진다.

 

1. 매우 가볍다
2. 나중에 merge하도록 권장

"나중에 merge" 가 다른 VCS와 가장 큰 차이라 생각하면된다.

 

거기다 branch에서 작업하고 main branch에 반영할 때, pull request라는 메인 작업자의 허락이 떨어져야 main branch에 반영이 되는 기능도 제공한다.

 

이 외에도 여러가지 특징 및 장점들이 있다.

 

git이 브랜치를 다루는 과정을 알아보자.

---

git branch

git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 포인터 같은 것이다.

 

기본적으로 git은 master 브랜치(최근 디폴트 브랜치의 이름이 main으로 바뀜)를 만든다. 처음 커밋하면 이 main 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 main 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.

# 로컬 저장소 브랜치 조회
git branch

# 원격 저장소 브랜치 조회
git branch -r

# 원격 저장소 브랜치와 로컬 저장소 브랜치 모두 조회
git branch -a

# 새로운 로컬 저장소 branch 만들기
git branch <branch>

# branch 이름 바꾸기
git branch --move <from_branch> <to_branch>
git branch -m <from_branch> <to_branch>

# 로컬 저장소의 branch 제거
git branch --delete <branch>
git branch -d <branch>
## 지워질 브랜치에 커밋이 있을 경우에도 삭제를 취소하지 않고 강제로 브랜치 제거
git branch -D <branch>

branch 이동하기

git checkout <branch>

---

git merge

현재 브랜치에 다른 브랜치를 병합하는 커밋을 만든다.

# 1 <- 2 <- 3   (current branch)
#   <- 4 <- 5   (base branch)
git merge <branch> # 1 <- 2 <- 3 <- 6(merge)

가끔씩 3-way Merge가 실패할 때도 있다. Merge 하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하고 Merge 하면 git은 해당 부분에서 충돌(Conflict) 메시지를 출력한다.

 

충돌이 일어난 파일은 unmerged 상태로 표시되고, 개발자가 수동으로 해결해야 한다.

 

충돌을 해결하고 나서 해당 파일이 Staging Area에 저장됐는지 확인했으면 git commit 명령으로 Merge 한 것을 커밋한다.

git remote

협업을 위해서는 리모트 저장소를 로컬 저장소와 연결하고 관리해야 한다.

 

리모트 트래킹 브랜치의 이름은 <remote>/<branch> 형식으로 되어 있다.

 

예를 들어 리모트 저장소 origin 의 main 브랜치를 보고 싶다면 origin/main 라는 이름으로 브랜치를 확인하면 된다.

  # 연결된 원격 저장소 조회
git remote

# 원격 저장소와 URL 함꼐 보기
git remote -v

# 연결된 원격 저장소 url 조회, 일반적으로 origin 사용
git remote get-url <remote>

# 원격 저장소의 구처젝인 정보 확인하기
git remote show <remote>

# 원격 저장소 연결하기
git remote add <단축이름> <url>

# 원격 저장소 이름 변경하기
git remote rename <from_단축이름> <to_단축이름>

# 저장소 제거하기
git remote remove <단축이름>

# 원격 레포지토리에서 사라져 더이상 추적할 수 없는 로컬 저장소의 브랜치를 제거한다
git remote prune <remote>

git push

로컬 저장소를 원격 저장소로 Push한다.

# 원격 저장소에 브랜치가 없는 경우, 최초 스냅샷을 원격 저장소에 push한다.
git push --set-upstream <remote> <branch>
git push -u <remote> <origin>

# 원격 저장소에 브랜치가 있는 경우 다음처럼 push 할 수 있다
git push <remote> <branch> # 원격 저장소에 특정 브랜치를 push
git push # 원격 저장소에 현재 브랜치를 push

# 원격 저장소의 브랜치 삭제하기
git push <remote> --delete <branch>

로컬의 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 Push 해야 한다. 로컬 저장소의 브랜치는 자동으로 리모트 저장소로 전송되지 않는다.

git fetch

로컬 저장소에 없는 원격 저장소의 데이터를 로컬 저장소로 가져온다.

하지만 데이터를 로컬 저장소에 Merge하지는 않는다.

# 로컬 저장소에 없는 원격 저장소의 데이터를 가져옴
git fetch <remote>

# 원격 레포지토리에서 사라져 더이상 추적할 수 없는 로컬 저장소의 브랜치를 제거한다
git fetch --prune

git pull

원격 저장소의 데이터를 로컬 저장소로 가져온다.

git pull

# default 전략, merge 방식
git pull --no-rebase

# rebase 방식
git pull --rebase

---

git rebase

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다.

# 1 <- 2 <- 3   (current branch)
#   <- 4 <- 5   (base branch)
git rebase <branch> # 1 <- 4 <- 5 <- 2' <- 3'

Rebase 의 위험성

이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라

 

새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자.

 

그런데 그 커밋을 git rebase 로 바꿔서 Push 해버리면 동료가 다시 Push 했을 때 동료는 다시 Merge 해야 한다. 그리고 동료가 다시 Merge 한 내용을 Pull 하면 내 코드는 정말 엉망이 된다.

 

이 점을 유의하며 rebase를 활용하자.

---

Rebase vs. Merge

둘 중 무엇을 쓰는 게 좋을까? 정답은 히스토리에 있다.

 

히스토리를 보는 관점 중에 하나는 작업한 내용의 기록으로 본다. - merge

히스토리를 프로젝트가 어떻게 진행되었나에 대한 이야기로 본다. - rebase

 

개인적으로는 merge가 맞다고 본다.

 

git-book에서는 아래와 같이 언급했다.

 

일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.

 

아직 개인적으로 정리가 잘 안된것 같으니 꼭 다시 한번 보자. https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

마치며

일단 필요한 내용은 모두 봤다고 생각한다. 이제는 잘 쓸일만 남은 것 같다.