브랜치란?
정의
사람들이 동일한 소스 코드를 기반으로 하되, 서로 다른 기능이나 수정 작업을 동시에 진행할 수 있게 해주는 Git의 기능이다.
각자 독립적인 작업 공간(브랜치)를 만들어 작업한 뒤, 필요할 때 원래 버전(`main` 등)과 비교·병합하여 새로운 버전을 만들어 낸다.
생성 방법
git branch ${브랜치명} # 브랜치 생성
git switch ${브랜치명} # 브랜치 전환 (또는 git checkout ${브랜치명})
주요 명령어
- `git checkout`
- 예전 방식
- 브랜치 전환 + 파일 복원 기능을 모두 담당
- 현재는 `git switch`(브랜치 전환)와 `git restore`(파일 복원)로 기능이 나누어짐
- `git switch`
- 요즘 권장 방식 (Git 2.23 이상)
- 브랜치 전환 전용 명령어
- `-c` 옵션으로 새 브랜치 생성 가능 (`git swtich -c ${브랜치명}`)
- `git restore`
- 파일 복원 전용 명령어
- 특정 파일이나 커밋 상태로 되돌릴 때 사용
git restore ${파일명} # 최근 커밋 상태로 복원
git restore --source=HEAD~1 ${파일명} # 한 커밋 전 상태로 복원작업 합치기
Merge
말 그대로 두 브랜치의 변경 내용을 병합하는 명령어다.
예를 들어, 아래와 같은 상황을 가정해보자.
- `main` 브랜치에서 `commit1`까지 작업 완료
- 새로운 기능 개발을 위해 `step1` 브랜치를 생성하고 `commit2` 작성
- `commit1`에서 버그가 발견되어 `bugFix` 브랜치를 만들어 `commit3`으로 수정
이제 bugFix의 수정 내용을 step1에 합치고 싶다면, 다음 순서로 진행한다.
1. step1로 이동 후 bugFix로 병합
git switch step1 # step1 브랜치로 이동
git merge bugFix # bugFix 브랜치를 병합
2. bugFix 브랜치도 최신화
git switch bugFix # bugFix 브랜치로 이동
git merge step1 # step1 브랜치를 병합
주의할 점
- 만약 bugFix와 step1이 같은 부분의 코드를 수정했다면, 병합 시 충돌(conflict)이 발생한다.
- 이때는 충돌 부분을 수정한 뒤 병합을 완료하면 된다.
Rebase
한 브랜치의 기반(base)를 다른 브랜치 위로 옮겨 붙이는 방식이다. 겉으로 보면 merge처럼 결과적으로 코드가 합쳐지는 건 비슷하지만, 커밋 히스토리를 깔끔하게 일렬로 다시 쓰는 게 핵심이다.
예시 상황은 merge와 같다.
1. bugFix를 step1 기준으로 재배치하기
git switch bugFix # bugFix 브랜치로 이동
git rebase step1 # bugFix의 커밋들을 step1 위로 옮겨 붙이기- bugFix에서 만든 `commit3`이 그냥 그대로 쓰이는 게 아니라 `commit2` 뒤에 새로 복사된 형태로 붙는다.
- 그래서 bugFix 입장에서는 `commit3'`처럼 다시 쌓인 커밋이 생긴 것처럼 보인다.
즉, bugFix의 변경 사항이 마치 step1 이후에 바로 이어서 작업한 것처럼 히스토리가 재정렬된다.
2. step1도 bugFix와 동일한 최신 위치를 가리키게 만들기
git switch step1 # step1 브랜치로 이동
git rebase bugFix # step1을 bugFix 위로 이동- bugFix가 더 앞선 히스토리를 가지게 되었기 때문에, step1은 단순히 가리키는 위치만 bugFix의 최신 커밋으로 이동한다.
- 추가 커밋이 생기지 않는다. 히스토리만 깔끔하게 정리된다.
HEAD
Git을 사용하다 보면 종종 HEAD라는 단어가 등장한다.
`HEAD`는 우리가 현재 작업 중인 커밋의 위치를 가리키는 포인터이다. 작업 트리에 변화를 주는 Git 명령어들은 대부분 HEAD를 변경하는 것부터 시작한다.
상대 참조
HEAD가 가리키는 커밋을 기준으로 이전 커밋들로 이동할 때 유용하게 쓰인다.
캐럿(^) 사용
git switch HEAD^- `HEAD^`는 현재 커밋의 이전 커밋을 의미한다.
- 즉, 한 단계 이전의 커밋으로 HEAD를 이동시킨다.
git switch HEAD^^ # 두 단계 이전
git switch HEAD^^^ # 세 단계 이전- 캐럿(^) 개수만큼 뒤로 이동한다.
틸드(~) 사용
git switch HEAD~2- `~` 뒤에 숫자를 붙이면 그 숫자만큼 이전 커밋으로 이동한다.
브랜치가 가리키는 위치 변경
상대 참조는 HEAD 뿐만 아니라 브랜치가 가리키는 위치도 변경할 수 있다.
예를 들어, step2 브랜치를 commit3으로 옮기고 싶다면, 아래와 같은 명령어를 쓰면 된다.
git branch -f step2 step1~1- step1 기준으로 한 단계 이전 커밋을 step2가 가리키도록 한다.
작업 되돌리기
git reset
로컬에서만 작업할 때 사용하는 되돌리기 방법이다.
예를 들어 아래 그림에서 `commit3`을 잘못 커밋했다고 가정해보자.
git reset HEAD~1- `HEAD~1` → HEAD의 한 단계 이전 커밋을 의미한다.
- 즉, 이전 커밋을 현재 상태로 되돌려라는 뜻이다.
결과적으로 `commit3`이 깔끔하게 사라지고 현재 브랜치가 `commit2`를 가리키게 된다.
즉, reset은 커밋 기록 자체를 지우는 행위이다. 따라서 다른 사람이 해당 커밋을 기준으로 작업 중이라면 충돌이 발생하게 된다.
주요 모드
| 모드 | 명령어 | 스테이징 영역(index) | 워킹 디렉터리(파일) | 특징 |
| --soft | git reset --soft <commit> | ❌ 유지됨 | ❌ 유지됨 | 커밋만 되돌림 (변경사항은 그대로 staged 상태) |
| --mixed (기본값) | git reset --mixed <commit> 또는 git reset <commit> | ✅ unstaged로 변경 | ❌ 유지됨 | 커밋은 되돌리고, 파일은 남기되 add는 풀림 |
| --hard | git reset --hard <commit> | ✅ 삭제됨 | ✅ 삭제됨 | 모든 변경사항 완전히 제거 (복구 불가) |
git revert
공유된 브랜치에서도 안전하게 커밋을 취소할 수 있는 방법이다.
예를 들어 `commit2`의 내용을 취소하고 싶다면:
git revert HEAD
- 기존 `commit2`는 그대로 남고 `commit2'`라는 반대 내용이 추가된다.
즉, `revert`는 기존 커밋은 그대로 두되 반대 동작을 하는 새 커밋을 만들어서 원상복구하는 방식이다. (다른 사용자에게도 변경 내역을 보낼 수 있다.)
삭제된 커밋과 브랜치 복구
reflog
Git은 모든 명령 수행 기록(reset, commit, checkout 등)을 자동으로 `reflog`에 저장한다. 즉, 무엇을 지웠는지조차 기록으로 남는다.
git reflog- 커밋 해시값이 표시된다. 이 해시를 이용하면 해당 커밋으로 돌아갈 수 있다.
커밋 복구
git reset --hard ${커밋2의 해시}- 커밋 2가 삭제되기 전 상태로 복원된다.
브랜치 복구
git branch ${새 브랜치 이름} ${커밋 3의 해시}- 새 브랜치를 생성하고, 삭제되기 전의 커밋을 가리키게 할 수 있다.
git remote
- 원격 저장소를 관리한다.
어? 페어가 도망가버렸어! 내 코드 어떡하지?
git remote add : 깃헙 레포지토리에 빨대를 꼽는다.(통로)
git pull : 원격 저장소에서 로컬 저장소로 변경사항을 다운로드한다.
git remote rm : 원격 레포지토리가 로컬 레포지토리에서 제거된다. 이를 통해 원격 레포지토라와의 연결이 해제되며, 더 이상 해당 원격 레포지토리로부터 데이터를 가져오거나 푸시할 수 없다.(빨대를 치운다)
git remote add로 페어 레퍼지토리 연결 → git pull로 로컬로 가져오기 → git remote rm으로 통로 제거 → 내 레포지토리 연결 → git push로 받은 코드 레포지토리에 올리기
git commit --amend
새롭게 변경한 내용을 이전 커밋에 덮어쓰고 싶을 때는 `--amend` 옵션을 사용한다. 이 옵션은 기존 커밋을 수정하는 것이 아니라, 새로운 커밋을 생성하고 기존 커밋을 대체한다.
⚠️ 따라서 `--amend`는 이미 push한 커밋이나 다른 작업자가 함께 작업한 커밋에는 사용하면 안된다.
커밋 해시가 변경되기 때문에, 원격 저장소에 push할 때 충돌이나 히스토리 불일치가 발생할 수 있다.
`git commit --amend`는 주로 아래와 같은 상황에서 사용된다.
- 커밋 메시지를 수정하고 싶을 때
- 이전 커밋에 빠뜨린 파일을 추가하고 싶을 때
git cherry-pick
어? 브랜치를 변경하지 않고 작업을 진행해버렸어 어떡하지?
실수로 브랜치를 변경하지 않고 커밋을 해서 커밋 내용을 다른 브랜치로 옮기고 싶다.
1. B2, B3, B4를 다른 브랜치로 옮기고 싶다.
2. 브랜치를 새로 만든다.
git checkout -b feature2
3. 원하는 커밋을 특정 브랜치로 옮긴다.
git cherry-pick B2 B3 B4
...을 통해서 처음 것과 끝에 것을 연결하면 연속된 커밋을 모두 가져올 수 있다.
git cherry-pick B2...B4
참조
'우아한테크코스' 카테고리의 다른 글
| [Java] 정적 팩토리 메서드 (0) | 2025.10.30 |
|---|---|
| [Java] Enum이란? (0) | 2025.10.29 |
| [우아한 테크코스] 프리코스 2주차 회고 (0) | 2025.10.28 |
| [Java] 일급 컬렉션 (0) | 2025.10.27 |
| [Java] 모든 원시값과 문자열 포장 (0) | 2025.10.27 |
