[github] 브랜치 개념 정리

읽기전!!

• /슬래시 사이/에 있는 내용은 사용자로부터 입력을 받는 곳을 표현하였습니다. 쓰실 때 양쪽 슬래시까지 지우고 새로운 내용을 입력하여 사용하셔야 합니다.

• 커밋 히스토리. 이해하기 편하게 커밋 메세지로 표현하였습니다. 새로운 커밋은 이전 커밋을 가리키고 있습니다.
  

GitHub repository

개발자가 프로젝트 코드를 체계적으로 저장하고 작업할 수 있는 클라우드 기반 리포지토리입니다. GitHub는 버전 관리 시스템인 Git을 기반으로, 개발자 간의 협업을 개선하는 추가적인 기능을 제공합니다. GitHub는 리포지토리 기능을 간편하게 사용할 수 있는 그래픽 UI를 제공합니다.
출처: 리포지토리란? >

Branch

하나의 레포에 여러 사람들이 여러 작업을 동시에, 독립적으로 진행할 수 있습니다. 이렇게 독립적으로 개발하는 것이 브랜치입니다.

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

• master 브랜치가 가장 최근의 커밋을 가리키고 있습니다.
• head는 현재 브랜치를 가리킵니다.

브랜치 생성하기

$ git branch /브랜치이름/

새로 만든 브랜치도 지금 작업하고 있던 마지막 커밋을 가리킵니다. 즉, 브랜치를 새로 만들었지만, 새로 만든 브랜치로 이동된 것은 아닙니다.

브랜치가 어떤 커밋을 가리키고 가리키고 있는지 확인하기

$ git log --oneline --decorate

f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to the central interface
34ac2 Fixed bug #1328 - stack overflow under certain conditions
98ca9 The initial commit of my project

위는 git에서 나온 예시입니다. 현재 f30ab라는 커밋은 master, testing이라는 두 브랜치를 모두 가리키고 있다는 내용입니다.

브랜치 이동하기

$ git checkout /브랜치이름/
새로 생성한 브랜치이름을 적는다면 해당 브랜치로 이동할 수 있습니다. 현재 checkout의 기능을 나누어 switch 등으로 나뉘었지만 여전히 사용이 가능합니다. 다시 git log를 이용해 어떤 브랜치가 현재 커밋을 가리키고 있는지 확인해보시면 현재 브랜치 이름만 나오는 것을 확인할 수 있습니다.

여기에서!! 새로 생성한 브랜치에서 새로 작업한 내용을 커밋합니다. 그러면 이전 브랜치는 여전히 과거의 커밋을 가리키고 있습니다. 그래서 이전 브랜치로 이동하면서 파일의 내용에서 새로 작업한 내용이 없어지는 것으로도 확인할 수 있습니다. 이것이 바로 독립적인 개발이 가능한 브랜치입니다.

심화
실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 40글자의 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고 지우기도 쉽습니다. 새로 브랜치를 하나 만드는 것은 41바이트 크기의 파일을(40자와 줄 바꿈 문자) 하나 만드는 것에 불과합니다. 따라서 git을 사용하면 브랜치를 복사하는 작업은 매우 간단합니다. 게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터(Merge Base) 합쳐야 하는지 알고 있습니다.

브랜치와 Merge

• 브랜치와 브랜치 합치기

마스터 브랜치로 다시 넘어와서 새로운 커밋을 하게 되면, 새로 만든 브랜치와는 다른 커밋 히스토리가 생기게 됩니다. 따라서 master에는 branch의 내용이 없는 상태입니다. 그리고 여기에서 다른 사람이 yellow라는 브랜치를 만들고 새로 커밋을 합니다. 하지만 커밋 내용은 유지하고 싶지만, yellow 브랜치는 필요가 없어졌습니다. 그래서 yellow 브랜치를 master 브랜치에 합쳐줄 것입니다.

• fast forward 방식
  먼저 $ git checkout master를 써서 HEAD를 master 브랜치로 이동시킵니다. 즉, 현재 브랜치는 master입니다. 여기에서 $ git merge yellow로 master 브랜치를 가장 최신의 커밋으로 이동시킵니다. 즉, 여기에선 yellow가 가리키는 커밋을 의미합니다. 이렇게 이동한 master 브랜치도 yellow가 가리키는 커밋을 가리킵니다. 즉, yellow를 없애도 최신 커밋이 유지가 되는 것입니다. 따라서 $ git branch -d yellow를 이용해 yellow를 지워 최종적으로 master와 yellow가 합쳐진 결과물과 같게 할 수 있습니다.

  $ git merge /브랜치이름/
$ git branch -d /브랜치이름/

• 3-way merge 방식
  
  branch가 다른 기능에 대한 작업을 많이 해서 가장 최신 커밋을 branch가 가리키게 되었습니다. 이럴 땐, 공통 조상 커밋인 "second commit"을 기준으로 merge를 하게 됩니다. merge의 방식은 같습니다. $ git merge branch로 하여 merge를 하게 되는데, master가 이동을 하는 것이 아닌 새로운 merge commit을 생성하여 이동합니다. 그래서 이런 커밋은 부모가 여러 개입니다. 마찬가지로, 기본 branch 브랜치를 지워줍니다. $ git branch -d branch
  
  이때!! 서로 다른 브랜치에서 같은 파일의 같은 부분을 수정했다면 충돌이 일어나 merge가 안 될 수도 있습니다. 이런 경우, 충돌된 부분을 unmerged 상태로 표시해주며, 작업한 개발자 간 상의하여 어떤 내용을 살릴지 결정합니다. 충돌된 부분을 모두 수정했을 경우, git add 명령으로 다시 Git에 저장합니다. git status 명령으로 충돌이 해결된 상태인지 다시 한번 확인해볼 수 있습니다. 최종적으로 git commit 명령으로 Merge 한 것을 커밋합니다.

• 충돌 해결 후 Merge 할 때 커밋 메시지

Merge branch 'branch'

Conflicts:
    index.html//충돌된 파일명
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
#	.git/MERGE_HEAD
# and try again.


# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
#	modified:   index.html//충돌된 파일명
#

브랜치 관리하기

• 브랜치 목록보기

  $ git branch

  //결과
  * master

  결과에서 *는 현재 브랜치입니다.

• 각 브랜치의 마지막 커밋 메세지 보기
  $ git branch -v

  //결과
  * master  7a98805 Merge branch 'branch'

• 현재 브랜치 기준 머지된 브랜치인지 확인하기
  $ git branch --merged

  //결과
  branch
  *master

  다른 브랜치 기준으로 보려면 마지막에 브랜치이름을 붙여주면 됩니다.

• 브랜치 삭제시 주의하기
  아직 Merge 하지 않은 커밋을 담고 있으면 git branch -d 명령으로 삭제되지 않습니다.

---

이상으로 브랜치에 대한 기본적인 개념을 정리하였습니다. 직접 실행해 보면서 어느 정도 감으로 알고 있었지만, 본격적으로 깃과 깃헙에 대해 공부하기 시작하니 머릿속이 정리되는 것 같습니다. 개념만 보지 말고 익숙해집시다!

출처: git >

추가적으로, 리모트에 대한 개념이 정리되면 리모트 저장소, 리모트 브랜치에 대해서 정리할 계획입니다.