나의 길
git 브랜치(branch) 본문
이전 포스팅에서 git의 버전관리를 알아보았는데 조금 더 완벽한 버전관리를 위해 git의 브랜치를 배워보도록 하겠습니다!
브랜치(branch)란?
원래 나뭇가지라는 뜻으로 가지를 뻗는 것처럼 관리하기 위한 개념입니다.
(저도 이 말이 잘 이해되지 않지만 밑에 내용을 보면 이해가 될 거예요!)
브랜치의 필요성
이전 포스팅처럼 하나의 저장소가 있다고 가정해보자. 저장소에 코드 버전을 관리하던 중, 이 저장소의 코드와 유사하지만 조금은 다른 코드를 원하는 상황이 생긴다면 저장소를 복사한 후 이전 저장소의 코드와 다른 부분을 수정한 후 또다시 버전 관리하는 상황이 생길 수 있습니다.
이런 상황에 우리는 git init을 통해 만들어진 master 브랜치 이외의 브랜치를 만들어 해결할 수 있습니다.
예를 들어 우리가 [그림 1]의 kakao와 naver를 개발하는 개발자라고 생각해봅시다. [그림1]의 버전 2의 kakao의 기능 중 버전 1의 naver가 필요한 기능이 있다면 git을 배우기 전이라면 단순히 버전2의 kakao의 코드를 버전1의 naver코드에 복사/붙여넣기를 할 것입니다.
이 방법은 버전 1의 naver가 쓰고있는 버전2의 kakao 기능이 버전3에서 수정되었다면 버전1의 naver 기능도 수정되어야 하지만 당연하게도 수정되지 않습니다.
이처럼 위의 방식은 오류의 여지가 많고 비효율적이기에 우리는 브랜치를 사용하여 관리할 것입니다.
브랜치 관련 명령어
이전 명령어들(기억이 안 나면 여기)과 혼합하여 실습을 해보도록 하겠습니다.
git branch → 커밋내역이 없으면 브랜치 목록이 안 뜬다.
git log → HEAD가 어디를 가리키는지 확인 (밑에서 HEAD와 branch 추가 설명!)
git branch [브랜치명] → 브랜치 만들어서 로그 보여주기
git checkout [브랜치명] : 해당 브랜치로 이동
→ git checkout -b [브랜치명] : 해당 브랜치 만들고 브랜치로 이동
git log --oneline : log를 한 줄로 보여주기
→ git log -oneline --branchs --graph : 브랜치와 커밋을 보기 쉽게 만들어 주는 log 옵션들
(다양한 옵션이 존재합니다.)
git stash : 수정 중인 파일 감추기(파일이 tracked 상태일 때 가능)
git stash pop : 감춘 파일 수정 상태로 되돌리기
git stash apply, git stash drop 명령어도 존재한다.
그 밖에 명령어
git log [브랜치명]..[브랜치명] : 뒤에 있는 브랜치는 있지만 앞에 브랜치에는 없는 커밋을 보여줌
git branch -d [브랜치명] : 병합이 끝난 브랜치 삭제
(브랜치가 삭제되지만 브랜치명을 똑같이 만들면 기록이 남아있다. 삭제보다는 숨겨놓는 개념)
브랜치 병합(브랜치 활용)
이번에는 브랜치를 활용하여 병합(merge)을 해보겠습니다.
서로 다른 파일 병합
ort 공식문서 참고
https://git-scm.com/docs/merge-strategies
참고 : fast-forward 방식 실습
같은 파일의 다른 부분 수정 후 병합
같은 파일의 같은 부분 수정 후 병합
병합 시 conflict(충돌)라는 문구를 볼 수 있습니다.(충돌이 일어나 병합할 수 없다는 뜻입니다.)
충돌된 문서는 <<<<<<< HEAD, ======, >>>>>>> Lee가 추가되어 있는 것을 볼 수 있습니다.
HEAD는 현재 브랜치에서 수정한 부분, Lee는 Lee 브랜치에서 수정한 부분이라는 표시입니다.
그럼 conflict를 해결하고 Lee가 수정한 것으로 병합해 보도록 하겠습니다.
수정한 파일을 커밋하게 되면 정상적으로 conflict가 해결된 것을 볼 수 있습니다.
일반적으로 명령어를 통해 더 이상 사용하지 않는 브랜치는 삭제해 줍니다.
브랜치 작동 원리(심화)
브랜치는 최신 커밋을 가리키고, HEAD는 현재 작업 중인 워킹트리를 가리킨다.
위의 그림은 master 브랜치로 c2 커밋까지 하였고, c2 커밋에서 iss53 브랜치를 생성하고 c3 커밋을 하면 해당 브랜치는 앞으로 나아간다. 여기서 master 브랜치로 돌아가 hotfix를 처리하기 위해 브랜치를 만들고 c4 커밋을 한다면 hotfix 브랜치는 앞으로 나아간다. 여기까지 설명이 위의 그림이다.
여기서 master와 hotfix를 merge 한다면 위와 같이 된다. hotfix 브랜치는 iss53 브랜치에 영향을 주지 않는다. (이것이 fast-forward 방식) 그리고 iss53 브랜치가 c5 커밋을 하고 master 브랜치와 iss53 브랜치를 merge 하면
이와 같은 그림이 된다. master 브랜치의 부모도 c2, iss53 부모도 c2이고, c4, c5의 커밋을 병합하여 c6 merge 커밋을 만들어 낸다.(이것이 3-way-merge)
느낀 점
명령어를 익혀서 쓰기만 했었는데 Git 공식문서와 참고서를 보며 동작원리와 활용법을 공부하니 Git을 실제 사용하면서도 그냥 넘어갔던 부분들이 보이게 되어 뿌듯했고 Git을 활용하면서 부족한 부분을 더 알게 되었으니 그때마다 공부해서 이 카테고리에 포스팅해보겠습니다.
다음 포스팅은 GitHub!
그림출처 : http://git-scm.com
Git
git-scm.com
'git&github' 카테고리의 다른 글
| github actions 알아보기 (0) | 2023.09.23 |
|---|---|
| git 버전 관리 (2) | 2023.02.07 |
| git&github를 알아보자. (0) | 2023.01.27 |
