깃(Git) - 브랜치

브랜치 = 분기

• 독립적으로 어떤 작업을 진행하기 위한 개념, 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있음

 

브랜치가 필요한 이유?

•  예를 들어 우리가 어떤 제품의 사용 설명서를 만들고 버전 관리는 깃으로 한다고 상상
  제품이 출시되기 전에는 다음 그림처럼 개발 순서에 따라 사용 설명서를 작성
  하지만 제품이 출시되고 나면 문제가 생기는데 고객사마다 추가로 요구하는 내용이 달라질 수 있기 때문
• 이렇게 고객사의 요구 사항을 반영하다 보면 제품이 달라질 것이고, 그에 따라 사용 설명서도 달라져야 함

• 먼저 떠오르는 해결책은 처음에 작업했던 저장소(다음 그림에서 main) 전체를 여러 개 복사해서
  고객사(다음 그림에서 apple, google, ms)마다 이름을 붙인 후 저장소마다 버전 관리를 따로 하는 방법임
• 하지만 이 방법은 비효율적인데 먼저 고객사마다 디렉터리를 복사하면
  출시 전까지 만들었던 내용은 동일하기 때문에 자료가 중복됨
• 버전 관리 시스템의 장점은 파일 이름을 더럽히지 않는 것인데, 이 방법은 고객사마다 디렉터리 이름을 다르게 사용해야 함

• google에서 작업을 마쳤는데 나중에 apple에서도 필요한 내용이라고 가정하면
  google에 있는 최신 상태의 코드를 복사해서 apple 디렉터리에 붙여 넣은 다음, 
  apple 디렉터리에서 새로운 버전을 커밋하면 문제가 생길 수 있음
• GG 버전에서 필요한 부분의 코드만 복사해서 붙여 넣으려 해도 GE와 GF 버전의 내용이 AE 버전에는 반영되어 있지 않으
  므로 오류가 날 수 있으며 그렇다고 GG 버전의 코드 전체를 그대로 덮어 버리면 apple의 D 버전에서 AE 버전을 만들면서 수정한 내용이 의도치 않게 바뀌거나 사라짐
• 이런 지옥에서 우리를 구원해 주는 도구가 바로 브랜치임

 

master 브랜치? main 브랜치

• 깃으로 버전 관리를 시작하면 기본적으로 main이라는 브랜치가 만들어짐
• 옛 버전의 깃을 사용하고 있거나, 최신 깃을 설치했더라도 메인 브랜치를 main으로 지정하지 않았다면
  master 브랜치로 나타날 수도 있음
• main 브랜치와 master 브랜치는 이름만 서로 다를 뿐, 깃을 사용할 때 기본이 되는 브랜치라는 개념은 같음
• master라는 이름이 master(주인)-slave(종)라는 노예 제도를 연상시키고 인종을 차별하는 느낌을 주기 때문에 main으로 바뀌었음
• 이미 깃을 사용해 왔다면 브랜치 이름은 master로 되어 있을 것이고 main 브랜치와 master 브랜치가 뒤섞여 헷갈릴 수도 있음
• 예전 작업은 master 브랜치를 사용하고 최근 작업은 main 브랜치를 사용하겠지만 시간이 흐르면 main 브랜치가 자연스러워질 것

 

 

브랜치 기능

• 깃으로 버전 관리를 시작하면 기본적으로 main 브랜치가 만들어짐
• 사용자가 커밋할 때마다 main 브랜치는 어떤 게 최신 커밋인지 정보를 가짐
• 즉, 브랜치는 커밋을 가리키는 포인터와 비슷하다고 생각하면 됨
• 기존 파일은 main 브랜치에 그대로 유지하면서, 새 브랜치에서 기존 파일 내용을 수정하거나 새로운 기능을 추가할 수 있음
• 이렇게 main 브랜치에서 새 브랜치를 만드는 것을 ‘분기(branch)한다’라고 함

•  브랜치에서 원하는 작업을 다 끝냈다면 새 브랜치에 있던 파일을 원래 main 브랜치에 합칠 수 있음
  이렇게 분기했던 브랜치를 main 브랜치에 합치는 것을 ‘병합(merge)한다’고 함
• 즉, 기본 파일은 main 브랜치에 그대로 둔 상태에서 새로운 브랜치를 분기한 후
  수정이나 추가 작업을 하고 별 문제없이 완성되었다면, 새 브랜치의 내용을 main 브랜치와 병합하는 것