[깃허브] 브랜치

 

안녕하세요! 여러분들과 함께 게임 개발을 공부하는 베르입니다!

이번 강좌에서는 깃허브에서 브랜치를 다루는 방법을 알아봅시다!

 

타임라인

0:00 인트로

0:09 브랜치

1:48 메인 브랜치

2:12 브랜치 나누기

4:04 깃허브 웹페이지에서의 브랜치 작업

6:15 깃허브 데스크탑에서의 브랜치 작업

8:04 아웃트로

스크립트

인트로

안녕하세요. 여러분들과 함께 게임 개발을 공부하는 베르입니다.

이번에는 깃허브에서 브랜치를 다루는 방법에 대해서 알아보도록 하겠습니다.

브랜치

깃허브에서 브랜치를 다루기 전에 브랜치라는 단어에 대해서 이야기해보겠습니다.

브랜치라는 단어는 영어 단어로 분기 혹은 가지라는 뜻을 가지고 있습니다.

쉽게 생각하면 여러 개의 가지로 나누어지는 나무를 생각할 수 있습니다.

지난 깃허브 영상에서는 리포지토리를 만드는 방법과 커밋, 푸시, 풀 등의 기본적인 깃 동작들을 알아보았는데 이 모든 작업은 깃에서 가장 기본이 되고 중심이 되는 가지인 메인 브랜치 위에서 이루어진 것입니다.

여기서 이 브랜치라는 단어의 뜻을 생각하면 이후의 작업에서는 경우에 따라서 이 브랜치가 마치 나뭇가지처럼 여러 갈래로 갈라질 수 있음을 추측할 수 있습니다.

그럼 이 브랜치라고 부르는 개발의 나뭇가지는 왜 필요한 것일까요?

사실 혼자서하는 간단한 개인 작업이나 연습 프로젝트를 위한 리포지토리라면 메인 브랜치 위에서만 작업해도 충분합니다.

하지만 적어도 출시를 하기 위한 1인 프로젝트나 여러 개발자들과 함께 하는 프로젝트에서는 메인 브랜치에서 모두 작업하는 일은 바람직하지 못합니다.

먼저 출시를 위한 1인 프로젝트의 경우를 보면 어떤 기능을 추가하거나 버그를 수정하기 위해서 코드를 작성하거나 수정하는 일이 곧바로 출시되서 앱스토어에 올라가는 버전에 반영이 되게 됩니다.

물론 깃허브에는 잘못된 작업이나 만들었지만 마음에 들지 않는 기능을 다시 되돌리기 위한 히스토리 기능이 있지만 여전히 가장 중심이 되는 메인 브랜치에 영향을 끼친다는 점이 꺼림칙하게 느껴질 수 밖에 없습니다.

그리고 여러 개발자가 함께 협업하는 경우 역시 모든 개발자가 메인 브랜치에서 동시에 작업을 한다면 내가 작업 중인 파트를 누군가 건드려서 훼손하거나 동시에 여러 종류의 커밋이 한 브랜치의 히스토리에 뒤섞여서 문제가 발생했을때 이것을 되돌리기 어려워지게 됩니다.

이러한 여러 가지 문제를 해결하기 위한 도구가 바로 브랜치입니다.

메인 브랜치

앞에서도 말했다시피 리포지토리를 만들었을 때 가장 기본적으로 만들어지는 브랜치는 메인 브랜치입니다.

이 메인 브랜치는 보통 언제든지 배포 혹은 빌드되어 출시 가능한 버전의 코드만이 올라와 있어야 합니다.

그렇기 때문에 이 메인 브랜치를 대상으로 커밋이나 풀, 푸시 같은 작업을 하는 일은 리포지토리를 생성해서 프로젝트를 세팅하기 위한 초기가 아니면 발생하지 않도록 주의해야 합니다.

브랜치 나누기

그러므로 메인 브랜치는 놔둔채로 최신 버전의 메인 브랜치에서 새로운 브랜치를 따서 해당 브랜치에서 작업을 한 뒤에 모든 작업이 끝나고 검증이 완료되면 메인 브랜치로 합치는 방식으로 작업이 진행되어야 합니다.

그럼 이 브랜치를 나누는 기준은 어떻게 될까요?

물론 브랜치를 나누는 기준은 개발자마다, 팀마다, 프로젝트마다, 회사마다 다 다를 수 있습니다.

여기서는 브랜치 나누는 아주 간단한 방식을 한 가지만 이야기 해보겠습니다.

그 방법은 브랜치를 메인 브랜치, 디벨롭 브랜치로 나누는 것입니다.

앞에서도 이야기 했다시피 메인 브랜치는 출시나 배포를 위해 두고 완전히 검증된 코드만 올라오도록 유지합니다.

그리고 디벨롭 브랜치에서는 실제 개발 작업이 이루어지며 이 버전의 브랜치에서 빌드된 프로그램은 내부 테스트를 통해 검증하게 되고 검증이 완료된 코드를 메인 브랜치로 보내서 출시와 배포가 이루어지는 방식입니다.

이렇게 브랜치를 이원화시키고 검증된 작업만 메인 브랜치로 적용함으로써 버그를 최소화할 수 있게되는 겁니다.

물론 이 디벨롭 브랜치에서도 모든 개발자들이 한 브랜치에서 작업하는게 아니라 각자의 기준에 따라서 브랜치를 따게 됩니다.

그 기준은 작업자 별로 따로 브랜치를 딸 수도 있고, 만들어야 하는 기능이나 고쳐야하는 버그 별로 브랜치를 딸 수도 있습니다.

보통 기능이나 고쳐야하는 버그 같은 작업 단위로 따는 브랜치를 토픽 브랜치라고 부릅니다.

일반적으로는 두 방식을 섞어서 디벨롭 브랜치에서 기능이나 수정할 버그 별로 토픽 브랜치를 따고 그 토픽 브랜치에 여러 개발자가 붙으면 또 거기서 각 개발자별 브랜치를 따는 방식으로 진행됩니다.

물론 여러 개발자가 한 토픽에서 작업할 수도 있지만, 작업하다가 서로 같은 부분을 수정해서 합칠 때 발생하는 충돌이 없도록 작업을 섬세하게 분배할 필요가 있습니다.

서비스가 유지되는 동안에는 계속 유지하게 되는 메인 브랜치나 디벨롭 브랜치와는 다르게 이런 토픽 브랜치는 해당 기능이 완성되거나 버그가 해결되서 디벨롭 브랜치에 합쳐지는 순간 브랜치를 삭제하게 됩니다.

깃허브 웹 페이지에서의 브랜치 작업

그럼 이제 깃허브에서 브랜치를 생성하는 방법을 알아보겠습니다.

먼저 깃허브 웹페이지에서 브랜치를 만들고자하는 리포지토리를 선택합니다.

그러면 파일과 폴더 목록 위에 main이라고 써진 드롭다운 버튼이 보입니다.

이것은 지금 선택된 브랜치가 리포지토리의 가장 기본 브랜치인 main 브랜치로 선택되어 있다는 뜻입니다.

그리고 그 옆에 있는 1branch라는 버튼을 누르면 이 리포지토리에 있는 모든 브랜치 목록을 볼 수 있습니다.

앞 페이지로 돌아가서 main 브랜치 드롭다운을 클릭하고 입력창에 현재 브랜치 목록에 없는 이름을 입력하면 새로운 브랜치를 생성할 수 있습니다.

이렇게 다른 브랜치인 상태에 파일을 하나 열고 내용을 수정해보겠습니다.

새로운 브랜치에서 이렇게 작업을 진행하고 다시 원래의 main 브랜치로 돌아가보면 두 브랜치의 파일 작업 상태가 서로 다른 것을 볼 수 있습니다.

그리고 이 새로 만든 브랜치에서의 작업이 끝나면 이렇게 작업한 내용은 메인 브랜치로 합쳐야 하는데 그 작업을 머지라고 부르고 이 머지 작업을 요청하는 것을 풀 리퀘스트라고 부릅니다.

풀 리퀘스트를 생성하기 위해서는 페이지 상단 탭에서 Pull request를 클릭하고 뜨는 풀 리퀘스트 페이지에서 New pull request 버튼을 클릭하면 됩니다.

그리고 compare에는 작업한 브랜치를 선택하고 base에는 작업한 브랜치를 합칠 브랜치를 선택합니다.

그러면 새 브랜치에서 작업한 내용과 원본 브랜치의 내용을 비교할 수 있게 됩니다.

변경사항을 비교한 다음 Create pull request 버튼을 누른 뒤에 생성할 풀 리퀘스트의 타이틀과 코멘트를 통해 어떤 작업을 진행했는지 작성하고 한 번 더 Create pull request 버튼을 눌러주면 풀 리퀘스트가 생성 됩니다.

이렇게 풀 리퀘스트를 생성하고 나면 리포지토리의 Pull request 목록에 생성된 풀 리퀘스트를 볼 수 있습니다.

이렇게 만들어진 풀 리퀘스트에 개발 팀원들은 이 작업에 대해서 코멘트를 남길 수 있고 관리자는 풀 리퀘스트를 검토한 후 풀 리퀘스트를 브랜치에 머지하거나 Close pull request로 풀 리퀘스트를 거절할 수도 있습니다.

그리고 Merge request 버튼을 누르면 풀 리퀘스트의 작업 내용을 합칠 수 있게 됩니다.

이렇게 원래의 브랜치로 머지를 끝낸 브랜치는 Delete branch로 닫을 수 있습니다.

깃허브 데스크탑에서의 브랜치 작업

그럼 이번에는 깃허브 데스크탑에서 브랜치 작업을 해보겠습니다.

깃허브 데스크탑에서 작업할 리포지토리를 선택하고 나면 Current repository 옆에 Current branch 가 main으로 되어있음을 볼 수 있습니다.

여기서도 웹 페이지에서처럼 새로 만들 브랜치의 이름을 적고 Create new branch를 해주면 됩니다.

하지만 깃허브 데스크탑에서 브랜치를 만들어도 웹 페이지에서는 바로 보이지 않을텐데, 깃허브 데스크탑에서 방금 만든 브랜치는 로컬에만 존재하는 상태이기 때문입니다.

웹 페이지에서도 보이고 다른 작업자들에게 내 브랜치를 보이게 만들기 위해서는 Publish branch를 해줘야 합니다.

Publish branch를 하고 나면 웹 페이지에서도 추가된 브랜치를 볼 수 있게 됩니다.

그 다음에 새로 만든 브랜치에서 작업한 뒤에 커밋하고 푸시하면 웹 페이지에서 변경된 점을 볼 수 있습니다.

그리고 깃허브 데스크탑에서도 브랜치를 오가면 작업이 분리되는 모습을 볼 수 있습니다.

역시 깃허브 데스크탑에서도 작업이 끝나면 작업 내용을 원래 브랜치로 합치는 풀 리퀘스트를 해야합니다.

Create pull request 버튼을 누르면 웹 페이지가 열리면서 풀 리퀘스트를 생성할 수 있습니다.

이후의 과정은 웹 페이지에서의 과정과 같이 브랜치의 작업 내용을 정리해서 풀 리퀘스트를 하고 머지를 진행하면 됩니다.

다만, 웹 페이지에서 풀 리퀘스트를 머지하고 브랜치를 삭제하더라도 깃허브 데스크탑에서는 브랜치가 그대로 존재합니다.

이 브랜치를 다시 퍼블리시해서 사용할 수도 있지만 상단 메뉴 바에서 [Branch > Delete] 항목을 선택해서 깃허브 데스크탑에서의 브랜치를 완전히 삭제할 수도 있습니다.

아웃트로

이번 영상에서는 깃허브에서 작업 내용이 섞이지 않게 하기 위해서 브랜치를 이용해서 작업하는 방법을 알아보았습니다.

이상 베르의 게임 개발 유튜브였습니다. 감사합니다.

 

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

에셋스토어

Easy 2D, 3D, VR, & AR software for cross-platform development of games and mobile apps. - Unity Store

Create 2D & 3D Experiences With Unity's Game Engine | Unity Pro - Unity Store

[투네이션]

-

[Patreon]

WER's GAME DEVELOP CHANNEL님이 Game making class videos 창작 중 | Patreon

[디스코드 채널]

Join the 베르의 게임 개발 채널 Discord Server!