GitHub

GitHub 는 코드와 그 코드가 바뀐 기록을 인터넷에 올려 두고 여러 사람이 함께 고치게 해 주는 서비스입니다. 각자 자기 컴퓨터에서 고친 코드를 이곳에 올리고 남이 올린 코드를 받아 옵니다. 올리기 전에 동료가 바뀐 줄을 읽고 의견을 남기는 일도 이 사이트 위에서 합니다.

상세

GitHub 는 Git 저장소를 맡아 두는 웹 서비스입니다. 이 문서가 다루는 것은 이 서비스가 무엇을 맡아 주고 무엇을 덧붙이는지입니다. Git 과 GitHub 가 어떻게 갈리는지부터 봅니다.

Git 과 GitHub 는 다른 물건이다

Git 은 파일이 바뀐 이력을 남기는 프로그램입니다. 이렇게 이력을 남기고 되돌리는 일을 버전관리라고 부릅니다. Git 은 각자의 컴퓨터에 설치해서 씁니다.

Git 은 인터넷이 없어도 돕니다. 이력 전체가 내 컴퓨터 안의 저장소에 들어 있기 때문입니다. 저장소는 파일과 그 파일이 바뀐 기록을 함께 담은 폴더입니다.

GitHub 는 그 저장소를 인터넷의 서버에 하나 더 두게 해 줍니다. 여럿이 같은 서버의 저장소를 기준으로 받고 올리면 서로의 작업이 한곳에서 만납니다. Git 이 도구라면 GitHub 는 그 도구로 만든 저장소를 모아 두는 곳입니다.

원격 저장소를 맡아 둔다

내 컴퓨터 밖에 있는 저장소를 원격 저장소라고 부릅니다. GitHub 가 맡는 첫째 일이 이 원격 저장소를 보관하는 것입니다.

원격 저장소와 내 저장소를 오가는 것은 커밋입니다. 커밋은 한 번에 고친 묶음을 이력에 남긴 단위입니다. 이 커밋을 주고받는 동작이 셋 있습니다.

첫째는 클론입니다. 처음 저장소 전체를 받아 오는 것이 클론입니다. 한 번 받아 두면 그다음부터는 바뀐 커밋만 주고받습니다.

나머지 둘은 방향이 반대입니다. 내가 새로 만든 커밋을 올리는 것이 푸시입니다. 남이 올린 커밋을 받아 오는 것이 풀입니다.

git clone <저장소 주소>  # 한 벌을 받는다
git pull                # 남의 커밋을 받는다
git push                # 내 커밋을 올린다

세 줄 모두 Git 명령입니다. GitHub 는 이 명령이 오가는 상대편 서버일 뿐입니다. 그래서 명령을 외우는 것은 Git 을 배우는 일입니다. GitHub 를 쓴다는 것은 그 상대편을 이 서비스로 정한다는 뜻입니다.

flowchart TD
    subgraph S["GitHub 서버"]
        R["원격 저장소"]
    end
    subgraph A["개발자 A 의 컴퓨터"]
        LA["내 저장소"]
    end
    subgraph B["개발자 B 의 컴퓨터"]
        LB["내 저장소"]
    end
    LA -->|푸시| R
    R -->|풀| LB
    LB -->|푸시| R
    R -->|풀| LA

두 사람은 서로의 컴퓨터에 직접 닿지 않습니다. 둘 다 GitHub 의 원격 저장소하고만 주고받습니다.

풀 리퀘스트로 합치기 전에 읽는다

여럿이 한 저장소를 고칠 때는 보통 작업마다 브랜치를 따로 냅니다. 브랜치는 이력을 갈래로 나눠 두는 것입니다. 갈라 둔 브랜치에서 고치면 다른 사람의 작업을 건드리지 않습니다.

다 고친 브랜치는 기준 브랜치에 합쳐야 합니다. 이렇게 두 브랜치를 하나로 잇는 일이 병합입니다. 병합이 끝나면 기준 브랜치에 내 커밋이 들어갑니다.

GitHub 는 병합하기 전에 한 단계를 끼워 넣습니다. 그 단계가 풀 리퀘스트입니다. 풀 리퀘스트는 「내 브랜치를 기준 브랜치에 합쳐 달라」는 요청을 웹 페이지 하나로 만든 것입니다. 이름의 「풀」은 앞의 풀과 같은 말입니다. 저장소를 맡은 쪽에게 내 브랜치를 받아 가서(풀) 합쳐 달라고 청한다는 뜻입니다.

풀 리퀘스트 페이지에는 바뀐 줄이 모여 보입니다. 동료는 줄마다 의견을 달 수 있습니다. 이렇게 남의 코드를 읽고 의견을 주는 일이 코드 리뷰입니다. 병합 전에 한 사람이라도 더 읽게 하려고 이 단계를 둡니다.

sequenceDiagram
    participant 작성자
    participant GitHub
    participant 리뷰어
    작성자->>GitHub: 작업 브랜치를 푸시한다
    작성자->>GitHub: 풀 리퀘스트를 연다
    GitHub->>리뷰어: 바뀐 줄을 보여 준다
    리뷰어->>GitHub: 줄마다 의견을 남긴다
    Note over 작성자,리뷰어: 고칠 것이 있으면 작성자가 다시 푸시하고 되풀이한다
    리뷰어->>GitHub: 승인한다
    GitHub->>GitHub: 기준 브랜치에 병합한다

그림은 한 번의 풀 리퀘스트가 지나가는 순서입니다. 의견이 오가는 동안 병합은 일어나지 않습니다. 그래서 누구의 코드도 남이 한 번 읽기 전에는 기준 브랜치에 들어가지 않게 만들 수 있습니다.

권한이 없는 저장소에는 포크로 기여한다

남의 공개 저장소에는 보통 푸시할 권한이 없습니다. 그래도 고친 것을 보내고 싶을 때 쓰는 것이 포크입니다. 포크는 남의 저장소를 내 계정 아래로 한 벌 복사해 오는 일입니다.

복사해 온 저장소는 내 것이라 마음대로 푸시할 수 있습니다. 거기서 고친 뒤 원래 저장소에 풀 리퀘스트를 엽니다. 원래 저장소의 관리자가 읽고 받아들이면 병합됩니다.

오픈 소스 프로젝트가 모르는 사람의 기여를 받는 흔한 길이 이것입니다. MDN(Mozilla Developer Network, 모질라의 웹 개발 문서 사이트) 의 문서도 이렇게 GitHub 저장소에 풀 리퀘스트를 올려서 고칩니다.

코드 곁에 붙는 협업 도구

GitHub 는 저장소 옆에 일을 굴리는 도구를 더 붙여 둡니다. 코드와 같은 페이지에서 쓰기 때문에 따로 도구를 들이지 않아도 됩니다.

이슈는 할 일 목록입니다. 풀 리퀘스트 설명에 이슈 번호를 적어 두면 어느 고침이 어느 문제를 풀었는지 이어서 볼 수 있습니다.

코드가 올라올 때마다 빌드와 테스트를 자동으로 돌려 깨진 것을 일찍 찾는 일을 지속적 통합이라고 합니다. 사람이 매번 테스트를 돌리면 빠뜨리기 쉬워서 기계에 맡깁니다.

GitHub Actions는 GitHub 안에서 이 일을 하는 기능입니다. 풀 리퀘스트 페이지에 그 결과가 함께 뜹니다. 리뷰어는 테스트가 통과했는지 먼저 보고 코드를 읽습니다.

웹훅은 GitHub 가 다른 서버를 불러 주는 방식입니다. 푸시가 들어왔다는 소식을 배포 서버나 채팅 서비스에 넘길 때 씁니다.

공개 저장소와 비공개 저장소

저장소는 공개와 비공개로 나뉩니다. 공개 저장소는 누구나 읽고 클론할 수 있습니다. 비공개 저장소는 권한을 받은 사람만 봅니다.

회사 코드는 대개 비공개로 둡니다. 여러 저장소와 사람을 한데 묶어 관리하려고 조직 계정을 만들고 그 아래에 저장소를 둡니다.

누구인지 밝히는 방법

푸시처럼 저장소를 바꾸는 동작은 누가 하는지 GitHub 가 알아야 합니다. 그래서 명령줄에서 GitHub 에 닿을 때 인증을 거칩니다.

쓰는 길은 둘입니다. 첫째는 SSH(Secure Shell, 보안 원격 접속) 키입니다. SSH 키는 두 개가 한 쌍입니다. 남에게 보여도 되는 공개 키와 내 컴퓨터에만 두는 개인 키입니다. 공개 키를 GitHub 계정에 등록해 두면, 짝이 맞는 개인 키를 가진 내 컴퓨터가 비밀번호 없이 푸시합니다.

둘째는 액세스 토큰입니다. 비밀번호 대신 쓰는 긴 문자열입니다. 발급할 때 할 수 있는 일을 좁혀 둡니다. 새어 나가도 피해가 그 범위 안에 머물게 하려는 것입니다.

토큰은 비밀번호와 같은 무게를 가집니다. 코드 안에 적어 올리면 그 저장소를 읽는 누구나 내 권한으로 움직일 수 있습니다. 그래서 토큰 같은 값은 코드 밖에 따로 보관합니다. 이런 비밀 값을 코드와 떼어 안전하게 보관하고 필요한 곳에만 넘기는 일을 시크릿 관리라고 합니다.

쓰지 않는 때

혼자 한 컴퓨터에서만 작업하면 GitHub 가 없어도 됩니다. Git 만으로 이력을 남기고 되돌릴 수 있습니다. 다만 그 컴퓨터가 망가지면 이력도 함께 사라집니다.

코드를 회사 밖 서버에 두면 안 되는 곳도 있습니다. 그때는 회사 서버에 직접 설치하는 제품을 씁니다. GitHub 에도 설치형 버전이 있습니다. GitLab 처럼 직접 설치해 운영하는 경쟁 제품도 있습니다.

GitHub 를 쓰면 일의 흐름이 한 서비스에 걸립니다. 서비스가 멈추면 푸시도 리뷰도 자동 테스트도 함께 멈춥니다. 내 컴퓨터의 Git 이력은 남아 있어서 코드를 잃지는 않습니다. 다만 팀이 합치는 일은 서비스가 돌아올 때까지 기다려야 합니다.

관련 항목

GitHub 가 맡아 주는 버전관리 도구와 단위

Git · 버전관리 · 저장소 · 원격 저장소 · 커밋 · 브랜치 · 태그

원격 저장소와 주고받는 Git 동작

클론 · 푸시 · 풀 · 페치 · 병합 · 리베이스 · 충돌 해소

GitHub 위에서 굴러가는 협업 방식

풀 리퀘스트 · 코드 리뷰 · 포크 · 이슈 · 브랜치 전략 · 오픈 소스

GitHub 에 붙어 도는 자동화 기능

GitHub Actions · 지속적 통합 · 지속적 배포 · 웹훅 · 워크플로 · 자동화

GitHub 에 접근할 때 거치는 인증 수단

인증 · 인가 · SSH · 액세스 토큰 · 시크릿 관리 · 접근 제어

같은 역할을 두고 겨루는 저장소 호스팅 서비스

GitLab · Bitbucket · Gitea · Azure DevOps

GitHub 에 원본 저장소를 두는 프로젝트

MDN · Kubernetes · React · Rails