안녕하세요! 에이블디 입니다!
오늘은 브랜치에 대하여 알아볼까 합니다!
깃, 깃 헙을 들어봤다면 브랜치도 적지 않게 들어보셨을 텐데요!
이번 시간에는 브랜치에 대해 알아보는 시간을 가져보도록 할게요!
서비스를 운영하다 보면 추가 기능을 개발해서 업데이트해야 하는 경우가 생기는데요, 이때 기존 파일에 새로운 기능을 만들어 새 버전을 만들어야 한다면 어떨까요?
새로 개발한 기능이 오류 없이 완벽하게 동작한다는 보장이 있을까요?
완벽하게 동작한다는 보장이 없다면 기존에 코드에 새로운 기능을 추가하기란 여간 쉬운 일이 아닙니다.
기존에 잘 작동되던 기능도 동작하지 않을 수 있거든요.
이럴 때 제대로 동작하는 소스코드는 그대로 둔 채 새 소스코드를 추가한 버전을 따로 만들어 관리하고, 완벽하게 완성한 다음 원래 소스에 더할 수 있다면 너무 좋겠지요?
이걸 해주는 것이 바로 깃의 '브랜치(branch)'라는 기능입니다.
브랜치는 원래 나뭇가지라는 뜻을 가지고 있는데요, 버전 관리 시스템에서는 나무가 가지에서 새 줄기를 뻗듯이 여러 갈래로 퍼지는 데이터 흐름을 가리키는 말로 사용합니다.
깃으로 버전 관리를 시작하면 기본적으로 'master'라는 브랜치가 만들어지게 되는데요, 사용자가 커밋할 때마다 master 브랜치는 최신 커밋을 가리킵니다.
즉, 브랜치는 커밋을 가리키는 포인터와 비슷하다고 생각하면 됩니다.
그럼 새 브랜치를 만들면 어떻게 될까요?
새 브랜치를 만들면 기존에 저장한 파일을 master 브랜치에 그대로 유지하면서 기존 파일 내용을 수정하거나 새로운 기능을 구현할 파일을 추가로 만들 수 있습니다.
이렇게 master 브랜치에서 뻗어 나오는 새 브랜치를 만드는 것을 '분기한다'라고 합니다.
마스터 브랜치에서 새로운 브랜치가 분기되는 과정을 그림으로 살펴볼까요?
그림에서 마스터 브랜치의 M2 커밋에서 M3 커밋 사이에 first 브랜치와 second 브랜치가 생성된 걸 볼 수 있죠?
그리고 first 브랜치의 커밋은 F1과 F2로 second 브랜치의 커밋은 S1으로 따로 커밋이 진행되는 걸 보실 수도 있습니다.
그럼 새 브랜치에서 원하는 작업을 다 끝냈다면 새 브랜치에 있던 파일을 원래 master 브랜치에 합칠 수도 있어야겠죠?
이렇게 분기했던 브랜치를 master 브랜치에 합치는 것을 '머지(merge)' 또는 '병합한다'라고 합니다.
'병합한다'라는 말보다는 '머지한다'라는 말을 더 많이 들어보셨을 텐데요, 이 머지가 되는 과정을 그림으로 살펴보겠습니다!
그림을 보시면 second 브랜치의 S1 버전이 master브랜치의 M3커밋과 M4커밋 사이에 머지가 됩니다.
이렇게 되면 M4에서는 기존의 M3 버전의 파일에 S1에서 수정 및 추가된 기능의 소스코드를 담고 있는 파일들 까지도 같이 가지고 있게 되는 거죠!
M4와 M5 사이에서도 first 브랜치의 F1과 F2까지의 파일이 머지되는 것이 보이시죠? 마찬가지로 M5는 M4 버전의 파일에 first 브랜치에서 F2까지 작업한 내역을 합친 상태입니다.
오늘은 브랜치와 머지에 대해 알아보았습니다!
다음 시간에는 실습을 통해 더욱더 깊이 알아보는 시간을 가져보도록 할게요!
그럼 여러분 다음시간에 만나요!
'git' 카테고리의 다른 글
| #15 깃(Git) - 브랜치 이동하기(git checkout) (2) | 2021.11.19 |
|---|---|
| #14 깃(Git) - 브랜치 만들기 실습 (1) | 2021.11.18 |
| #12 깃(Git) - 커밋 삭제하지 않고 이전 버전으로 되돌리기 (revert) (2) | 2021.11.15 |
| #11 깃(Git) - 커밋을 삭제하고 취소하기 (reset) (2) | 2021.11.12 |
| #10 깃(Git) - 수정한 파일, 스테이징 되돌리기 (restore) (6) | 2021.11.11 |