6. GitHub - ProGit |
-
GitHub은 가장 큰 git 저장소 호스트이다.
6.1. 계정 만들고 설정하기
* SSH 사용하기
-
https:// 프로토콜로도 git 저장소를 사용하는데 부족함이 없다.
간단히 사용자 이름과 암호로 인증만 하면 된다.
공개 프로젝트를 clone 하는 데는 인증도 필요 없다.
그러나 프로젝트를 fork 하고 그 프로젝트에 push 할 때면 SSH 가 필요하다.
-
SSH 리모트를 쓰려면 공개키를 설정해야 한다.
* 아바타
* 사용자 이메일 주소
* 투팩터 인증 (Two Factor Authentication)
-
2FA 는 최근 들어 인기가 높아지는 인증 매커니즘이다.
암호를 도둑맞았을 때 위험을 완화하기 위해 사용한다.
인증 수단을 2가지 사용하며, 둘 중 한 가지 방법만 뚫어서는 공격자가 계정에 접근할 수 없다.
6.2. GitHub 프로젝트에 기여하기
* 프로젝트 Fork 하기
-
과거에는 fork 가 오픈 소스 프로젝트를 복사해서 조금은 다른 프로젝트를 만드는 것을 의미했고, 때때로 원래 프로젝트와 경쟁하거나 기여자를 나누는 결과를 가져오기도 했다.
* GitHub 플로
-
GitHub 은 Pull Request 가 중심인 협업 워크플로를 위주로 설계됐다.
이 워크플로는 fork 해서 프로젝트에 기여하는 것이다.
다음과 같이 작동한다.
1. master 에서 토픽 브랜치를 만든다.
2. 뭔가 수정해서 커밋한다.
3. 자신의 GitHub 프로젝트에 브랜치를 push 한다.
4. GitHub 에 Pull Request 를 연다.
5. 토론하면서 그에 따라 계속 커밋한다.
6. 프로젝트 소유자는 Pull Request 를 Merge 하고 닫는다.
이는 integration-manager 워크플로와 같다.
토론이나 리뷰를 이메일이 아니라 깃헙에서 제공하는 웹 기반 도구를 사용하는 것 뿐이다.
* Pull Request 만들기
-
Pull Request 가 오면 프로젝트 소유자는 변경점이 무엇인지 확인한 후, 머지 혹은 거절하거나 코멘트를 달 수 있다.
누구나 Pull Request 에 코멘트를 달 수 있다.
-
한 저장소의 두 브랜치를 두고도 Pull Request 를 열 수 있다.
한 저장소에 쓰기 권한이 있는 동료 둘이서 어떤 기능을 추가하려고 하면 토픽 브랜치를 만들고 push 한다.
그리고 나서 같은 저장소의 master 브랜치에 대해 Pull Request 를 만들어 코드 리뷰와 토론을 시작한다.
Fork 는 필수가 아니다.
* Pull Request 팁
* Markdown
-
- [X] Option1
- [ ] Option2
위의 방식으로 테스크 리스트와 check 상태를 표기할 수 있다.
-
``` code ``` 로 코드를 표시할 수도 있다.
-
> citing 으로 인용할 수 있다.
-
: 문자로 입력을 시작해서 이모지를 넣을 수도 있다.
:<emoji_name>: 형태가 이모지다.
-
drag-and-drop 으로 이미지를 붙여넣을 수도 있다.
6.3. GitHub 프로젝트 관리하기
* 새 저장소 만들기
-
GitHub 계정 없이 clone 할 수 있기 때문에 공개 프로젝트를 공유할 때는 SSH 보다 HTTP URL 을 더 많이 공유한다.
SSH URL 을 사용하려면 계정도 있어야 하고 SSH 키도 GitHub 에 등록해야 한다.
* 동료 추가하기
-
저장소에 커밋 권한을 주고 싶은 동료가 있다면 Collaborator 로 추가해야 한다.
* Pull Request 관리하기
-
git pull url branch_name 을 통해서 저장소를 리모트로 추가하지 않고 간단히 해당 브랜치를 가져올 수 있다.
$ git pull <remote_url> <branch_name>
-
다음과 같이 머지할 수도 있다.
$ curl patch_file_url | git am
-
GitHub 는 Pull Request 의 브랜치를 서버에 있는 가상 브랜치로 노출해준다.
GitHub 이 자동으로 해주기 때문에 바로 이용하면 된다.
이걸 해보려면 저수준(plumbing) 명령어인 ls-remote 가 필요하다.
이 명령어는 서버에 어떤 Ref 가 있는지 보여준다.
저장소 브랜치 뿐만 아니라 태그 등 온갖 Ref 를 보여준다.
-
GitHub 저장소에 어떤 Pull Request 라도 열려있다면 refs/pull/ 로 시작하는 이름으로 Ref 가 생성된다.
이것도 브랜치지만 refs/heads/ 로 시작하는 브랜치와는 달리 clone 과 fetch 할 때 받아들여지지 않는다.
기본적으로 무시된다.
-
Pull Request 에는 두 종류의 Ref 가 있다.
/head 로 끝나는 것은 Pull Request 브랜치가 가리키는 마지막 커밋이다.
누군가 우리 저장소에 bug-fix 라는 브랜치를 pull request 로 보내왔으며, 그 브랜치는 a5a775 커밋을 가리킨다면..
a5a775 를 가리키는 refs/pull/<pr#>/head 형식의 브랜치가 자동으로 생긴다.
그래서 매번 다른 저장소를 리모트로 등록하지 않고서도 pull request 브랜치를 쉽게 pull 할 수 있다.
.git/config 파일을 열어서 origin 리모트를 찾으면 fetch 항목이 있다.
fetch =. 로 시작하는 라인이 refspec. 인데, 리모트 이름과 로컬 .git 디렉토리를 어떻게 매핑하는지 나타낸다.
-
pull request 를 머지할 브랜치는 master 가 아니어도 된다.
주 브랜치를 고를 수도 있고, pull request 를 열 때 다른 브랜치를 골라도 된다.
심지어 pull request 에 pull request 를 보낼 수 있다.
-
착착 잘 진행하는 어떤 pull request 가 있는데 거기에 뭔가 아이디어를 더하고 싶다면, 이럴 때 pull request 에 pull request 를 보낼 수 있다.
* 맨션과 알림
-
@멘션 을 하면 해당 사용자에게 알림이 간다.
맨션으로 언급되면 그 사람은 구독 상태(Subscribed)가 된다.
-
해당 저장소를 Watching 하는 상태이거나, 코멘트를 단 경우에도 구독 상태가 된다.
더는 알림을 받고 싶지 않으면 화면의 Unsubscribe 버튼으로 끌 수 있다.
-
README 는 저장소 랜딩 페이지이다.
.md 이든 .asciidoc 이든 잘 랜더링 된다.
README 에는 주로 아래의 내용을 쓴다.
1. 무슨 프로젝트인지
2. 설정하고 설치하는 방법
3. 사용법과 실행결과에 대한 예제
4. 프로젝트의 라이선스
5. 기여하는 방법
* CONTRIBUTING
-
CONTRIBUTING 파일도 README 처럼 인식한다.
이 파일에는 프로젝트에 기여하는 방법과 Pull Request 규칙 같은 것을 적는다.
* 프로젝트 관리
-
기본 브랜치를 master 말고 다른 브랜치로 설정할 수 있다.
Pull Request 를 열 때 설정한 기본 브랜치가 기본으로 선책된다.
-
프로젝트 소유자를 다른 사용자나 Organization 으로 변경할 수 있다.
이 때 저장소만 옮겨지는 것이 아니라 Watching 하는 사람이나 Star 한 사람까지도 함께 옮겨진다.
그리고 URL 은 Redirect 되는데, 웹 뿐만 아니라 clone 이나 fetch 요청까지고 redirect 된다.
6.4. Organization 관리하기
-
Organization 계정은 개인 계정처럼 프로젝트 네임스페이스지만 다른 점이 많다.
이 계정은 여러 명이 같은 프로젝트를 관리하는 데 사용하는 그룹 계정이고 사람들을 서브 그룹으로 나누어 관리하는 도구도 있다.
* Organization 기초
* 팀
-
Organization 과 개인은 팀을 통해 연결된다.
Organization 의 사용자와 저장소는 팀으로 관리되고 저장소의 권한 설정도 팀으로 관리한다.
Organization 에서 팀은 저장소에서 함께 일하는 사람을 관리하는 효과적인 도구다.
팀은 권한을 가질 수 있는데, 저장소에 대해 읽기 전용, 읽고 쓰기, 관리 권한을 가질 수 있다.
* 감사(Audit) 로그
-
소유자는 Organization 에서 일어나는 모든 정보를 알 수 있다.
Audit Log 탭에 보면 저장소에서 일어난 일들의 로그가 있다.
6.5. GitHub 스크립팅
* 훅
-
서비스를 이용하여 CI, 버그 트래커, 이슈 트래커, 채팅, 문서 시스템 등등과 연동할 수 있다.
서비스는 다양한 이벤트를 처리할 수 있지만 보통은 push 할 때 그 데이터를 가지고 뭔가를 한다.
-
GitHub 서비스에 없는 사이트나 외부 서비스와 연동하고 싶거나 좀 더 세세한 설정을 하고 싶다면 GitHub 훅을 이용하면 된다.
GitHub 훅은 URL 을 설정해주면 그 URL 로 HTTP 페이로드를 보내준다.
훅 페이로드를 처리하는 간단한 웹 서비스를 하나 만들고 그 서비스에 원하는 동작을 구현하는 것이 일반적이다.
-
GitHub 은 누가 push 했는지, 어느 브랜치에 push 했는지, push 한 커밋에서 어떤 파일을 수정했는지에 대한 정보를 json 페이로드에 담아 보낸다.
* GitHub API
-
이벤트 정보를 좀 더 자세히 알고 싶거나 자동으로 동료를 추가하거나 이슈에 레이블을 달도록 하고 싶을 때 GitHub API 를 이용하면 된다.
이를 이용하면 웹 사이트에서 하는 웬만한 일은 자동화 할 수 있다.
ex)
$ curl https://api.github.com/users/schacon
-
이슈나 pull request 에 코멘트를 달거나 공개하지 않은 정보를 얻으려고 할 때는 인증이 필요하다.
사용자 이름과 암호가 필요한 basic 인증도 가능하지만, 개인 엑세스 토큰을 사용하는 게 낫다.
토큰은 허용하는 범위를 제한하기 쉽고 언제든지 폐기할 수 있어 좋다.
인증을 하면 API 사용 횟수도 늘어난다.
ex)
$ curl -H “Content-Type: application/json” -H “Authorization: token TOKEN” —data ‘{“body”:”A new comment, :+1:”}’ url
-
웹 사이트에서 할 수 있는 일은 전부 API 로도 할 수 있다.
마일스톤을 만들고 설정하기, 사람들에게 이슈나 pull request 할당하기, 레이블을 만들고 수정하기, 커밋 데이터 사용하기, 커밋을 하거나 브랜치 만들기, pull request 만들고 닫고 머지하기, 팀을 만들고 수정하기, pull request 코드에 코멘트하기, 사이트에서 검색하기 등등이 다 된다.
* Pull Request 의 상태 변경하기
-
대부분의 CI 나 테스팅 서비스들은 코드가 푸시되면 바로 테스트를 하고 나서 Pull Requeset 에 상태를 추가하거나 조회하는 API 를 사용한다.
예를 들어 코드를 보낸 사람이 제대로 가이드라인을 지켰는지, 커밋에 제대로 서명했는지, 커밋 메시지가 규칙에 맞게 작성됐는지를 리포트 할 수 있다.
-
커밋의 상태는 success, failure, error 일 수 있다.
커밋의 상태(state)와 설명(description), 자세한 정보를 확인할 수 있는 url(target_url), 상태를 구분하는 컨텍스트(context)를 함꼐 전송한다. (돼왕: 컨텍스트에는 어떤 검사? 검증? 을 했는지가 string 형태로 들어간다. 예를들면 illegal_commit_msg )
* Octokit
-
더 편리하게 API 를 사용할 수 있게 해주는 오픈 소스 lib 이 있다.
6.6. 요약
'프로그래밍 놀이터 > Tips' 카테고리의 다른 글
| [도서 정리] 7. Git 도구 #2 - ProGit (0) | 2020.01.12 |
|---|---|
| [도서 정리] 7. Git 도구 #1 - ProGit (0) | 2020.01.11 |
| [도서 정리] 5. 분산 환경에서의 Git - ProGit (0) | 2020.01.09 |
| [도서 정리] 4. Git 서버 - ProGit (0) | 2020.01.08 |
| [도서 정리] 3. Git 브랜치 - ProGit (0) | 2020.01.07 |
댓글