반응형

 

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

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

 

타임라인

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] 항목을 선택해서 깃허브 데스크탑에서의 브랜치를 완전히 삭제할 수도 있습니다.

아웃트로

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

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

반응형
반응형

 

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

문돌이에서 시작해 어느 새 개발자가 되어버린 베르에 대해서 이야기 해봅시다.

반응형
반응형

 

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

이번에는 깃허브에 리포지토리를 생성하고 프로젝트를 업로드하는 방법을 알아봅시다.

 

타임라인

0:00 인트로

0:37 깃허브 웹에서 리포지토리 생성하고 프로젝트 업로드하기

4:04 깃허브 웹에서 리포지토리 생성하고 프로젝트 업로드했을 때 주의점

4:53 깃허브 데스크탑 앱에서 리포지토리 생성하고 프로젝트 업로드하기

6:09 아웃트로

반응형
반응형

 

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

디버그에 대해서 이런 저런 이야기를 해본 스트리밍의 편집본입니다!

 

타임라인

0:00 인트로

1:25 디버그란?

2:23 버그의 유래

5:02 프로그래머의 숙명

5:56 버그를 줄이고 버그를 빨리 찾기 위해서는?

7:42 버그가 발생할 확률을 줄이는 법 1

13:54 버그가 발생할 확률을 줄이는 법 2

16:49 버그가 발생할 확률을 줄이는 법 3

20:17 초보자때 할 수 있는 실수

22:17 버그 리포트

24:38 불필요한 경고문 없애기

26:18 빌드 테스트

28:55 유니티에서 문제 해결하는 법

31:23 베르의 게임 개발 유튜브 멤버십 개발단!

32:14 아웃트로

반응형
반응형

 

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

2021년 1월 24일 일요일에 진행한 프로그래밍 & 개발 입문자들이 느끼는 어려움에 대해 이야기하는 스트리밍을 편집한 두 번째 편입니다!

 

타임라인

0:00 QnA2 - 게임 서버는 어떻게 공부했나?

2:20 포트폴리오에 대한 이야기

4:39 개발자의 수준을 결정하는 것들

6:55 QnA3 - 인디 개발자 이야기

7:55 QnA4 - 게임 개발에 필요한 수학 지식?

9:06 QnA5 - 게임 기획?

10:55 QnA6 - 베르가 생각하는 유니티와 언리얼

12:54 QnA7 - 게임 엔진 개발 공부?

14:24 공부할게 너무 많다

15:54 아웃트로

반응형
반응형

 

프로그래밍이나 개발에 처음 입문하는 분들이 느끼는 어려움에 대해서 이야기해봅시다!

 

타임라인

0:00 인트로

0:27 입문자들이 느끼는 어려움 - 머리로 생각한 로직을 코드로 옮기기

2:41 그 해결책?

4:02 베르의 사례

7:10 어려움의 단계를 넘기기 어려운 타입들

16:11 QnA1 - 코드를 짜다가 막혔는데 검색해도 안나올때 or 문서에 함수 이름만 있고 사용법이 잘 안나올 때

20:02 게임 개발 공부 커리큘럼?

23:02 게임 개발 공부할 때 100% 필수인 과목

24:25 게임 개발자의 길

반응형
반응형

 

2021/01/09에 스트리밍으로 진행했던 게임 서버 & 네크워크 개론 편집본입니다!

급하게 기획해서 진행한 스트리밍 강좌라 그런지 아쉬운 점이 많네요. 다음엔 좀 더 잘 준비해서 해보겠습니다. 그리고 아쉬운 소식으로는 지난 1년간 저와 함께 열심히 90여편의 영상을 제작해왔던 마이크가 수명이 다해간다는 겁니다. 그래서 강좌 중간에 사운드가 나간 부분이 많아서 다시 녹음해서 올린 부분이 조금 있습니다. 거기에 무려 한 시간 짜리 영상이라 자막은 언제 제작할 수 있을지 눈 앞이 깜깜하네요 ㅜㅜ

 

타임라인

0:00 인트로

1:00 게임 서버 방식 1 - P2P

3:23 게임 서버 방식 2 - Host

6:31 게임 서버 방식 3 - 데디케이트 서버

8:04 데디케이트 서버를 잘못 만들면?

11:23 장르별 게임 동기화 수준

12:22 FPS/레이싱

13:40 턴제 전략/TCG

13:57 RTS

19:50 게임 네트워크 구조의 변화

27:24 서버 구축 방식의 발전

27:31 전통적인 서버 구축

34:08 IaaS(Infrastructure as a Service)

35:20 Paas(Platform as a Service)

38:31 서버리스 아키텍처

40:30 BaaS(Backend as a Service)

42:33 GBaaS(Game Backend as a Service)

43:44 게임 서버의 궁극! 클라우드 게임

50:06 아웃트로

반응형
반응형

위데브 유튜브 채널 개설!


여러분들과 함께 2-3년간 블로그를 통해서 유니티나 언리얼 엔진 등으로 게임 개발하는 방법을 공부하고 기능들을 소개해온 베르입니다.


이 블로그를 처음 개설한 이유는 인터넷에서 개발과 관련된 자료를 찾아서 공부하고, 나중에 다시 그 자료를 찾으려고 했을 때, 없어진 자료들이 너무나 많아서 느낀 답답함과, 자료를 공유해주신 고마운 분들이지만, 너무 본인 위주의 간략한 설명으로 자료를 따라서 공부하기 어려운 점을 누가 보아도 쉽게 이해할 수 있게 글을 써보자는 욕심이었습니다.


의도한 대로 잘되어 왔는지는 아직 확신할 수는 없지만, 많은 분들이 찾아주신 결과로 현재까지 약 40만여 회의 방문수를 기록하고 있습니다.


하지만, 아직도 아쉬운 점은 게임 개발은 변화가 많고 움직임이 많은 것이기 때문에 순수한 글로써는 제가 의도한 바를 100% 전달하고 있는지 확신할 수 없었습니다. 그래서 처음에는 글에 이미지를 넣고, 이미지에 빨간 박스나 화살표로 강조하는 등의 표시를 해왔고, 개발된 결과로 움직이는 것을 보여드리기 위해서 gif로 찍어서 올리기까지 했습니다.


그렇게까지 해왔지만, 아직은 모자란 점이 많다고 생각하여, 백 번 듣는 것보다는 한 번 보는 것이 났다는 옛 말에 따라 좀 더 확실하게 보여드리고 알려드리기 위해 유튜브 채널을 개설하게 되었습니다.


지난 한 달간 최소한의 콘텐츠를 만들기 위해서 열심히 새로운 영상을 만들고 쌓아온 끝에 드디어 오픈하게 되었습니다.


아직은 기초적인 내용의 영상 밖에 없지만, 지금 블로그에 적힌 다른 포스트 역시 차근차근 영상화해서 찾아뵙겠습니다.


그리고 이 블로그 역시 차근차근 글로 보고 배우는 과정을 따라오시기를 위한 분들을 위해서 업데이트를 계속해서 이어나갈 예정입니다.


위데브 채널 방문하기


위데브 채널에 방문해주셔서 필요한 영상을 시청하시고 좋아요와 구독/알림설정으로 앞으로도 양질의 글과 영상으로 찾아뵐 수 있도록 응원해주세요.


그 동안 이 모자란 블로그에 방문해주시고 사랑해주신 분들께 감사합니다. 그리고 앞으로도 잘 부탁드리겠습니다.



반응형

+ Recent posts