이번 포스팅에서는 GitHub 간단 사용법에 대해서 소개하겠습니다.
GitHub은 여러 명의 개발자들이 언제 어디서나 협업을 하면서 코드를 공유하고 버전 관리를 할 수 있게 해주는 분산형 Git Repository 호스팅 서비스 플랫폼입니다.
Git과 GitHub은 다른 것인데요, Stackoverflow[1]에 둘을 비교 설명한 내용이 있어서 소개합니다.
Git은 버전 관리 시스템이며, 소스 코드 이력을 관리하는 툴입니다. (Git is a revision control system, a tool to manage your source code history.)
GitHub은 Git repositories를 위한 호스팅 서비스 입니다. (GitHub is a hosting service for Git repositories.)
따라서 Git과 GitHub은 똑같은 것이 아닙니다. Git 은 툴이며, GitHub은 Git을 사용하는 프로젝트를 위한 서비스입니다. (So they are not the same thing: Git is the tool, GitHub is the service for projects that use Git.) |
Git은 리눅스의 창시자인 Linus Torvalds가 2005년에 기존의 리눅스 커널 개발에 사용하고 있던 버전 관리 시스템의 라이센스가 변경되면서 새로운 시스템을 찾는 과정에서 Git 을 만들었다고 합니다. (진정 Linux Torvalds는 오픈소스계의 아버지인가 봅니다!)[2]
아이러니 한 것은 오픈소스에 적대적이었던 마이크로소프트가 세계 최대 오픈소스 공유 플랫폼인 GitHub을 2018년 6월에 75억 달러(약 8조원)에 인수를 했다는 점입니다. 세상 참 오래 살고 볼 일입니다. (MS에 대한 불신 때문일까요? MS의 GitHub 인수 발표 이후에 GitHub과 같은 Git Repository 호스팅서비스인 GitLab으로 망명하는 개발자들도 있습니다)
만약 이 포스팅을 보고 있는 분이 팀으로 협업을 하는 개발자가 아니라면, 개인용 랩탑 컴퓨터로 R이나 Python, SAS, MATLAP 등으로 혼자 분석 업무 만 담당하는 분이라면 GitHub을 왜 써야 하나(Why GitHub?) 궁금증이 생길 것입니다. 아래의 그림은 Vincent Driessen 이라는 개발자께서 ‘A successful Git branching model’[3]이라는 제목으로 Why Git?, Decentralized but centralized, The main branches, Supporting branches 등에 대해서 블로그에 소개한 내용입니다. 시간의 흐름에 따라서 여러 명의 개발자가 협업하면서 코드 버전을 관리하는 과정을 볼 수 있을 텐데요, Git과 같은 버전관리 시스템이 없다면 무척 애를 먹을 것이라고 예상할 수 있습니다.
비단 협업 뿐만이 아니더라도, 분석가가 여러 버전의 분석 코드를 작성하다 보면 ‘그저께 코딩했던 데이터 전처리 R코드가 어디있더라?’, ‘어제 분석했던 Random Forest의 Hyperparameter 설정값을 수정하고 덮어써버렸네… 뭐였더라?’, ‘000로 부터 그저께 Python 코드를 이메일로 받았었는데 그게 어디있지?’와 같은 종류의 어려움에 처할 수 있는데요, 버전 관리 시스템이 있다면 이를 피할 수 있게됩니다.
[ 그림 1. A successful Git branching model (by Vincent Driessen) ]
* Source: https://nvie.com/posts/a-successful-git-branching-model/
코드 버전 관리를 도와주는 버전 관리 시스템은 크게 (1) 로컬 버전 관리 시스템 (Local Version Control System), (2) 중앙 집중식 버전 관리 시스템 (Centralized Version Control System), (3) 분산 버전 관리 시스템(Distributed Version Control System)으로 구분할 수 있으며, Git은 이중에서 ‘분산 버전 관리 시스템’에 해당합니다.
(* Reference: https://git-scm.com/book/ko/v1)
[ 그림 2. 버전 관리 시스템 (Version Control System) ]
중앙 집중식 버전 관리 시스템(Subversion, Perforce 등)은 사용 방법이 분산형 대비 상대적으로 쉽다는 장점이 있습니다. 하지만 코드가 저장되어 있는 중앙 서버에 장애가 발생했다 거나, 개발자 중에 한명이 코드 커밋을 완료하지 않고 퇴근을 해버린다거나 하면 버전 관리 기능이 마비가 되어 협업을 할 수가 없는 단점이 있습니다.
분산 버전 관리 시스템은 중앙 집중식 버전 관리 시스템과 장점과 단점이 정반대입니다. 장점으로는 클라이언트가 저장소 자체를 복제하게 되므로 중앙 서버에 장애가 발생해도 클라이언트에서 개발 작업을 진행하는데 문제가 없으며, 여러 그룹과 협업을 진행하는데도 문제가 없습니다. 반면에, 처음 분산형을 사용하는 분이라면 전체 구조와 흐름을 이해하고 능숙하게 사용하는데 (중앙 집중형 대비 상대적으로) 어렵다는 단점이 있습니다.
(저는 5년 전에 Coursera에서 처음으로 GitHub에 대해 20여분짜리 동영상 강의를 접하였었는데요, 뭐가 여기 저기를 왔다 갔다 하는데요, 강사가 무슨 얘기를 하는지 도통 이해할 수가 없었던 기억이 있습니다. ‘그냥 코드 카피해서 게시판에 페이스트 해서 숙제 제출하면 안되나?’ 라고 투덜거렸었습니다. ^^;)
아래의 그림3은 GitHub에서 여러 명의 개발자가 협업을 할 때, 소스 코드를 수정하고 이를 소스 코드에 반영해달라고 요청하는 Pull Request를 하는 절차를 도식화한 것입니다. [2] 클라우드 상의 GitHub에서 타인의 git과 자기의 git 사이의 흐름, 그리고 자신의 로컬 개발환경 사이의 전체 흐름에 대해서 살펴보면 GitHub의 사용 절차를 이해하는데 도움이 될 것이라고 생각합니다.
아래의 그림3 에서는 (1) 다른 사람의 master branch를 자신의 github으로 Fork 해서 (2) 로컬 개발환경으로 pull 하고, (3) topic branch를 만들어서 (4) 수정 작업을 한 후, (5) 자신의 github에 원격 branch 작성을 push하고, (6) original master branch를 가진 사람에게 pull request를 전송해서 피드백을 요청하면, (7) original master branch 주인이 pull request를 열고 차이점을 비교한 후 만족스러우면 merge 하는 절차입니다.
[ 그림 3. Git Pull Request Workflow ]
최근 Mac 에는 Git이 기본으로 설치되어 있으며, 리눅스나 윈도우즈는 자신이 사용하는 종류에 맞게 다운받아서 설치를 해주어야 합니다. Git 설치는 ‘https://git-scm.com/book/ko/v2/시작하기-Git-설치’ 를 참고하세요. [4]
GitHub.com account 생성 및 SSH 인증(https://github.com/join)을 모두 끝마쳤다는 가정 하에 이제부터 GitHub의 간단한 사용을 예를 들어서 소개하겠습니다.
아래의 예는 GitHub hello world (https://guides.github.com/activities/hello-world/) 튜토리얼을 한글로 번역한 내용입니다. [5] 위의 그림3은 다른 사람의 git을 fork 하는 것으로 시작하는데요, 아래의 예는 좀더 간단하게 다른 사람의 git이 아니라 자기 자신의 github 안의 repository 를 가지고 pull request 해보는 예입니다. pull request 는 Git의 꽃이므로 정확하게 이해하는게 좋겠습니다.
- Repository 생성하고 사용하기
- 새로운 Branch 시작하고 관리하기
- 파일에 변경사항 만들고 GitHub에 push 하기 (commit)
- Pull request 열고 합치기(merge)
[1 단계] Repository 생성
Repository는 보통 하나의 프로젝트를 구성하기 위해 사용합니다. Repository는 여러 개의 폴더, 파일, 이미지, 동영상, 데이터셋을 가질 수 있습니다. 이 Repository에 코드를 저장하고, 다른 개발자와 코드를 공유하며, 의견도 나누고, 코드 수정도 같이 할 수 있습니다.
(1) GitHub.com 의 우측 상단에 ‘+’ 메뉴를 클릭한 후,
(2) ‘New repository’ 하위 메뉴를 선택하면 아래와 같은 화면이 나타납니다.
(3) Repository name에 ‘hello-world’라고 이름을 기입해주고,
(4) ‘Public’ 외부 공개 모드를 선택해주세요. 참고로, Private은 비공개인 대신에 유료 서비스 입니다.
(5) ‘Initialize this repository with a README’ 를 선택 후 ‘Create repository’ 단추를 눌러주세요.
짜잔~! ‘hello-world’ Repository가 생성되었습니다.
[2 단계] Branch 생성
Repository에 다른 버전의 작업을 할 때 새로운 Branch를 만듭니다. Repository를 처음 만들면 디폴트 설정으로 master 라는 이름의 최종적인 Branch가 만들어집니다. Branch에서 작업을 실험도 하고 수정을 한 후에 master에 커밋합니다.
Master branch에서 새로운 branch를 만들게 되면 그 시점의 master를 그대로 복사합니다. 만약 당신이 당신의 branch에서 작업을 하는 동안 다른 누군가가 master branch에서 수정을 한 경우에 당신은 변경사항을 pull해서 가져올 수 있습니다.
아래의 다이어그램은 [5]
Master branch 에서
Feature라는 이름의 새로운 branch를 생성하고,
Pull request 와 변경했으면 하는 사항에 대한 토론을 진행한 후,
Master branch 에 ‘feature branch’를 병합(merge)하는
작업 절차를 보여줍니다.
새로운 branch를 만드는 방법은
(1) ‘hello-world’ repository로 가서
(2) ‘branch: master’라는 파일 리스트의 제일 위에 있는 drop down 메뉴를 선택 후
(3) Branch 텍스트 상자에 ‘readme-edits’이라는 이름의 Branch 이름을 입력하고,
(4) 파란색의 ‘Create branch’ 상자를 선택하거나 키보드의 ‘Enter’를 치면 됩니다.
이제 ‘hello-world’ repository 안에 ‘master’ branch 그리고 master branch를 복사한 ‘readme-edits’ branch의 두개 branch가 생겼습니다.
[3 단계] 수정 후 commit 하기
(1) README.md 파일을 선택 후 우측 상단의 연필 모양 아이콘을 클릭
(2) 편집창에서 수정사항 쓰기
(3) 편집창 아래에 있는 ‘commit message’란에 수정사항에 대한 부연설명 쓰기
(무엇을, 왜 수정했는가를 써서 다른 개발자가 쉽게 이해할 수 있도록)
(4) ‘Commit changes’ 단추 클릭
하면 Master에서 복사한 ‘readme-edits’ branch를 수정할 수 있습니다. 이제 애초의 master branch와 방금 수정한 readme-edits branch는 서로 다른 branch가 되었습니다.
[4 단계] Pull Request 열기
Pull Request를 통해서 당신이 만든 수정사항을 제안하고 다른 사람이 검토해줄 것을 요청하며 수정사항을 master branch에 반영하도록 할 수 있습니다. Pull Request 는 master branch와 새로 만든 branch 간의 다른 점(differences, diffs)을 녹색이나 빨간색으로 보여줍니다.
GitHub의 @mention 시스템을 이용하여 특정 팀이나 사람에게 피드백을 요청할 수도 있습니다.
(1) Pull Request 탭을 클릭하여 나타난 페이지에서 ‘New pull request’ 단추를 클릭
(2) 변경점 비교 창에서 비교를 하려고 하는 ‘readme-edits’ branch를 선택하면 master branch와 차이점을 비교하게 됩니다. 비교 페이지에서 추가(+), 삭제(-), 변경사항을 살펴봅니다.
(3) 비교한 변경사항이 원하는 내용임을 확인하였으면 Pull request의 제목과 설명을 추가한 후에 ‘Create pull request’ 단추를 누릅니다.
[5 단계] Pull Request 합치기 (merge)
마지막 단계로서, ‘readme-edits’ branch에서 수정한 사항을 원래의 master branch에 합쳐보겠습니다.
(1) Master branch에 변경점을 반영하기 위해 ‘Merge pull request’ 녹색 단추 클릭
(2) ‘Confirm merge’ 클릭
(3) 변경사항이 master branch에 모두 반영이 되었으므로 ‘Delete branch’ 자주색 단추를 눌러서 ‘readme-edits’ branch 삭제하기
드디어 pull request를 original master branch에 합치는 것을 끝마쳤습니다. ^^b
‘readme-edits’ branch에서 수정했던 사항들이 original ‘master’ branch에 합쳐진 것을 확인할 수 있습니다.
다음번 포스팅에서는 터미널에서 Git을 사용해서 GitHub Repository에 commit 하는 방법을 소개하겠습니다.
많은 도움이 되었기를 바랍니다.
* Reference
[1] https://stackoverflow.com/questions/13321556/difference-between-git-and-github
[2] ‘소셜 코딩으로 이끄는 GitHub 실천 기술’, 오오츠카 히로키 지음/윤인성 옮김, Jpub
[3] https://nvie.com/posts/a-successful-git-branching-model/
[4] Git 설치 및 명령어 참고: https://git-scm.com/
[5] GitHub hello world: https://guides.github.com/activities/hello-world/
