참고: Do It! 깃&깃허브 입문
모든 버전 관리 시스템에는 '브랜치(Branch)'라는 개념이 있다.
참고로 그 동안 몇십개의 프로젝트를 뛰어봤지만 SVN 사용하는 프로젝트에서는 브랜치를 따서 작업하는 곳을 보지 못했다.
나무가 가지에서 새 줄기를 뻗듯이 여러 갈래로 퍼지는 데이터 흐름을 브랜치라고 한다.
브랜치가 필요한 이유
제품 하나를 만들어서, 여러 고객사에 제품을 납품한다고 가정한다.
이 때, 제품이 출시되고 나서 고객사마다 요구하는 요구사항이 다른데, 이 요구 사항을 반영해주다보면 고객사마다 제품이 달라지고 사용설명서도 달라질 것이다.
이 때 어떻게 해야 할까?
책에서는 저장소 전체를 여러 개 복사해서 각 고객사의 이름을 붙인 다음 저장소마다 버전 관리를 따로 하는것을 먼저 예로 들었는데 내가 투입됐던 프로젝트에서는 if else 범벅이었다. 그 때 소스보고 충격받은건 둘째치고 현실적으로는 관리하기가 정말 힘들었다.
어쨌든 책에서 말하는 저장소를 따로 관리하는 방법은 효율적이지 않다. 먼저 고객사마다 디렉터리를 복사하면 출시 전까지 만들었던 내용이 동일하기 때문에 자료가 중복된다. 또 버전 관리 시스템의 장점 중 하나는 파일 이름을 더럽히지 않는 것인데, 이 방법을 사용하면 고객사마다 디렉터리 이름을 다르게 사용해야 한다.
마지막으로 더 중요한 문제가 있는데 만약 G사에서 작업을 마쳤는데 해당 기능이 A사에서도 필요한 기능이라면?
단순하게 G사에 있는 최신 상태의 코드를 복사해서 A 디렉터리에 붙여 넣은 다음 A사 디렉터리에서 새로운 버전을 커밋하면 될까?
그 기능과 연계된 다른 작업들이 있다면 A사에 디렉터리에서는 오류가 발생할 수 있고, 오류를 없애기 위해 하나하나 찾아가면서 필요한 파일들을 계속 붙여넣어야 할 수도 아니면 통으로 다 덮어버리면서 기존에 추가했던 기능들이 사라질 수도 있는 여러문제들이 발생한다.
이 때 필요한 기능이 바로 브랜치(Branch)이다.
브랜치 기능
깃으로 버전 관리를 시작하면 기본적으로 master(main)라는 브랜치가 만들어진다.
사용자가 커밋할 때마다 master(main) 브랜치는 최신 커밋을 가리킨다. 즉, 브랜치는 커밋을 가리키는 포인터와 비슷하다고 생각하면 된다.
새 브랜치를 만들면 어떻게 될까? 새 브랜치를 만들면 기존에 저장한 파일을 master 브랜치에 그대로 유지하면서 기존 파일 내용을 수정하거나 새로운 기능을 구현할 파일을 만들 수 있다. 이렇게 master 브랜치에서 뻗어 나오는 새 브랜치를 만드는 것을 '분기(branch)'라고 한다.
새 브랜치에서 원하는 작업을 다 끝냈다면 새 브랜치에 있던 파일을 원래 master 브랜치에 합칠 수 있다. 이렇게 분기했던 브랜치를 master 브랜치에 합치는 것을 '병합(merge)' 한다고 한다.
'Git&GitHub' 카테고리의 다른 글
[GIT 09] 새 브랜치에 커밋 (0) | 2023.01.19 |
---|---|
[GIT 08] 브랜치(Branch) 생성 (0) | 2023.01.19 |
[GIT 06] 작업 되돌리기 (0) | 2023.01.19 |
git(깃) - 커밋한 메세지 수정하기 (0) | 2023.01.18 |
[GIT 05] unmodified, modified, staged 상태 (0) | 2023.01.18 |
댓글