브랜치 사용하기

브랜치란?

• 하나의 코드 관리 흐름
  
• main 브랜치: 레포지토리를 만들고 커밋을 하면 자동으로 생기는 브랜치
• git branch [새 브랜치 이름]: 새로운 브랜치를 생성
• git checkout [기존 브랜치 이름]: 그 브랜치로 이동

브랜치 다뤄보기

• git brnach: 모든 브랜치 조회하기
• git branch -d [기존 브랜치 이름]: 브랜치 삭제
• git checkout -b [새 브랜치 이름]: 새로운 브랜치를 생성하고 그 브랜치로 바로 이동

브랜치 merge하기

• 다른 브랜치에서 했던 커밋을 가져오고 싶을 때 사용하면 됨
• git merge [기존 브랜치 이름]: 현재 브랜치에 다른 브랜치를 머지
• 머지 커밋: 머지를 통해서 생겨난 커밋

merge할 때 conflict가 날 수도 있어요!

CONFLICT (content): Merge conflict in calculator.py: 머지를 하다가 충돌이 발생했다!

• 해결방법
  1. 컨플릭트가 발생한 파일 열기
  2. 머지의 결과가 되었으면 하는 모습대로 코드를 수정하기
  3. 커밋

conflict가 났을 때 merge 자체를 취소해도 됩니다

• git merge --abort: 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감
• 꼭 머지를 해야하는 상황이라면 Conflict를 해결하고 커밋을 하는 게 정석임
• 머지 자체를 취소해도 되는 상황
  • Conflict가 발생한 파일들이 너무 많아서 Conflict를 최소화할 수 있는 방식으로 파일들을 다시 수정하고 커밋한 다음에 머지를 하고 싶을 때
  • 그냥 좀더 나중에 머지하고 싶을 때

여러 파일에서 conflict가 났을 때는?

• 원리는 파일 하나일 때와 같음
• 파일 하나씩 conflict를 해결하고 git add [파일 이름] 커맨드로 하나씩 staging area에 올리고 커밋하기(중간중간에 git status 커맨드로 현재 상태 확인하면서)
• 모든 파일들의 conflict를 다 해결하고, git add . 커맨드로 한번에 staging area에 올리고 커밋하기

Remote Repository의 브랜치는 이렇게 보입니다!

GitHub에서 Math_Box라는 리모트 레포지토리(remote repository)를 만들고 로컬 레포지토리(local repository)의 내용을 그 리모트 레포지토리에 보내기위해 아래와 같은 커맨드 2개를 실행한 적이 있음

• git remote add origin https://github.com/kyuri-dev/Math_Box.git
  • remote: 리모트 레포지토리에 관한 작업을 할 때 쓰는 커맨드
  • add: 새로운 리모트 레포지토리를 등록하겠다는 뜻
  • orgin:https://github.com/kyuri-dev/Math_Box.git 리모트 레포지토리를 origin이라는 이름으로 등록하겠다는 뜻
    • origin이 아닌 원하는 다른 단어를 입력해도 큰 상관은 없음
    • 하지만 Git에서는 리모트 레포지토리를 최초로 추가할 때 origin이라는 이름으로 가리키는 것이 관례화되어 있음
• git push -u origin master
  • 현재 로컬 레포지토리에 있는 master 브랜치의 내용(=master 브랜치와 관계된 모든 커밋들)을 origin이라는 리모트 레포지토리로 보낸다는 뜻
  • 이때 같은 이름의 브랜치로 전송하게 되는데 만약 origin이라는 리모트 레포지토리에 master 브랜치가 없으면 master 브랜치를 새로 생성하고 푸시함
  • -u: --set-upstream이라는 옵션의 약자
    • 로컬 레포지토리에 있는 master 브랜치가 origin에 있는 master 브랜치를 tracking(추적)하는 걸로 설정됨
    • tracking: 로컬 레포지토리의 한 브랜치가 리모트 레포지토리의 한 브랜치와 연결되어 그것을 계속 바라보는 상태가 되는 것
    • 이렇게 맺어진 연결 상태를 tracking connection이라고 함
    • tracking connection이 서로 맺어진 경우,리모트 레포지토리의 브랜치를 로컬 레포지토리의 브랜치의 upstream branch라고 함
    • -u 옵션을 주지 않으면 git push를 하고 싶을 때 git push origin master:master라고 해줘야 하며 git pull 도 마찬가지임
      • origin은 리모트 레포지토리
      • 먼저 나오는 master는 로컬 레포지토리의 master 브랜치(~에서)
      • 뒤에 나오는 master는 리모트 레포지토리의 master 브랜치(~으로)를 나타냄
• 즉, 같은 이름이지만 서로 다른 2개의 브랜치가 있다는 것
  • 로컬 레포지토리의 master 브랜치
  • 리모트 레포지토리의 master 브랜치
    
• master가 로컬 레포지토리의 master 브랜치를 나타내고
• origin/master가 리모트 레포지토리의 master 브랜치를 나타냄
• 로컬 레포지토리의 master 브랜치에서 여러 커밋을 했지만 git push를 해준 적은 없서 위 그림처럼 origin/master가 master보다 이전의 커밋을 가리키고 있는 것임

master 브랜치와 premium 브랜치 둘다 push하기

• premium branch도 git push를 하려면 git push --set-upstream origin premium을 해줘야 tracking connection이 됨
  

HEAD와 브랜치의 관계

• 브랜치: 코드를 관리하는 하나의 흐름 -> 어떤 커밋을 가리키는 존재 -> 포인터
• HEAD: 커밋을 가리키는 존재 -> 포인터
• 머지: 헤드가 가리키던 커밋에 다른브랜치가 가리키던 커밋을 합쳐서 새로운 커밋을 만드는 작업
  

git reset의 비밀

1. git reset 커맨드를 사용하면

• HEAD는 여전히 같은 브랜치를 가리키고,
• HEAD가 가리키는 브랜치가 다른 특정 커밋을 가리키게 됨
• 이 때문에 결국 HEAD가 간접적으로 가리키던 커밋도 바뀌게 됨

2. • 과거의 커밋으로 git reset을 한다고 그 이후의 커밋들이 삭제되는 게 아니며 계속 남아있음
   • git reset은 과거의 커밋뿐만 아니라 현재 HEAD가 가리키는 커밋 이후의 커밋으로도 할 수 있음

git reset과 git checkout의 차이점

• git checkout이 하는 일:
  • HEAD가 직접적으로 가리키는 것을 바꿀 수 있음
  • git checkout 뒤에는 커밋 아이디 또는 브랜치의 이름을 줘서
  • HEAD가 직접 커밋을 가리키거나, 브랜치를 가리키도록 할 수 있다는 뜻
    git checkout 9033
    
• Detached HEAD:HEAD가 직접 커밋을 가리키고 있는 상태
• HEAD가 특정 커밋을 직접 가리키게 하는 이유는 여러가지가 있으나 주된 이유 한 가지는 과거의 특정 커밋에서 새로운 브랜치를 만들고 싶을 때임
  git branch premium

git checkout premium
  
• git checkout 커맨드를 사용해서 다른 브랜치로 이동할 때 벌어지는 일
  • HEAD가 다른 브랜치가 가리키던 커밋을 가리키게 되면
  • 그에 맞게 working directory 내부도 바뀌게 되고,
  • 그 결과 우리는 브랜치가 변경되었다는 걸 실감할 수 있는 것
• git reset vs git checkout
  

새로운 커밋을 만들지 않는 merge도 있습니다

• fast-forward 머지: 새로운 커밋이 생기는 게 아니라 단지 브랜치가 이동하게 되는 머지
  커밋 히스토리에서 같은 선(line) 상에 있는 브랜치를 머지할 때 Fast-forward 머지가 이루어짐
• 3-way 머지 (머지 커밋): 커밋 히스토리 상에서 분리된 2개의 선에 각각 존재할 때 머지를 하면 머지 커밋이 새롭게 생기는 것
  

• base때의 내용과 비교했을 때 달라진 부분이 있는 것이 우선시 됨
• 두 브랜치에서 둘다 변화가 일어났을 때는 Conflict를 발생시켜서 사용자가 스스로 선택하게끔 함