[Git & GitHub] GitHub는 무엇일까?

GitHub는 무엇일까?

GitHub(깃허브)는 분산 버전 관리 툴인 Git(깃)을 지원하는 웹 호스팅 서비스이다.

협업과 관리를 위해 만들어진 Git을 웹을 통해 더 쉽게 도와줄 수 있는 서비스라고 생각하면 된다.

전문적이게 말하면 로컬에서 프로젝트를 관리할 수 있게 비주얼 인터페이스를 제공하며 공유, 평가 등의 소셜 네트워크 기능을 사용할 수 있게 도와준다는 것이고,

쉽게 말하면 ‘git add . ‘ 등 명령어로 사용되었던 Git을 시각적으로 보며 사용하게 도와주며, 덕분에 다른 사람들과 서로의 코드에 대해 공유하고 의견을 나눌 수 있게 된다는 것이다.

이를 통해 같은 프로젝트를 진행하는 동료 뿐만 아니라 모르는 여러 개발자들과 오픈소스로 협업을 진행할 수 있게 된다.

GitHub의 용어와 기능

사실 GitHub에서 사용하는 기능은 Git을 이해한다면 직관적으로 이해할 수 있는 것이 대부분이다. 따라서 GitHub 이전에 Git을 공부하는 것이 조금 더 유리하다고 볼 수 있다.

하지만 GitHub를 처음 이용한다면 생소한 부분이 있을 수 있기에 간단하게 설명하려고 한다.

Clone :

Clone는 원격저장소(GitHub)를 복제해서 로컬 저장소에 저장하는 기능이다. fork와 다른 점은 fork는 원격저장소를 복제해서 나의 원격저장소에 저장하는 기능이고, Clone는 원격저장소를 복제해서 나의 로컬저장소에 저장하는 기능이다.

사진에서 보이는 것처럼 우측의 Code버튼을 누르면 Clone, Download ZIP 등이 적힌 화면이 나타난다.

이 화면은 Code를 어떻게 로컬 저장소로 가져갈 지 선택할 수 있는 화면인데, URL주소를 이용해 Clone이 가능하며 GitHub Desktop이라는 App과 ZIP파일로의 다운로드를 통해서도 로컬 저장소로의 저장이 가능하다는 것을 보여준다.

여기서는 많이 이용하는 HTTPS 형식의 URL주소를 이용한 Clone 방법에 대해 소개하겠다.

git clone [REPO_URL] [DIR]

의 형식으로 [REPO_URL]에는 원격저장소에서 복사한 URL주소를 적으면 되고, [DIR]에는 저장할 로컬저장소의 위치를 적으면 된다.
( [DIR]의 경우는 보통 cd(change directory)를 이용해 원하는 로컬저장소의 위치로 이동된 상태에서 명령을 수행하기 때문에 생략해도 상관없다. )

사진에서 보이는 URL주소로 예를 들자면

위의 사진처럼 사용하면 된다. 이때 현재 폴더에 원격저장소와 같은 이름의 폴더가 생성되며, 그 폴더 안에는 .git 폴더와 원격저장소에서 복제한 파일이 생성된다.

복제한 원격저장소에는 README.md 파일만 있으므로 위의 사진처럼 .git폴더와 README.md 파일만 생성된 것을 확인할 수 있다.

이렇게 원격저장소의 Clone이 마무리되었다. Clone으로 만든 로컬저장소에서 새로운 기능들을 구현하고, 이를 commit, push하며 GitHub를 통한 협업이 진행된다.

Remote :

Remote는 원격 저장소를 관리할 수 있는 명령어로, 만들어져 있는 로컬저장소에 만들어져 있는 원격저장소를 연결하는 기능을 한다.

Clone과 다른 점은 Clone은 만들어져 있는 원격 저장소의 파일을 복제해서 그 내용을 로컬 저장소에 저장하고 연결하는 기능을 하는데,

Remote는 로컬 저장소, 원격 저장소 둘다 독자적으로 만들어져 있는 상황에서 내용의 변화없이 서로를 연결 시키는 기능을 하는 것이다.
(물론 pull, push를 활용하면 서로의 내용이 변하고 같아지게 된다. )

git remote -v

위와 같은 명령어를 사용하면 다음처럼 현재 로컬 저장소에 연결되어 있는 원격저장소를 확인할 수 있다.

git remote remove [등록한 원격저장소의 이름]

위와 같은 명령어를 사용하면 다음처럼 원격저장소와의 연결을 끊을 수 있다.

git remote add [등록할 원격저장소의 이름] [등록할 원격저장소의 주소]

위와 같은 명령어를 사용하면 다음처럼 현재 로컬 저장소와 원하는 원격저장소를 연결할 수 있다.

Issues :

Issues란 프로젝트를 진행하며 발생하는 버그, 개발, 풀 리퀘스트 등 거의 모든 것을 나타낸다.

GitHub에서는 Issues 기능을 통해 프로젝트에서 발생하는 모든 문제를 관리하는데, 이를 통해 버전마다 개발의 흐름을 정리할 수 있다.

GitHub에서 repositories를 들어간 후 Issues를 선택하면 위와 같은 화면이 나타난다. 지금은 아무것도 없지만 issue를 등록하면 작성된 issue를 확인할 수 있는 화면이다.
여기서 오른쪽에 New issue를 누르면 아래와 같은 화면이 나타난다.

이때 상황마다 다르지만 보통 이 화면에서는 제목과 글을 쓰는 페이지 공간, 그리고 오른쪽에 보이는 Labels, Milestone 을 신경쓰면 된다. ( Assignees도 자주 쓰이는데, 해당 작업의 담당자를 뜻한다. )

제목과 글에는 issue에 대한 내용을 작성하며, Labels를 선택해서 해당하는 이슈의 분류(성격)를 선택하면 된다.

Milestone은 생소할 수 있는데, 해당 이슈가 속한 버전을 생각하면 된다. Milestone이 version 1.0.0이면 버전1을 개발할 때 발생하는 이슈들을 해당 마일드스톤에 정리하는 것이다.

필요한 내용을 작성한 후 Submit new issue를 클릭하면 정상적으로 issue가 등록된 것을 확인할 수 있다.

Wiki :

GitHub에서 원격저장소(repository)에 들어가면 다음처럼 Wiki라는 항목이 있다.

Wiki는 해당하는 원격저장소(repository)에 대한 문서를 만들고 유지하는 기능을 한다.

이때 Wiki에는 저장소에 활용된 기술스택을 정리해놓을 수 있고, 단계별 목표와 진행사항을 정리해둘 수 있다.(팀마다 Wiki의 사용에 대해 약속이 있을 수 있다.)

Wiki를 사용해보자

이전의 사진에서 Create the first page를 클릭하면 다음과 같은 페이지로 이동하는데,

이곳에서 마크다운 언어를 이용해서 Wiki에 필요한 내용을 작성하면 된다.

이후 페이지 오른쪽 아래에 있는 Save Page를 누르면 다음과 같이 새로운 Wiki Page가 등록된 것을 확인할 수 있다.

이때 우리는 두가지 정도를 더 추가해볼 수 있다.

첫 번째는 footer을 추가하는 것이다.
바닥글이라고도 하는데 동그라미친 Add a custom footer을 누르면

위와 같이 처음 page등록했을때와 비슷한 화면이 나타난다.
(다른 점은 제목에 Home 대신 _Footer라고 적혀있다는 것이다.)

마찬가지로 내용 작성 후 Save Page를 클릭하면

위와같이 바닥글 부분이 추가되었음을 알 수 있다.

두 번째로 추가할 수 있는 것은 Sidebar이다.

Add a custom sidebar를 누르면 예상대로 _Sidebar 이라는 제목의 page 작성화면이 나타난다.

이 역시 내용을 작성 후 Save Page를 클릭하면

위와같이 오른쪽 사이드에 내용이 추가된 것을 확인할 수 있다.

이렇게 Wiki 작성 방법은 마무리 된다.

이제 Wiki를 관리하는 방법을 알아보자

위의 사진에서 오른쪽에 있는 Edit을 누르면

위와같은 화면이 나타난다.

이때 오른쪽 위에 보이는 Page History를 클릭하면

위와같이 페이지에 대한 변경날짜와 메시지, 그리고 작성자를 확인할 수 있다.
(실제 Wiki에서는 변경 메시지를 직관적으로 작성해주는 것이 좋다.)

이때 비교하고싶은 내용을 체크박스 선택 후 오른쪽에 있는 Compare Revisions을 클릭하면

위와같이 해당 내용들을 비교할 수 있다.

현재 third edit이 적용된 상황인데, 오른쪽 상단에 있는 Revert Changes를 클릭한다면 변경사항이 선택된 버전(edit이 없는 상황)으로 되돌아가는 것을 확인할 수 있다.

(Revert 전 Wiki Page)

(Revert 후 Wiki Page)
(** 사진을 추가하기 위해서 다시 revert를 진행했습니다. 제목 밑에 있는 revisions 횟수가 신경 쓰이셨다면 양해부탁드립니다.)

이후 History를 통해 Revert 되었다는 정보를 확인할 수 있다.

Pull request :

pull request는 pr이라고 불리며 ‘정중한 요청’ 이라는 뜻으로 쓰인다.

merge(병합)와 연관된 기능인데, 내가 혼자 기능을 만들었다고 무작정 merge(병합)를 해버리면 함께 일을 하는 사람의 입장으로는 준비가 되지 않았을 수 있다.

실제로 그 기능이 너무 완벽해서 잘 돌아간다하더라도 의견을 듣고 합치는 것과 무작정 합치는 것은 협업의 과정에서 큰 차이를 발생시킨다.

따라서 협력자에게 branch merge(브랜치 병합) 을 요청하는 메시지를 보내는 것이 pull request이다.

쉽게말해서 이 코드를 merge(병합)해도 될까요? 라고 물어보는 것이다.

pull request를 사용해보자

GitHub에서 원격저장소(repository)에 들어가면 다음처럼 Pull request라는 항목이 있다.

Pull request를 만들기 위해 오른쪽에 있는 New pull request를 클릭하면 다음과 같은 화면으로 넘어간다.
(현재 원활한 Pull request를 위해 미리 test branch를 이용해서 새로운 변경사항을 commit, push 완료한 상태이다. )

위의 화면 아래에서 내가 request하고자 하는 변경사항(branch)을 선택하면 다음과 같이 merge가능여부, 작성자, 변경되는 내용 등을 확인할 수 있다.

내용 확인 후 오른쪽에 있는 Create pull request를 누르면 다음 화면이 나타난다.

(**사실 pull request의 첫 번째 화면에서 New pull request가 아니라 그 위에 있는 Compare & pull request를 클릭하면 바로 이 화면이 보여진다.)

위의 사진처럼 pull request(정중한 요청)를 위한 제목과 내용을 작성한 뒤 Create pull request를 클릭하면

위와같이 정상적으로 Pull request되었음을 확인할 수 있다.

이제 작성한 pull request를 클릭해 들어가면

위와같이 pull request 내용을 확인할 수 있고, merge하거나 close pull request(거부)하거나 comment를 작성할 수 있다.
(**이때 merge를 한다면 merge가 확정된 후 pull request는 자동으로 close된다.)

Merge pull request를 클릭해 merge를 하면 main branch에 변경내용이 반영되었음을 확인할 수 있다.

또한 다시 pull request에 들어가면

위의 사진처럼 open된 pull request는 없고,

위의 사진처럼 close된 pull request를 확인할 수 있다.

Fork :

fork는 남의 저장소를 내 계정에 통째로 복제하는 기능이다.

기본적으로 commit을 원본저장소에 push할 수 있는 사람은 원본저장소의 소유자와 소유자가 인정한 협력자 뿐이다.

이때 협력자가 늘어날수록 저장소 관리가 어려워지기 때문에 협력자의 수는 일정 이상을 넘기지 않는다. (믿을 수 있으면서 실력도 있는 사람이 필요하다)

하지만 많은 개발자에게 의견을 받고 코드를 개선하고 싶은 니즈는 항상 존재했고 fork를 통해 그것이 가능하게 되었다.

내가 협력자가 아니더라도 fork를 통해 남의 저장소를 내 저장소에 통째로 복제한다면 내가 독립적으로 그 코드를 관리할 수 있게 되며, 이때 내가 생성한 branch나 commit등은 남의 저장소에 반영이 되지않고 오직 내 저장소에만 반영된다.

이후 개선점이나 버그를 발견한다면 앞서 배운 pull request를 통해 남의 저장소에 개선된 코드를 제안할 수 있다.

이렇듯 우리는 fork를 통해 수많은 오픈소스에 기여할 수 있으며, 그 덕분에 오픈소스 생태계는 발전할 수 있다.

fork를 사용해보자

내가 복제하고싶은 남의 repository를 들어가면

위의 사진처럼 오른쪽 상단에 fork라는 문자와 몇명이 fork를 했는지 숫자가 보인다.

문자를 클릭하면 정말 간단하게 내 repository로 해당 repository가 복제된다.

위의 사진을 보면 repository가 hyundp(repository의 원래 주인)에서 subhyundp(fork를 해서 repository를 복제한 계정)의 소속으로 들어간 것을 확인할 수 있다.

또한 밑에 ‘forked from hyundp/github-test’라고 어느 계정에서 fork를 해왔는지에 대한 정보 역시 포함된다.

fork해온 repository에서 내용을 변경하더라도

아래 사진처럼 원래 repository(hyundp의 repository)에는 반영되지 않음을 확인할 수 있다.

이제 변경 내용을 원본 repository에 반영해보자

위의 사진처럼 내 계정(fork를 통해 남의 저장소를 복제한 계정)에서 Pull request로 들어간 후 오른쪽에 있는 New pull request를 클릭하면

위의 사진처럼 원본 repository에 pull request를 보내는 내용이 자동으로 생성되어 나타난다.

이때 하단의 변경내용을 확인한 후 오른쪽의 create pull request를 클릭하면

위 사진처럼 pull request에 대한 제목과 내용을 쓰는 화면이 나타나고, Create pull request를 누르면

위 사진처럼 원본 repository에 pull request가 보내진 것을 확인할 수 있다.

이제 원본 repository의 계정에서 pull requests를 확인해보면

이전 사진에서 보낸 것과 같은 내용의 pull request를 확인할 수 있고, 이를 Merge(병합)할 지 선택할 수 있다.

Merge를 하게 되면

다음처럼 원본 repository에도 변경 내용이 반영된 것을 확인할 수 있다.

마무리

GitHub는 협업의 기능 이외에도 장점이 정말 많다. 특히 개발과 관련해서 다른 사람이 작성한 코드를 보고, 공부한 정리노트를 보고, 만들어낸 서비스를 보면서 많은 것을 배울 수 있다.

따라서 만약 GitHub가 익숙하지 않거나 협업 기능을 사용하는 것이 부담스럽다면, GitHub를 탐험(Explore)하며 재미를 찾아가면 좋겠다.

감사합니다.