맨땅에서 시작하는 협업을 위한Github 사용법

13 min readApr 25, 2021

많은 기업들이 채용 과정에서 개발자의 협업 능력을 중요하게 보고 있습니다. 이런 상황 속에서 혼자서만 개발을 해왔던 초보 개발자인 제가 팀 프로젝트를 하면서 공부한 Github 사용법 및 설정 방법을 공유하고자 합니다.

Github란 무엇인가?

깃허브는 Git을 기반으로 소스 코드를 호스팅하고 협업 지원 기능들을 제공하는 웹서비스입니다.

Git을 사용하기 때문에 소스 코드를 버전 별로 관리할 수 있고 개발 프로젝트를 위한 다양한 편의 기능도 제공하고 있습니다.

(Git에 대해 더 자세히 알고 싶다면 Git Book을 참고해주세요)

Github로 여러명이 함께 개발하는 프로젝트 관리하기

Github로 협업하기 위한 과정을 간략히 소개하자면 아래와 같습니다.

Repository 생성
공동 작업자(팀원) 초대
Projects 기능을 이용한 칸반 보드 설정
이슈 라벨 및 템플릿 설정
Pull request 템플릿 설정
브랜칭 전략 설정
커밋 메시지 작성 규칙 설정
코드 리뷰

각 과정을 차례대로 설명하도록 하겠습니다.

1. Repository 생성

깃허브에서는 프로젝트를 Repository(저장소) 단위로 관리하게 됩니다. 우선 깃허브 사이트로 들어가줍니다. Repositories 우측 New 버튼을 누르거나 헤더의 + 버튼을 누르면 나오는 New repository 를 클릭하면 Repository 생성 화면으로 넘어가게 됩니다.

Repository 생성 화면으로 오시면 Repository 이름과 설명, Repository 공개 유무와 같은 초기 설정을 하시고 하단의 Create repository 버튼을 누르시면 생성이 완료됩니다.

아래와 같이 Repository가 생성이 되면, 이제 여기에서 Git을 사용해 저희의 소스 코드를 저장하고 공유할 수 있게 됩니다. 참고로 녹색 Code 버튼을 눌러서 Repository를 clone 하시면 로컬 환경에서 개발을 시작하실 수 있습니다. (clone을 하는 자세한 방법은 여기에서 다루지 않도록 하겠습니다)

2. 공동 작업자(팀원) 초대

처음 Repository를 생성한 상태에서는 이를 생성한 사람만 자유롭게 소스 코드를 올리고 프로젝트를 관리할 수 있습니다. 자신을 제외한 다른 사람들은 간접적으로 Repository를 이용해야 합니다. 이에 대해서는 Github Contributor로 검색하시면 더 자세한 정보를 얻으실 수 있습니다.

아무튼 하나의 프로젝트를 함께 집중적으로 개발할 동료들이라면 간접적으로 공헌하는 방식이 아닌 저처럼 자유롭게 많은 권한을 가지고 Repository를 관리할 수 있으면 좋겠죠? 이를 위해서는 동료들을 Collaborator(공동 작업자)로 초대해야 합니다. 자, 우선 메뉴의 Settings로 들어갑니다.

Collaborator를 초대하기 위해 Manage access 탭으로 이동한 뒤 Invite a collaborator 버튼을 눌러 원하는 유저(팀원)를 초대하시면 됩니다.

유저를 초대하게 되면 Pending Invite 상태가 되고 초대받은 유저는 이메일을 확인해보시면 초대 메일이 온 것을 확인하실 수 있습니다. 이렇게 받은 메일을 통해 초대를 수락하게 되면 Collaborator로 등록이 완료됩니다.

추가로, Collaborator로 등록된 유저에 대해서 Role을 설정할 수 있는데 부여된 Role에 따라 Repository에 대한 권한이 달라지니 참고하시길 바랍니다.

3. Projects 기능을 이용한 칸반 보드 설정

Github에서 제공하는 Projects 기능을 사용하면 칸반 방식으로 프로젝트를 관리하실 수 있습니다. 칸반이 무엇인지 모르신다구요? 이에 대해서는 함께 칸반 보드란 것을 만들어보면서 알려드리도록 하겠습니다. 우선 Github 메뉴 중 Projects로 이동합니다.

상단의 Create a project 를 누르시면 칸반 보드를 생성하는 화면으로 이동하게 됩니다. 각 입력칸을 채워주시면 되는데 이때, Project template는 꼭 None으로 설정해주세요. Github에서는 기본적인 설정이 되어 있는 template을 제공하고 있습니다. 하지만 이번에는 이를 사용하지 않고 직접 설정해보면서 만들어보기 위해 template 항목을 None으로 하겠습니다.

(이후에 익숙해지시면 기본 template을 사용하셔도 무방합니다)

이제 보드를 만들었으니 칸반 보드를 구성할 열들을 만들어 주겠습니다. 생성할 때 Automation 설정을 하게 되면 설정 값에 따라 이슈나 풀 리퀘스트가 자동으로 해당 열에 속하게 됩니다. 이 설정 값은 열 하단에 위치한 Manage로 수정할 수 있으니 참고하시면 됩니다.

다 생성하셨나요? 이제 이것을 어떻게 활용하는 지 알려드리겠습니다. 우선 저희는 앞으로 개발을 진행하면서 수행해야하는 각각의 작업들을 나눠서 모두 이슈로 만들어야 합니다. 이렇게 만들어진 이슈는 Automation 설정에 의해 자동으로 To Do열에 속하게 됩니다. 그리고 실제 개발에 들어갈 이슈를 골라 풀 리퀘스트를 생성하면 자동으로 In Progress 열에 속하게 됩니다. 이후 개발이 완료되어 리뷰가 필요한 풀 리퀘스트는 Review 열에 옮겨 놓게 되고 리뷰가 끝나 해당 풀 리퀘스트가 Merge 되는 경우 이와 연관된 이슈와 함께 Done 열로 이동하게 됩니다.

작업은 To Do -> In Progress -> Review -> Done의 순서로 진행이 된다 — 작업 진행 흐름에 대한 예시( To Do -> In Progress -> Review -> Done )

이처럼 칸반이란 각 작업의 진행도를 좌에서 우로 열을 이동함으로써 나타낼 수 있으며 오른쪽에 위치한 열 일수록 작업의 우선순위가 더 높게 측정 됩니다. 또한 각 열에서는 위쪽에 놓인 작업이 더 높은 우선순위를 가지는 방식입니다. 칸반을 효율적으로 활용하기 위해서 각 열에 부여할 수 있는 작업의 수에 제한을 둔다거나 하는 자세한 이야기는 빠졌지만 아 대략 이런 방식으로 일이 진행되는 구나 정도로 이해해주셨으면 합니다. 제가 보여드린 칸반 보드는 하나의 예시일 뿐 여러분의 취향대로 구성하시면 됩니다. 칸반에 대한 더 자세한 이야기는 해당 블로그 글을 참고하시면 도움이 될 것입니다.

4. 이슈 라벨 및 템플릿 설정

아까 말씀드린 것처럼 저희는 해야되는 모든 작업을 이슈로 만들어서 관리할 것입니다. 우선, 메뉴에서 Issues로 이동합니다.

각 이슈에는 해당 이슈가 어떤 이슈인지 간략하게 알려주는 라벨을 달아줄 수 있습니다. Github에서 기본적으로 여러 라벨을 제공하지만 여러분의 팀에 필요한 커스텀 라벨 또한 생성할 수 있으니 참고 바랍니다.

팀원들 간에 이슈를 서로 다른 형태로 작성하는 것이 아닌 팀 공통의 작성 틀이 필요할 수 있습니다. 이를 위해 Github에서는 Issue Template 기능을 제공하고 있습니다. 먼저, 메뉴의 Settings로 이동을 합니다. 이후 스크롤하다보면 Features-Issues에 Set up template 버튼을 누르시면 이슈 템플릿을 만드실 수 있습니다.

이슈 작성이 markdown 문법을 사용하듯이 이슈 템플릿 역시 markdown 문법을 사용합니다. 템플릿을 작성한 뒤 커밋을 하면 프로젝트에 .github/ISSUE_TEMPLATE 폴더가 생성됩니다. 우리가 생성한 템플릿 파일들이 여기에 위치하게 됩니다.

이렇게 이슈 템플릿을 작성하고 나서 다시 이슈를 생성하러 가보면 이슈 작성 전에 적용할 템플릿을 선택할 수 있게 됩니다. 앞으로는 선택한 템플릿에 맞춰서 이슈를 작성하시면 됩니다. 또한 이슈를 작성하실 때 우측 사이드바에 있는 Assignees, Labels, Projects 를 설정해주는 것도 잊지 말아주세요.

5. Pull request 템플릿 설정

앞에서 Issue 템플릿을 만들었다면 Pull request 템플릿은 매우 쉽게 만들 수 있습니다. 그저 .github 폴더로 이동해서 Add file을 통해 PULL_REQUEST_TEMPLATE.md 파일을 만들어 주시면 됩니다.

이슈 템플릿을 만들 때와 마찬가지로 markdown 문법으로 원하시는 템플릿을 작성한 뒤 커밋하시면 Pull request 템플릿이 추가됩니다.

추가로 팁을 주자면 Pull request 내용을 작성하실 때 resolve: #[이슈넘버]를 내용에 넣어주시면 해당 Pull request가 merge 될 때 연결해준 이슈 또한 자동으로 Github가 close 상태로 만들어 줍니다.

6. 브랜칭 전략 설정

브랜치 전략에는 다양한 방법이 있습니다. 예를 들어 Git Flow 같은 것이 있겠죠. 하지만 여기서는 이슈 기반 개발 플로우에 활용할 수 있는 전략을 하나 소개하고자 합니다.

새로운 이슈를 생성하고 번호를 확인한다.
로컬 저장소에 issue/#이슈번호 형식으로 새로운 브랜치를 생성한다. 그 후 새 작업 브랜치를 원격 저장소로 push한다.
이슈에 적어둔 목표들을 달성한다.
작업에 대해 테스트 과정을 거친다.
수정 사항을 커밋하고 원격 저장소로 push한다.
리뷰 과정을 거친 후 작업 브랜치를 메인 브랜치에 merge한다.
이슈를 닫고 작업 브랜치도 삭제한다.

7. 커밋 메시지 작성 규칙 설정

커밋 메시지 작성 시 팀 전체가 일관된 규칙을 사용하는 것이 보기 좋은 커밋 로그를 남기는 데 도움이 됩니다. 개인적으로 Udacity에서 사용하는 커밋 메시지 스타일 가이드를 사용하는 것을 추천합니다. 해당 스타일 가이드에 대한 자세한 규칙은 링크를 참고해주세요. 여기서는 해당 스타일 가이드 형태로 커밋 메세지를 작성하는데 도움을 주는 커밋 메세지 템플릿을 만드는 방법을 알려드리겠습니다. 우선 .gitmessage.txt 파일을 만들어 주세요. 그리고 파일에 다음과 같은 내용을 넣어주시면 됩니다.

# <타입>: <제목># 본문# 필요한 경우 주석 처리(#)를 지우고 사용. 이슈 트래킹을 위함
# Issues: #이슈번호 
# Resolves: #이슈번호
# See also: #이슈번호
# ------------------
# <타입> 리스트
#   feat    : 기능 (새로운 기능)
#   fix     : 버그 (버그 수정)
#   refactor: 리팩토링
#   style   : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
#   docs    : 문서 (문서 추가, 수정, 삭제)
#   test    : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
#   chore   : 기타 변경사항 (빌드 스크립트, 패키지 매니저 설정 수정 등)
# ------------------
#     제목과 본문을 한 줄 띄워 분리하기
#     제목 첫 글자를 대문자로
#     제목은 영어 50자 이내 (한글은 25자 이내)
#     제목은 명령문으로 (적용 시, 이 커밋은 <커밋 메시지> 합니다)
#     제목 끝에 마침표(.) 금지
#     본문은 영어 72자 마다 개행 (한글은 36자 마다)
#     본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------

실제로 커밋이 될 때는 #으로 표시된 부분은 주석 처리 되어서 메세지에 반영이 되지 않습니다. 제목과 본문 바로 밑 빈칸부터 메세지를 작성해주세요.

.gitmessage.txt 파일을 작성하셨으면 이를 commit.template 에 반영해야 합니다. 다음 명령어를 작성해주세요.

git config --global commit.template .gitmessage.txt파일의 경로(ex: C:\Users\progr\.gitmessage.txt)

이후로는 git commit 명령어를 치면 터미널 에디터에 작성한 커밋 템플릿이 보이게 됩니다.

만약 , VS Code 에디터를 사용하신다면 50/72 규칙을 위한 에디터 설정 글을 읽어보시는 것을 추천합니다.

8. 코드 리뷰

여러분이 작성한 pull request를 가지고 Github 상에서 코드 리뷰를 하는 방법에 대해 알려드리겠습니다. 제가 표시해둔 곳을 보시면 몇 개의 파일이 변경되었는 지 확인하실 수 있습니다. 각 파일을 확인하시고 Viewed 체크 박스를 체크하시면 봤다고 표시가 되며 코드 영역이 최소화 됩니다. 이렇게 코드를 다 확인하시고 Review changes 버튼을 누르시면 해당 Pull request에 대해서Comment를 남기거나 Merge를 승인하거나 변경을 요구하실 수 있습니다.

표시하진 않았지만 코드 옆 +버튼을 눌러서(드래그로 여러 라인 선택 가능) 각 코드 별로 리뷰 가능

코드 리뷰 과정은 버그를 줄이고 코드의 품질도 높이는 데 도움이 되는 만큼 협업을 하신다면 꼭 하시는 걸 추천드립니다.

마무리

이 글은 저처럼 로컬에서만 혼자 개발해오다가 처음으로 Github에 입문하는 분들을 위해 작성하였습니다. 최대한 많은 정보를 담고자 노력하였으나 깊이가 모자랄지도 모릅니다. 그만큼 제가 소개해드린 내용은 Github가 제공하는 서비스의 일부분일 뿐이고 Github에는 사용자들을 위해 아주 많은 편의 기능을 제공하고 있습니다. 이 글에서 알려드리지 못한 여러 기능들을 찾아서 배워보는 것도 좋을 것입니다.

또한 여러분들이 저와 같은 초보 개발자라면 반드시 Git에 대해서도 자세히 공부해보기를 권합니다. Git에 대해 알아갈수록 정말 마법같다고 느껴집니다. Git을 사용하는 데 주저함 없이 편하게 다룰 수 있게 된다면 개발자로서 한 단계 더 성장하실 거라 생각합니다.