팀프로젝트 가이드

깃허브를 통한 팀프로젝트에서 작업 흐름과 방법을 소개하는 글입니다.

깃허브 사용하기

리포지토리 로컬로 가져오기

보내드린 초대를 수락하면 깃허브에 팀프로젝트 리포지토리의 접근이 허가됩니다. 리포지토리 홈 화면에서는 다양한 기능들을 사용할 수 있습니다.

초록색 Code 버튼을 클릭한 후 Open with GitHub Desktop 버튼을 클릭해 깃허브 데스크탑 앱을 통해 리포지토리를 로컬로 가져올 수 있습니다.

단, 현재 브랜치가 main으로 설정되어 있는 경우
설정된 브랜치 보호 규칙에 의해 커밋이나 푸쉬를 할 수 없습니다.
반드시 개인 브랜치를 생성한 후에 로컬로 클로닝해주세요.

브랜치 생성하기

브랜치란 여러명의 개발자들이 동일한 소스코드 내에서 동시에 다른 작업들을 진행하기 위해 각자의 독립적인 작업영역을 분리하는 기능입니다.

리포지토리 홈 화면에서 ‘branch’ 버튼을 클릭한 후, 다음 화면에서 우측 ‘new branch’를 클릭해서 자신의 이름 알파벳 이니셜로 브랜치를 생성해줍니다.

저희는 3명이니 브랜치의 갯수는 main 브랜치를 포함해 총 4개입니다.
main 브랜치는 모든 소스코드를 총괄하며, 프로젝트 내에서 서브 프로젝트가 진행 될 때 원본이 되는 소스코드를 가진 브랜치입니다. 따라서 main 브랜치에서는 작업을 진행하지 않고 본인 이름의 알파벳 브랜치를 생성한 뒤 해당 브랜치에서 작업을 진행하시면 되겠습니다.

커밋, 푸쉬, 언두, 리버트 (Commit, Push, UnDo, Revert)

DirectX를 배우면서 VS 또는 PS 단계로 ConstantBuffer를 보내는 방법에 대해 학습한 적이 있습니다. 이 때 ConstantBuffer에 데이터를 입력하는 것이 커밋이고 해당 버퍼를 VS나 PS에서 SetConstantBuffers()로 보내는 것이 푸쉬입니다.

커밋 : 버스(버퍼)에 학생(데이터)를 태우는 행위
푸쉬 : 버스를 학교(리포지토리)로 출발시키는 행위

작업을 진행한 뒤 제목을 추가한 뒤 버튼을 눌러 커밋을 진행할 수 있습니다. 설명은 선택사항입니다. 또한 깃허브 데스크탑을 이용한다면 개방형 포맷의 경우 앱의 우측 프리뷰 패널에서 변경된 내용을 확인할 수 있습니다.

커밋 시 제목을 작성할 때는 해당 커밋의 내용을 빠르게 파악할 수 있도록 접두에 키워드를 이용하는데 추천하는 키워드는 다음과 같습니다.

Create : 파일 또는 기능의 생성시
Update : 파일 또는 기능의 변경시
Delete : 파일 또는 기능의 삭제시

특정 파일이 생성되었을 시 : Update Test.txt
	// 단일 파일의 생성, 변경, 삭제의 경우
	// 깃허브 데스크탑에서 자동으로 제목을 생성해줍니다.
특정 기능이 생성되었을 시 : Create CharacterMovement

커밋 후에 내용을 변경하고 싶다면 커밋 버튼 밑에 생성되는 Undo 버튼을 클릭해서 커밋을 되돌릴 수 있습니다.

커밋이 문제가 없다고 판단될 시 우상단 푸쉬 버튼을 클릭해 푸쉬를 진행하면 되겠습니다.

푸쉬 후 코드의 결함이 발생하여 되돌려야 할 경우가 있습니다. 그 경우에 해당하는 행위를 리버트라고 합니다. 히스토리 탭을 누른 후 되돌아가고 싶은 푸쉬를 우클릭 후 revert changes in commit 버튼을 클릭합니다.

리버트 버튼을 클릭하게 되면 리포지토리의 내용을 리버트 한다는 내용의 커밋이 생성됩니다. 푸쉬버튼을 클릭해 해당 내용을 보내주게 되면 되돌아오는데 성공하게 됩니다.

이 때 주의사항으로 리버트를 하기 위해선 현재 로컬에 변경사항이 없어야 합니다. revert changes in commit 버튼을 클릭하게 되면 로컬에는 해당 사항이 바로 적용되기 때문인 것으로 추측됩니다.

풀 리퀘스트 (Pull Request)

두 분은 현재 브랜치를 생성했고 main 브랜치로부터 코드를 가져와서 캐릭터이동, 공격 등의 기능을 만들었다고 가정합니다. 이제 해당 기능들을 다시 main 브랜치로 올려보내서 프로젝트의 진행률를 올리고자 합니다.

위처럼 두 브랜치의 내용을 합치는 행위를 병합(merge)이라고 하는데 동시다발적인 병합이 일어난다면 예기치 못한 코드충돌, 혹은 현재로선 알 수 없는 여러 문제점들이 일어날 가능성이 있기 때문에 이를 방지하기 위해 병합을 하기 전 코드를 리뷰하고 충돌을 줄이려고 합니다.

풀 리퀘스트란?
- 병합에 대한 요청을 제출하는 행위
- 줄여서 `PR` 이라고 합니다.

주 목적은 main 브랜치에서의 문제발생 예방이지만 직접 작성한 코드가 아니라도 코드리뷰를 통해 해당 코드의 경험치를 획득해 갈 수 있기 때문에 PR을 사용하도록 하겠습니다.

PR은 리포지토리의 PR 탭에서 요청을 작성할 수 있습니다. 깃허브 데스크탑의 PR 버튼을 누르면 PR 탭으로 바로 들어올 수 있습니다.

PR을 작성할 때는 아래의 항목들을 설정해줘야 합니다.
base branch : 병합을 받을 브랜치, 거의 대부분 main
compare branch : 병합을 할 브랜치, 제 경우 거의 대부분 KJH
Title : 병합에 대한 제목
Write : 간단한 설명
필요한 내용들을 기입한 뒤 Create pull request 버튼을 눌러 요청을 생성합니다. 요청을 생성하기 전 현재 코드가 가진 문제나 발생할 수 있는 문제가 있다면 상세하게 기술해주시고 같이 해결해보도록 합시다.

프로세스 플로우차트

다음의 그림과 같이 프로젝트의 진행에 대한 흐름을 알려드리고 싶어서 이 프로젝트가 진행되는 동안에 필요한 기술들에 대해서 위에서 설명해 드렸습니다. 깃허브가 백업의 기능도 있지만 가장 핵심적인 기능을 고르라 하면 효율적인 협업 프로세스가 메인이라고 생각합니다. 나중에 회사에 가도 회사 자체적인 깃허브 형태의 형상 관리 툴을 사용하고 있거나 깃허브를 사용하고 있을 수도 있으니까 깃허브에 대해서 부족한 부분은 좀 더 알아보시면 좋을것 같습니다.

칸반보드란

애자일 방식에서 사용되는 툴로 일반적으로 3개의 영역(Todo, InProgress, Done)을 나눠서 일을 단위로 나누어 일의 처리상황을 볼 수 있게 만든 보드입니다.

이 화면을 앞으로 보드라고 부르도록 하겠습니다. 보드에는 4개의 필드가 있고 Backlog 필드에는 2개의 아이템이 들어가 있습니다. 앞으로 아이템을 태스크라고도 부르도록 하겠습니다.

어떻게 쓰나요?

Todo 필드에 있는 태스크 중 마음에 드는 아이템을 In Progress로 옮긴다.
In Progress로 옮긴 아이템을 열어서 Written을 옮긴 날짜로 변경한다.
아이템에 작업시작 댓글을 남겨서 담당자임을 기록한다.
태스크를 완료한 뒤 PR을 하고 PR이 통과하면 아이템을 열어 Deadline을 PR이 통과한 날짜로 변경한다.
아이템을 Done으로 옮기고 1번부터 다시 시작한다.

필드

- Todo

아직 담당이 정해지지 않은 미처리 태스크들이 올라오는 필드입니다. 첫 미팅에서 예상되는 태스크를 조사하기로 했고 조사된 내용을 토대로 작업 태스크들이 생성되어 Todo에 올라올 것입니다. 그렇게 태스크가 올라오면 그 중 하고싶은 태스크를 골라서 In Progress로 이동한 뒤 작업을 진행하면 되겠습니다.

- In Progress

현재 담당자가 작업중인 태스크들이 있는 필드입니다. Todo에서 가져온 뒤 아이템을 열어보면 Comment 버튼이 보이고 댓글을 남길 수 있는데 작업 시작이라고 코멘트를 남겨서 현재 작업중인 담당자임을 기록해주시면 되겠습니다. 처음으로 달리는 코멘트는 작업 시작을 알리는 코멘트를 남겨주시면 되고 이후에 태스크 진행하면서 혼자서 해결하기 어려운 문제를 적어둔다던지 공유해서 다같이 해결하는 등 메모, 공유 등의 다양한 용도로 적극 활용하시면 좋을 것 같습니다.

- Done

작업이 완료된 태스크들을 모아두는 필드입니다. 여기서 작업이 완료된 상태란, PR한 뒤 머지가 이루어진 상태를 말합니다.

- Backlog

작업 간에 필요한 내용을 아이템 형태로 모아둔 필드입니다. 원래 백로그가 이렇게 사용하는 명칭은 아닌 것으로 알고있는데 저희는 작업을 위한 라이브러리 정도로 생각하시면 될 것 같습니다.

아이템

아이템을 누르면 다음과 같이 해당 아이템에 대한 상세한 내용을 확인할 수 있습니다.

제목과 내용은 이미 작성되어서 올라오기 때문에 특별한 경우가 아니면 수정할 일은 없습니다. 유일하게 조정해줘야 할 것은 우측에 보이는 아이템에 대한 필드 속성들 중 Written과 Deadline 입니다.

Written : 해당 태스크를 In Progress로 옮긴 날을 지정해줍니다.
Deadline : 해당 태스크가 PR후 머지까지 완료된 날을 지정해줍니다.

이 두가지만 잘 작성해주시면 되겠습니다.