목차

• branch 운영
  • branch 생성
  • branch 삭제
  • branch 전환
  • branch 통합
  • commit

Branch 운영

branch 생성

어떤 형태로 토픽 브랜치를 구성할지 협업하는 사람들과 결정이 우선되어야 한다.
ex. naming, 어떤 상황에서 branch를 만들지, 어느 시점에서 병합할 것인지 등등

[명령어]

• 생성 : git branch <브랜치명>
• 브랜치 목록 : git branch

branch 삭제

[명령어]

• git branch -d <삭제할 브랜치 명>

branch 전환

작업을 하려면 어떤 branch에서 작업할지를 선택해야 한다. 이를 checkout 명령어를 사용하여 원하는 branch로 전환한다. checkout을 수행하면, 해당 branch의 마지막 커밋 내용이 워크 트리(로컬)에 펼쳐진다.
이말은 branch전환을 하기위해선 변경사항이 없는 상태여야 한다는걸 의미한다.
이 후에 실행한 커밋은 전환된 지금 branch에 추가된다.

[명령어]

• git checkout <브랜치명>

HEAD

HEAD 개념을 알게되면 커밋단위로 간편하게 이동이 가능하다.

모든 브랜치에는 HEAD값이 존재하는데, 해당 브랜치의 마지막 커밋을 뜻한다.
즉, 특정 branch의 마지막 커밋에 대한 포인터이다.(항상 현재 브랜치의 최신 커밋을 포인팅한다.)
HEAD를 이동하면, 사용하는 branch가 변경된다.

**[명령어]**

• head 확인 : git log
• head 이동 : 커밋 이동할 때 head 해시는 너무길어서 불편하다. 상대참조를 활용한다.
  • ^ : 한 커밋 위(부모 커밋)으로 이동(이전 커밋으로 이동)
    • ex : git checkout HEAD^
    • 결과 : HEAD is now at 0f179c9 add analyze schema2
    • 부모 커밋은 근원 branch 즉, master같은 상위 branch를 뜻하는것이 아니다. 이전 commit을 부모 커밋이라고 한다.
  • ~<num> : num전으로 이동
    • ex : git checkout HEAD~2
    • 결과 : HEAD is now at 1d329d5 add analyze schema1
  • 원복 : git checkout [브랜치명]

stash

아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어다.
stash를 사용하여 stage와 local 내에서 일시적으로 저장해 둘 수 있다.
이 stash에 저장된 변경 내용은 나중에 다시 불러와 원래의 브랜치나 다른 브랜치에 커밋할 수 있다.

[필요 케이스]

• 작업중에 다른 요청이 들어와 잠시 브랜치를 변경해야하는 상황일때, 아직 완료되지 않은 일을 커밋하는 것이 껄끄러울 때( commit 또는 stash를 하라는 오류 메시지가 뜬다)
• 커밋하지 않은 변경 내용이 work tree에 남아 있는 경우

[명령어]

• 저장 : git stash(실행하면 워크트리가 깨끗해진다.)
• stash 목록 확인 : git stash list
• stash 적용하기(다시 가져오기)
  • git stash apply (가장최근)
  • git stash apply stash@{0} (id 지정)
• stash 제거 : git stash drop(동일하게 최근, 지정 삭제 가능)

Branch 통합하기

작업이 완료된 토픽 브랜치는 최종적으로 통합 브랜치에 병합된다.
브랜치 통합에는 merge를 사용하는 방법과 rebase를 사용하는 방법의 2가지 종류가 있다.

merge

여러 개의 브랜치를 하나로 모을 수 있다.

현재 local이 최신 버전이 아닌 경우 (다른 사람이 push를 하여 remote가 업데이트된 경우) push 요청이 거부되어 버린다.
이런 경우 merge를 진행하여 다른 사람의 업데이트 이력을 로컬에도 갱신 해야한다. 만약 merge하지 않은 채로 이력을 덮어쓰게 되면 다른 사람의 업데이트 내역이 사라진다.

[명령어]

• 병합 : git merge <commit>
  • 지정한 커밋 내용이 HEAD가 가리키고 있는 브랜치(보통 현재 브랜치)에 넣어진다.
  • ex : master 브랜치에 토픽 브랜치를 넣고 싶으면, git checkout master(HEAD 변경 후)git merge <토픽브랜치>를 수행한다. 그러면 master와 토픽브랜치는 같은 커밋을 바라본다.

[case 1]

만약 통합 브랜치가 변경이력이 없다면 매우 쉽게 병할할 수 있다. 토픽브랜치는 현재 통합브랜치의 모든 이력을 포함하고 있기때문이다.
"master" 브랜치에서 분기된 "bugfix" 브랜치이며, 분기 이후로 master는 변경이력 없어서 쉽게 병합이 가능하다.

[case 2]

하지만 토픽 브랜치 분기 이후에 통합브랜치에 여러가지 변경 사항이 발생했다면, 두 브랜치 내용을 통합할 필요가있다.
그래서 현재 브랜치("bugfix")에서 통합브랜치 내역을 가져오고, 병합을 마치고 다시 커밋을 수행해야한다.

### rebase

rebase하면 bugfix브랜치의 이력이 master 브랜치 뒤로 이동하게 된다. 하나의 줄기로 이어지게 된다.
이때 X와 Y에서 master 내용과 충돌하는 내용을 수정해야 한다.

[rebase 예제1]

• 토픽 브랜치로 이동(issue3)
• rebase 명령어 : git rebase master
• 충돌발생
• 수정
• git rebase --continue : rebase는 commit이 아닌 continue 실행
• rebase 취소 : --abort 실행

[rebase 예제2]

master 브랜치에는 아직 issue3의 내용이 합쳐지지 않았다.
추가작업을 진행해야한다.

• git checkout master
• git merge issue3

---

상세한 예제 참고 : https://backlog.com/git-tutorial/kr/stepup/stepup1_5.html

---

conflict

자동 병합에 실패한 경우다. 경우에 따라 자동으로 병합할 수 없는 경우도 있다.
(merge의 1,2번 케이스이다.)

[발생 원인]
local과 remote 양쪽에서 동일한 부분을 변경한 경우, 두 변경내용중 어느 쪽을 저장할 것인지 자동으로 판단 할 수 없기 때문에 충돌을 발생시켜 수동처리를 요구한다.

[예제]

<<<<<< 부터 >>>>>>까지가 충돌이 발생한 부분이다.
=====A는 로컬 저장소, B는 원격 저장소의 변경 내용을 나타낸다.

[예제]
<<<<<<<<<<< HEAD
A 내용
========
B 내용
>>>>>>>>>>>7a09fd3002c67e50158edc467fe3b8093aac9685

Commit

[명령어]

• 커밋 : git commit
• 커밋&메시지 작성 : git commit -m <메세지>

업로드하려면 commit이라는 명칭의 명령을 수행해야한다. commit을 하려면 메시지를 필수로 입력해야한다.
메세지는 xx 기능 수정, 추가 등 각 commit별로 구분할 수 있도록 40자안으로 작성한다.

Tip) 메세제는 commit을 구분할 수 있는 유일한 key라고 생각하며 작성하자.

commit 전

저장할 파일을 index에 등록해야 한다.

• git add <변경파일>

Summary

로걸에서 branch를 핸들링하는 방법을 알아보았다.

• 생성,삭제 그리고 전환을 더욱 간편하게 하는 방법(HEAD 상대참조)
• 작업 중인 내용을 임시저장하여 언제든지 전환할 수 있음
• merge가 필요한 상황, conflict가 발생하는 상황 그리고 해결하는 방법