[GitHub] GitHub 프로젝트 관리하기 - 프로젝트 관리자 입장에서

[이전 포스트]

[GitHub] 개발자라고? 깃헙 알지? PR 할 줄 알지? - GitHub를 얕게만 아는 사람을 위해

 

---

 

 

Git - GitHub 프로젝트 관리하기

'깃북 6.3 GitHub - GitHub 프로젝트 관리하기'에 대한 발췌 및 정리입니다.

 

---

GitHub 프로젝트 관리하기

이전 포스트에서 다른 사람의 프로젝트에 기여하는 방법을 알아보았습니다.

 

이번에는 직접 프로젝트를 운영하는 법을 살펴보도록 하겠습니다.

프로젝트를 생성해서, 관리하는 방식입니다.

 

 

새 저장소 만들기

저장소를 새로 만들고 프로젝트 코드를 공유해봅시다.

대시보드의 왼쪽에 있는 “New repository” 버튼을 클릭하면,

저장소를 만드는 폼으로 이동합니다.

 

새 저장소 만들기

 

프로젝트 이름을 넣는 것만 필수고, 다른 것은 생략해도 됩니다.

“Create Repository” 버튼을 클릭하면 '뿅’하고

<user>/<project_name> 위치에 GitHub 저장소가 생깁니다.

 

GitHub에 프로젝트를 올리면

다른 사람들에게 프로젝트 URL을 알려주고 공유할 수 있습니다.

 

모든 프로젝트의 HTTPS URL은

https://github.com/<user>/<project_name> 처럼 생겼고,

SSH는 git@github.com:<user>/<project_name> 처럼 생겼습니다.

 

Git은 이 두 URL을 통해서 Fetch하고 Push 할 수 있지만,

인증 방식은 사용하는 프로토콜에 따라 다릅니다.

 

 

 

공개 프로젝트는 보통 HTTPS URL을 공유합니다

git clone 은 GitHub 계정 없이 할 수 있기 때문에

공개 프로젝트를 공유할 때는 SSH보다 HTTPS URL를 더 많이 공유합니다.

 

SSH URL을 사용하려면 계정도 있어야 하고 SSH 키도 GitHub에 등록해야 합니다.

브라우저에서 프로젝트 페이지에 접속할 때도,

저장소 URL로 사용하는 HTTP URL을 그대로 사용합니다.

 

 

동료(Collaborator) 추가하기

저장소에 커밋 권한을 주고 싶은 동료가 있으면 “Collaborator” 로 추가해야 합니다.

Ben과 Jeff, Louise라는 동료가 있는데,

이들이 내 저장소에 Push 할 수 있도록 하고 싶으면

내 프로젝트에 GitHub 계정들을 추가해야 합니다.

 

계정이 추가된 사람은 해당 프로젝트와 Git 저장소에

“Push” 할 수 있을 뿐만 아니라 읽고 쓰기도 가능합니다.

 

 

 

Settings 페이지로 이동하기

 

우선 프로젝트 레포지토리의 우측 상단 점 세개 … 를 눌러

Settings 페이지로 이동합니다.

 

이후 아래처럼 왼쪽 메뉴에서 “Collaborators” 메뉴를 클릭합니다.

 

 

 

Add people을 누르고, 원하는 사람을 추가합니다.

 

 

 

Pull Request 관리하기

프로젝트를 만들고

코드도 넣고

동료가 Push 할 수 있게 권한도 줬습니다.

 

이제 Pull Request가 왔을 때 어떻게 해야 하는지 봅시다.

 

Pull Request는

(1) 같은 저장소나

(2) Fork 한 저장소에서

브랜치를 보내오는 것입니다.

 

이 둘의 차이는 권한에 있습니다.

Fork 한 저장소는 다른 사람의 저장소이기 때문에

그 보내온 브랜치에 Push 할 권한이 없습니다.

 

하지만, 같은 저장소의 브랜치에는 Push 할 수 있습니다.

 

 

 

예시

“tonychacon” 이라는 사람이 “fade” 라는 Arduino 프로젝트를 만든 상황을 살펴봅시다.

 

이메일 알림

어떤 사람이 코드를 수정해서 Pull Request를 보내왔습니다.

그러면 새로운 Pull Request가 왔다는 메일이 담당자에게 갑니다.

 

아래와 같은 메일이 보내집니다.

새 Pull Request에 대한 이메일 알림

 

해당 Pull Request에서 어떤 파일이 얼마나 변경됐는지 보여줍니다.

그리고 Pull Request 페이지 링크도 존재하며,

CLI(command line interface)로 Merge 하는 방법과 URL도 간략히 보여준다.

 

git pull <url> patch-1 라는 명령을 통해 리모트 브랜치를 간단히 Merge 할 수 있습니다.

저장소를 리모트로 추가하지 않아도 됩니다.

필요하다면 토픽 브랜치를 만들고 Pull Request로 직접 Merge 해도 됩니다.

 

Patch Links 중

.diff 와 .patch URL은

Pull Request의 ‘Unified Diff’ 와 Patch 버전의 URL 입니다.

 

이 URL로 아래와 같이 Pull Request를 Merge 할 수 있습니다.

 

$ curl <http://github.com/tonychacon/fade/pull/1.patch> | git am

 

 

 

Pull Request로 함께 일하기

Pull Request를 만든 사람과 토론할 수 있는 페이지가 열립니다.

GFM(Github Flavored Markdown)을 사용해

특정 커밋을 선택하거나,

특정 라인을 지정하거나,

전체 Pull Request 자체도 코멘트를 남길 수 있습니다.

 

보내온 코드가 마음에 들어서 Merge 하고 싶다면 로컬에 가져와서 Merge 할 수 있습니다.

git pull <url> <branch> 명령으로 Merge 하면 되는데,

(1) 먼저 Fork 한 저장소를 리모트로 추가하고

(2) Fetch 해서 Merge 합니다.

 

GitHub 사이트에서 Merge 버튼을 누르는 걸로 간편하게 Merge 할 수 있습니다.

이를 Trivial Merge 라 합니다

Fast forward가 가능해도 non-fast forward Merge를 하기 때문에 Merge 커밋이 생깁니다.

그래서 “Merge” 버튼을 클릭해서 Merge 하면 항상 Merge 커밋이 생깁니다.

 

이전 포스트에서 말했던

"GitHub 프로젝트에서 Merge 버튼을 눌러 Merge를 하는 이유는

Merge 커밋을 명시적으로 남기기 위함입니다"

와 일맥상통합니다.

 

Merge 버튼과 Pull Request를 수동으로 Merge 하기

 

만약 Pull Request를 Merge 하지 않기로 했다면 그냥 닫으면 됩니다.

그러면 그 Pull Request를 보낸 사람에게 알림이 갑니다.

 

 

Pull Request의 Ref

일일이 리모트를 등록하고 Pull 하는 것은

Pull Request를 많이 처리하는 사람에게는 고통스럽습니다.

 

따라서 GitHub는 이럴 때 사용할 수 있는 방법을 제공합니다.

 

GitHub는 Pull Request의 브랜치를

서버에 가상 브랜치 형태로 노출해줍니다.

 

GitHub가 자동으로 해주기 때문에, 이를 이용하면 됩니다.

 

이걸 해보려면

(1) 저수준(“plumbing”) 명령어인 ls-remote를 통해 PR의 브랜치를 확인하고,

(2)  .git/config 파일을 열어서 origin 리모트를 찾아 아래처럼 fetch에 refspec을 등록하면 됩니다.

[remote "origin"]
    url = <https://github.com/libgit2/libgit2.git>
    fetch = +refs/heads/*:refs/remotes/origin/*
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

 

 

이후 git fetch 를 실행하면

새로운 Refspec의 브랜치도 가져옵니다.

$ git fetch

# …
 * [new ref]         refs/pull/1/head -> origin/pr/1
 * [new ref]         refs/pull/2/head -> origin/pr/2
 * [new ref]         refs/pull/4/head -> origin/pr/4
# …

 

이렇게 서버에 있는 모든 Pull Request를 추적하는 트래킹 브랜치를 만들 수 있습니다.

Pull Request를 로컬에 가져와 작업하는 게 편해집니다.

 

이는 실제로 GitHub에서 Merge 하기 전에

로컬로 가져와 먼저 테스트를 해볼 수 있음을 의미합니다.

 

 

 

 

Pull Request 이어가기, PR을 브랜칭하기

Pull Request를 Merge 할 브랜치는 master 가 아니어도 됩니다.

주 브랜치를 고를 수도 있고 Pull Request를 열 때 다른 브랜치를 골라도 됩니다.

심지어 다른 Pull Request를 고를 수도 있습니다.

 

착착 잘 진행하는 어떤 Pull Request가 있는데,

여기에 뭔가 아이디어를 더하고 싶다는 생각이 들었습니다.

 

그런데 좋은 아이디어라는 확신도 부족하고,

무엇보다 Merge 될 브랜치에 Push 권한이 없다면

 

이럴 때 Pull Request에 Pull Request를 보낼 수 있습니다.

Pull Request을 어디로 보낼지 대상을 선택

 

쉽게 말해,

다른 Fork 저장소나 Pull Request의 브랜치를 골라

Pull Request를 열 수 있습니다.

 

 

 

특별한 파일

저장소에 있는 파일 중

GitHub가 사용하는 몇 가지 특수한 파일이 있습니다.

 

README

GitHub는 저장소 랜딩 페이지, 즉 처음 보게되는 페이지를

README 파일을 이용해서 보여줍니다.

 

README 파일 형식에 상관없이 잘 보여줍니다.

README 파일이든 README.md이든 README.asciidoc 이든

GitHub가 자동으로 렌더링해서 보여줍니다.

 

보통 파일에 저장소나 프로젝트에 처음 방문한 사람들에게

필요한 정보를 아래처럼 정리해 둡니다.

• 무슨 프로젝트인지
• 설정하고 설치하는 방법
• 사용법과 실행 결과에 대한 예제
• 프로젝트의 라이센스
• 기여하는 방법

GitHub는 README 파일을 렌더링하는 것이기 때문에,

이미지나 외부 링크를 적어도 됩니다.

 

 

 

 

CONTRIBUTING

GitHub는 CONTRIBUTING 파일도 인식합니다.

README와 마찬가지로 원하는 파일 형식을 사용하면 됩니다.

Pull Request를 열 때 이 파일이 있으면

아래와 같이 링크를 보여줍니다.

상단에 CONTRIBUTING 파일이 있음을 보여준다.

 

이 파일에는 프로젝트에 기여하는 방법과

Pull Request 규칙 같은 것을 적습니다.

그러면 사람들이 Pull Request를 열 때 이 가이드라인을 참고할 수 있습니다.

 

 

 

 

 

[다음 포스트]

[GitHub] 프로젝트 관리자가 여러 명일 때 - Organization 관리하기

 

 

 

 

Ref.

Git - GitHub 프로젝트 관리하기