1. 개요
GitHub RepositoryGit 호스팅 서비스인 GitHub의 핵심 서비스 중 하나인 저장소 및 관련 기능들.
2. 종류
크게 공개(public) 저장소와 비공개(private) 저장소로 나뉜다. 공개 저장소는 대부분의 action 사용 시간 제한 등 혜택이 있지만, 모든 소스가 온라인에 공개된다. 따라서 오픈 소스에는 최적화되어 있지만, 민감한 정보를 올리거나 사내 프로젝트를 진행하는 데에는 무리가 있다. 실제로 공식 API를 통해 GitHub에 올라가는 모든 코드를 매 순간 실시간으로 긁는 봇들이 널려 있기 때문에 실수를 알아채고 force push를 사용한다 해도 그 찰나의 순간 사이에 민감한 정보가 노출되는 경우도 있다.때문에 공개되면 안 되는 데이터가 포함되어 있거나 소규모 협업을 할 때는 비공개 저장소를 사용할 수 있다. Microsoft의 인수 이후 무료 사용자도 개인 비공개 저장소 생성 갯수가 무제한으로 늘어나 일반적인 경우 제약은 거의 없는 편. 대신 별도의 조직을 만들거나 액션을 자주 돌리거나 할 때는 무료 요금제로는 부족한 경우도 발생하게 된다.
3. 소유자와 이름
일반적인 저장소는 개별 유저 소유(personal) 또는 조직 소유(organization) 둘 중 하나에 해당한다. 둘 중 무엇이든 해당 저장소를 소유하고 있는 주체를 소유자(owner)라고 하며, url이<소유자>/<저장소> 형태로 만들어진다. 예를 들어 GitHub 공식 조직인 github가 소유하고 있는 공식 .gitignore 파일 저장소인 gitignore의 전체 주소는 github/gitignore가 된다.권한만 있다면 개인 소유 저장소를 조직 소유로 옮길 수도 있고, 그 반대도 가능하다. 이름이 바뀌게 되면 그전의 이름은 현재 주소로 자동으로 리다이렉트된다.
4. fork
원본 저장소를 포크해 히스토리를 전부 복사한 저장소를 만들 수 있다. 포크한 저장소를 fork repository, 포크된 저장소를 upstream repository라고 부른다. 포크한 저장소는 이름 아래에 표시되며, 원본 저장소의/forks에도 역링크가 생긴다.흔히 오해되곤 하지만, 포크는 Git 자체에 내장된 기능은 아니다. fork가 단순한 clone과 다른 이유는 PR의 remote_ref 종속성 때문이며, 그 외에도 branch protection rule등을 업스트림에서 상속하도록 강제하는 등 GitHub 내에서 몇몇 차이가 있다. 실제로 GitHub의 fork는 hard clone이 아니라 업스트림 tree의 가벼운 참조로 구현되어 있다. 이 외에도 upstream의 변경사항을 쉽게 sync할 수 있는 기능을 지원한다는 차이점이 있다.
fork가 영구적인 것은 아니기 때문에, 원한다면 포크 저장소가 공개 저장소인 경우에 한해 업스트림의 fork network에서 수동으로 분리(detach)하는 것이 가능하다.
5. 구조
5.1. 코드
sourcehut등 타 Git 호스팅 서비스와 다르게 소스 코드 디렉토리가 저장소 페이지 맨 위에 바로 보여진다. 이 때문에 C나 Go처럼 루트 폴더 하위에 소스를 늘어놓는 성향의 언어일 경우 리드미까지의 스크롤이 매우 길어질 수 있다.기본적으로 디렉토리 메뉴는 아이템명과 최신 커밋 메세지, 수정 시각이 표시되고, 디렉토리를 클릭하면 cd한다. 상단 또는 좌상단의 검색창으로 파일명 fuzzy search를 할 수 있지만 속도가 좋지는 않기에 자주 해야 한다면 클론이 편하다. code search와는 달라서, 파일 내용으로 검색하는 것은 불가능하다.
파일명을 클릭하면 소스 파일일 경우 코드를 보여준다. 소스가 아니더라도 대부분의 이미지 파일이나 PDF 등의 미디어 파일 렌더링을 자체적으로 지원하고, 지원되는 마크업 파일일 경우 렌더해서 보여준다. 소스의 경우 linguist 및 Tree-sitter 기반으로 구문 강조를 지원하며, Tree-sitter의 경우 심볼 테이블도 표시된다.
좌측 상단의 탭에서 해당 소스의 blame을 볼 수 있다. 소스가 아닌 미디어 파일의 경우도 blob url을
/blame/<ref>/<path>로 강제로 바꾸면 볼 수는 있다. raw버튼을 누르면 해당 blob의 내용을 웹 서버에서 그대로 서빙하며, raw.githubusercontent.com이라는 별도의 도메인을 사용한다. 이를 이용하면 github pages를 쓰지 않아도 아주 간단한 정적 웹 서버를 만들 수도 있다. 주로 wget이나 axel 등의 클라이언트로 다운로드하기 위한 url 생성용으로도 쓰인다. 대표적인 예시로 설치용 셸 스크립트를 소스에 넣고 그 raw url을 주는 n 등이 있다.line permalink는 행 번호를 클릭하고 쉬프트 클릭해 생성할 수 있다. 별도의 도메인은 아니고 목적 blob 링크에서 앵커로
#Lxx-Lyy 형식으로 주어진다. 해당 링크를 이슈 댓글 등에 붙혀넣으면 자동으로 임베딩되는 건 덤.5.1.1. README
마크업 언어에 따라README.md, README.rdoc, README.asc 등 README라는 파일명을 사용할 경우, 해당 마크업을 렌더한 결과가 디렉토리에 바로 보여진다. 만약 해당 파일이 루트에 있을 경우, 저장소 페이지에 바로 보여지게 된다.5.2. 이슈
GitHub의 이슈 트래커. 협업 특히 오픈 소스 개발에서 필수적인 기능이기에 가장 중요한 기능 중 하나이다..github/ISSUE_TEMPLATE 하위에 간단한 이슈 양식을 넣거나 YAML 형식으로 간단한 form을 만들어 넣을 수 있다.기본적으로 크게 두 가지 상태가 있는데, open은 해결되지 않은 이슈, closed는 해결된 이슈를 뜻한다. PR시 #fixes syntax 등을 통해 연관된 이슈를 자동으로 열고 닫을 수 있다. 이외에도 원하는 만큼 label을 만들거나 붙힐 수 있다. 큰 프로젝트의 경우 action을 돌려서 자동으로 라벨을 붙히거나 관리하기도 하는 편.
이슈가 열렸다 닫히기도 하고, 버그가 고쳐지지 않은 것이 확인되어 또 다시 열리기도 한다. 잘못된 태그를 고치거나 담당자를 바꾸거기도 하며 이러한 모든 과정을 시간순으로 전부 기록한 것을 이슈 히스토리라고 한다. 이슈가 닫힌 상태에서도 댓글을 남길 수 있기에 자신이 겪고 있는 버그가 이미 닫힌 이슈라면 문제를 제기할 수도 있다. 무수히 많은 +1 댓글을 보고 메인테이너가 화내는 장면은 덤. 이러한 일을 막기 위해서 메인테이너 권한으로 이슈 자체를 잠글(lock) 수도 있는데, 주로 방기(stale)된 이슈를 자동으로 잠그도록 action을 설정한다. 여담으로 이슈 상태가 바뀐 히스토리뿐 아니라 개별 이슈 댓글의 역사를 확인할 수도 있다.
이슈가 하나 새로 생길 때마다 이슈 번호가 증가하는데, 보통 이 번호를 식별자로 사용한다. PR과 같은 식별 체계를 사용하기 때문에 번호가 같은 이슈와 PR은 없다. 이슈나 PR 댓글 입력창에서 #을 누르면 자동완성이 뜨는데, 여기서 기존 이슈나 PR들을 mention할 수 있다. 역으로 mention된 이슈 히스토리에도 역링크가 추가된다.
이슈 댓글에서는 통상적인 GFM에 더해 issue tag, gist embed, line permalink embed, issue group, hex color literal 등의 문법도 지원된다. 코드 뷰어의 마크다운 렌더러와는 구현이 아주 미세하게 다르다. 이외에도 이슈 댓글에 이모지로 반응을 달 수 있다.
마일스톤은 조금 더 큰 이슈의 단위로, jira나 타 이슈 트래커의 에픽 또는 그 이상급의 청크에 대응한다.
5.3. PR
GitHub 워크플로우의 꽃. 풀 요청(pull request)의 약자로 수정한 내역의 커밋을 원 브랜치에 반영하기 위한 요청을 말한다.헷갈릴 수 있지만 base branch는 수정을 시작하기 전 상태를, head branch는 수정을 완료한 상태를 의미한다. 여기서 기존 base와의 병합 충돌이 있다면 수동으로 rebase를 진행해야 한다. base와 head branch가 꼭 같은 리모트에 있을 필요는 없다. 필요하다면 다른 저장소의 브랜치와도 병합이 가능하고, 실제로 fork 기여의 경우 대부분 이 방식으로 진행된다.
이슈와 대부분의 체계를 공유하지만 수정된 내용을 직접 볼 수 있고 여기에 code review를 진행할 수도 있다. 코드블럭에
```suggestion을 사용하면 수정사항을 바로 제안할 수 있으며, 이 경우 리뷰가 훨씬 쉬워진다. 이해가 안 되는 경우 해당 리뷰 서브스레드에서 대화가 더 오가기도 한다. 확인이 끝난 개별 리뷰는 자동으로 접혀서 PR 히스토리 확인을 쉽게 만든다.큰 기능을 추가하거나 대대적인 리팩토링을 준비하는 경우, PR을 신중히 준비하기 위해 draft PR을 생성할 수 있다. 일반 PR과의 차이점은 단순히 머지가 안 되는 것뿐이며, 언제든지 draft와 ready 상태를 오갈 수 있다.
5.4. 액션
5.5. 위키
gollum 기반의 위키. Git과 PR 기반의 위키 서비스일 것 같지만 일반적인 위키위키와 크게 다르지 않다. 저장소가 별도로 분리되어 있기에 vscode의 예와 같이 PR 기반의 운용을 하는 것이 불가능하진 않다.5.6. stargazer
일명 깃허브 스타. 관심이 있는 저장소를 표시할 수 있는, 일반적인 SNS 서비스의 좋아요 또는 즐겨찾기 기능과 유사하지만 오픈소스 정신에 민감한 개발자들은 스타 수에 오픈소스 이념적 의미를 부여하기도 한다. 이는 공식에서도 어느 정도 인정하는 상징으로, 저장소를 private으로 전환하면 그동안 모은 스타가 전부 날아가는 것이 예시.[1] 실제로 유명 Python 오픈소스인 httpie의 메인테이너가 실수로 저장소를 비공개로 전환했다가 5만개에 가까운 스타를 날린 적도 있다.How we lost 54k GitHub stars실제 trending 순위 집계에 반영되는 지표이기도 하고, 누군가는 스타를 좋아요로 여기는 반면 누군가는 스타를 오픈소스의 신성한 의사표결권 쯤으로 간주하기도 해 오픈소스 커뮤니티에서 가끔 이를 주제로 의견 충둘이 일어나기도 한다. 다만 어느 쪽이건 개발자와 아무 관련이 없는 어뷰징만큼은 결코 용납하지 않는다.
이 주소에서 자신이 스타를 누른 모든 저장소를 확인할 수 있다.
6. GitHub Trends
See what the GitHub community is most excited about today.#
최근, 또는 특정 기간 동안 GitHub 내에서 관심이 급격히 증가한 저장소들의 리더보드 서비스. 일종의 깃헙판 실시간 검색어라고 할 수 있다. 트렌드 집계 알고리즘이 공개된 적은 없지만, 상술할 star 증감률에 기반하는 것으로 보인다.
일간, 주간, 월간으로 총 3개의 범위가 존재하는데, 집계 기간을 줄일수록 잘 알려진 거대 프로젝트 뿐 아니라 듣도 보도 못한 신박한 프로젝트를 발견할 확률이 높아진다.
2022년쯤 저조한 이용율로 사라질 뻔했으나 많은 반대로 현재까지 계속 운영 중이다.#
7. 기상천외한 저장소들
오픈 소스 프로젝트라면 뭐든 올릴 수 있기 때문에 프로그램, 코딩 관련이 아닌 가끔 괴상한 것들이 올라오기도 한다.- 세계 굴지의 미니어처 게임 회사인 게임즈 워크숍도 인증된 깃허브 페이지가 존재한다. 공개 리포지토리가 얼마 없는 것으로 보아 대부분의 리포지토리는 비공개인 것으로 보인다.
- 케모노 프렌즈 애니메이션의 대사집도 공개되어 있다.
KADOKAWA: ?? - 레진코믹스에서 취업 공고를 GitHub에 올리기도 하였다.
- 非컴퓨터 공학 리포지터리 중에서 가장 압권인 건 집안일 관리용 이슈 트래커(...). README 파일이 가관이다. 'My house has no source code, so I only use the issue tracker.' 이 리포지터리는 2012년 12월 말에 트렌드 1위로 등극하기도 했다! 2018년 10월 현재 상태로 저 리포지터리는 사라진 상태. 하지만 이 리포지터리에 영감을 얻은 여러 사용자들이 비슷한 집안일 관리용 리포지터리를 만들었다. 1, 2, 3 이 외에도 상당히 많은 리포지터리들이 존재한다. 원조와 다른 점은 소스 코드를 가지고 있다는 것 정도.
- 아폴로 11호에 사용된 가이던스 컴퓨터의 소스 코드가 공개되었다.
- 페르시아의 왕자 오리지널 버전 소스 코드. 공개자는 제작자인 조던 메크너 본인. 워낙 예전 소스라 자기도 기억 안 나니까 궁금한 거 있어도 묻지 말라고 써 놨다. 더군다나 사용 언어는 애플 II 어셈블리어(...). 추가로 굉장히 많은 언어 사용이 감지되는데, 확장자로 인한 것으로 어셈블리로 작성된 프로그램이 맞다.
- 엔하위키[2] 미러[3]가 통째로 저장되어 있기도 하다.
GitHub에서 위키질을 할 수가 있다편집을 못 한다PR을 일일이 보내야 한다 - 페이스북의 인공지능 바둑 프로그램인 다크포레스트도 공개되어 있다.
- 심지어 MS-DOS 1.25와 2.0, 4.0의 소스 코드도 공개되어 있다!
8. 기타
- https://github.com/new 주소에서 바로 새 저장소를 생성할 수 있다. 알아두면 편리한 팁.