모든 버전 관리 시스템에는 '브랜치(Branch)'라는 개념이 있습니다.
브랜치는 나뭇가지와도 같은 형태인데요.
버전 관리 시스템에서는 나무가 가지에서 새 줄기를 뻗듯이 여러 갈래로 퍼지는 데이터 흐름을 가르키는 말로 사용합니다.
브랜치가 뭐길래 나뭇가지라는 단어를 사용할까요?
우리가 어떤 제품의 사용 설명서를 만들고 사용 설명서의 버전관리는 깃으로 한다고 가정해보겠습니다.
제품 출시 전에는 A -> B -> C -> D 와같이 개발 순서에 따라 사용 설명서를 작성하면 됩니다.
하지만 출시된 제품에 문제가 생겨 고객사마다 추가로 요구하는 내용이 다르다면 요구사항을 반영하다 고객사마다 제품이 달라지게 되며 이에 맞춰 사용설명서도 달라져야 합니다.
이에 해결방법으로는 처음 작업했던 저장소 전체를 여러개 복사해 각각의 고객사의 이름을 붙여 저장소마다 다른 버전 관리를 하는 것입니다.
저장소 관리는 각각 따로 별개로 하는 방법이죠.
하지만 이 방법은 매우 비효율적입니다.
고객사마다 디렉터리를 복사하면 출시 전까지 만들었던 내용은 동일하기 떄문에 자료가 중복됩니다.
또 버전 관리 시스템의 장점 중 하나는 파일 이름을 더럽히지 않는 것인데, 이 방법은 고객사 마다 디렉터리 이름을 다르게 사용해야 합니다.
마지막으로 google에서 작업을 마친 후 에 그 내용이 apple에서도 필요한 내용이라고 가정할 경우 googlr에 있는 최신 상태의 코드를 복사해서 apple 디렉터리에 붙여 넣은 다음, apple 디렉터리에서 새로운 버전을 커밋하면 될까요?
이러한 경우 문제가 발생할수 있습니다.
'GG' 버전에서 필요한 부분의 코드만 복사해서 붙여 넣으려한다 해도 'GE'와 'GF' 버전을 만들 떄 수정한 다른 내용이 'AE' 버전에는 반영되어 있지 않으므로 오류가 날 수 있습니다.
그렇다고 'GG'버전의 코드 전체를 그대로 덮어 버리면 'D'버전에서 'AE' 버전을 만들면서 수정한 내용이 의도치 않게 바뀌거나 사라질 것입니다.
이러한 문제를 해결할수 있는것이 바로 브런치입니다.
깃으로 버전 관리를 시작하면 기본적으로 master라는 브랜치가 만들어집니다.
사용자가 커밋할 때마다 master 브랜치는 최신 커밋을 가리킵니다.
브랜치는 커밋을 가리키는 포인터와 비슷한 개념이라고 이해하시면 됩니다.
새로운 브런치를 만들기 위해서는 기존에 저장한 파일을 master브랜치에 그대로 유자하면서 기존 파일 내용을 수정하거나 새로운 기능을 구현할 파일을 만들 수 있습니다.
이렇게 master 브랜치에서 뻗어 나오는 새 브랜치를 만드는 것을 '분기(branch)한다'고 합니다.
새 브랜치에서 원하는 작업을 다 끝냈다면 새 브랜치에 있던 파일을 원래 master 브랜치에 합칠수 있습니다.
이렇게 분기했던 브랜치를 master 브랜치에 합치는 것을 '병합(merge)한다'고 합니다.
본 포스팅은 DO it! 지옥에서 온 문서 관리자 깃&깃허브 입문 도서를 참고하며 공부한 내용을 포스팅 하였습니다.
'Git > Github' 카테고리의 다른 글
[Git & GitHub] 브랜치정보확인(새로운 브랜치에서 커밋) (0) | 2022.06.18 |
---|---|
[Git & GitHub] 브랜치(branch) 만들기 (0) | 2022.06.17 |
[Git & GitHub] 작업 되돌리기(checkout, reset) (0) | 2022.06.15 |
[Git & GitHub] 깃허브 방금 커밋한 메세지 수정하기 --amend (0) | 2022.06.14 |
[Git & GitHub] 깃허브 .gitignore 파일로 버전관리 제외하기 (0) | 2022.06.13 |