GitHub Foundations #3 Domain 2: 저장소 다루기 — 브랜치·태그·릴리스·gist
Domain 2는 GitHub 작업의 기본 단위인 저장소(repository) 를 다룹니다. 만들고, 구성 파일을 갖추고, 복사하고, 공개 범위를 정하고, 수명을 관리하는 전 과정이 범위입니다. 개념 자체는 어렵지 않지만 비슷해 보이는 기능의 구분(fork와 clone, 태그와 릴리스)을 정확히 묻기 때문에, 이번 글은 그 경계를 중심으로 정리합니다.
저장소 만들기와 초기화 옵션 #
웹에서 New repository로 저장소를 만들 때 정하는 것은 세 가지입니다. 이름과 설명, 가시성(공개 범위), 그리고 초기화 옵션입니다. 초기화 옵션 세 가지는 각각 파일 하나를 첫 커밋에 넣어 줍니다.
- README — 저장소 첫 화면에 렌더링되는 소개 문서입니다.
- .gitignore — 언어별 템플릿(Python, Node 등)에서 골라 추적 제외 규칙을 미리 깔아 줍니다.
- LICENSE — 코드의 사용 조건을 밝히는 라이선스 파일입니다. 공개 저장소에서 라이선스가 없으면 법적으로는 타인이 쓸 수 없는 코드가 된다는 점이 출제되기도 합니다.
커뮤니티 파일 — 정해진 이름의 특수 파일 #
GitHub는 정해진 이름의 파일을 특별하게 취급합니다. 시험에서는 “이 정보를 어디에 두는가"의 형태로 묻습니다.
| 파일 | 역할 |
|---|---|
README.md | 프로젝트 소개. 저장소 첫 화면에 표시 |
LICENSE | 사용 조건. 라이선스 뱃지와 안내에 반영 |
CONTRIBUTING.md | 기여 절차 안내. Issue와 PR 작성 화면에 링크 노출 |
CODE_OF_CONDUCT.md | 커뮤니티 행동 규범 |
SECURITY.md | 취약점 신고 창구 안내 |
.github/ 디렉터리 | Issue·PR 템플릿, 워크플로 등 GitHub 설정 파일의 위치 |
개인 계정 이름과 같은 이름의 저장소에 README를 두면 프로필 페이지에 표시되는 프로필 README 기능도 Domain 2에서 언급되는 항목입니다.
default branch — 저장소의 기준 브랜치 #
저장소에는 기준이 되는 브랜치가 하나 있습니다. 새로 clone하면 체크아웃되는 브랜치이고, PR을 열 때 기본 base가 되는 브랜치입니다. 현재 기본 이름은 main이며, 저장소 설정에서 다른 브랜치로 바꿀 수 있습니다. 브랜치에 강제 규칙을 거는 보호 기능은 Domain 6에서 다루므로 여기서는 이름과 역할만 잡아 두면 됩니다.
태그와 릴리스 — 같은 지점, 다른 층 #
Domain 2의 대표 구분입니다.
- 태그(tag) — 특정 커밋에 붙이는 이름표로, Git의 기능입니다.
v1.2.0처럼 버전을 표시하는 데 쓰입니다. - 릴리스(release) — 태그를 기반으로 릴리스 노트와 빌드 산출물(에셋)을 함께 배포하는 GitHub의 기능입니다. 다운로드 페이지가 만들어지고, 소스 코드 아카이브가 자동으로 첨부됩니다.
즉 릴리스는 태그 없이 존재할 수 없고(만들 때 새 태그를 만들 수도 있습니다), 태그는 릴리스 없이도 존재합니다. “바이너리 파일을 사용자에게 배포하려면 무엇을 쓰는가?“라는 문항의 답은 릴리스입니다.
gist — 저장소보다 가벼운 코드 조각 공유 #
파일 몇 개짜리 코드 조각을 공유할 때는 저장소 대신 gist를 씁니다. 두 종류가 있습니다.
- public gist — 검색과 발견 페이지에 노출됩니다.
- secret gist — 검색에는 노출되지 않지만, URL을 아는 사람은 누구나 볼 수 있습니다. 비공개 저장소 같은 접근 통제가 아니라는 점이 출제 포인트입니다.
gist도 내부적으로는 Git 저장소라서 clone하고 버전을 관리할 수 있습니다.
fork, clone, 템플릿 저장소 — 세 가지 복사의 차이 #
Domain 2에서 가장 자주 나오는 구분입니다. 셋 다 “저장소를 복사한다"로 보이지만 방향과 연결이 다릅니다.
| 방식 | 복사 방향 | 원본과의 연결 | 대표 용도 |
|---|---|---|---|
| fork | GitHub 계정 → 내 GitHub 계정 | 유지됨 (원본으로 PR 가능) | 권한 없는 오픈소스에 기여 |
| clone | GitHub → 내 컴퓨터 | 원격(origin)으로 연결 | 로컬에서 작업 |
| 템플릿 저장소 | GitHub → 새 저장소 | 없음 (히스토리도 새로 시작) | 보일러플레이트로 새 프로젝트 시작 |
시나리오형 문항으로 출제됩니다. “쓰기 권한이 없는 프로젝트에 수정을 제안하려면?“은 fork 후 PR이고, “팀 표준 구조로 새 프로젝트를 시작하려면?“은 템플릿 저장소입니다. fork는 서버에서 서버로의 복사라서 fork만 해서는 내 컴퓨터에 아무것도 내려오지 않는다는 점, 작업하려면 fork본을 다시 clone해야 한다는 점도 함께 기억해 두기 바랍니다.
저장소 가시성 — public, private, internal #
- public — 인터넷의 누구나 읽을 수 있습니다. 쓰기는 별개의 권한입니다.
- private — 초대된 협업자와 권한을 받은 팀만 접근합니다.
- internal — Enterprise 전용으로, 같은 기업 구성원 전체에게만 보입니다. 조직 내부 공유(InnerSource)에 쓰입니다.
“기업 구성원 모두에게는 열고 외부에는 닫는다"는 시나리오가 나오면 internal입니다. Enterprise 플랜에서만 가능하다는 조건까지가 한 묶음의 출제 포인트입니다.
토픽, 스타, 워치 — 저장소의 발견과 구독 #
저장소를 찾고 따라가는 기능도 Domain 2의 범위입니다. 세 기능의 역할 구분이 출제 포인트입니다.
- 토픽(topic) — 저장소에 붙이는 분류 키워드입니다.
machine-learning,hugo처럼 주제를 선언해 두면 토픽 검색으로 저장소가 발견됩니다. 태그(커밋의 이름표)와 이름이 비슷하지만 완전히 다른 기능입니다. - 스타(star) — 관심 표시이자 북마크입니다. 스타 목록에서 다시 찾을 수 있고, 저장소의 스타 수는 인지도의 지표로 읽힙니다. 스타를 눌러도 알림은 오지 않습니다.
- 워치(watch) — 알림 구독입니다. 워치한 저장소의 Issue, PR, 릴리스 활동이 알림으로 들어옵니다. 전체 활동, 릴리스만, 멘션만처럼 구독 범위를 고를 수 있습니다.
“저장소의 새 릴리스 소식만 받고 싶다"는 시나리오의 답은 스타가 아니라 워치(릴리스만)입니다. 스타는 기억하기 위한 기능이고 워치는 알림을 받기 위한 기능이라는 한 줄 구분이면 충분합니다.
아카이브, 삭제, 이전 — 저장소의 수명 관리 #
- 아카이브(archive) — 저장소를 읽기 전용으로 전환합니다. Issue, PR, push가 모두 잠기고 첫 화면에 아카이브 안내가 표시됩니다. 유지보수가 끝난 프로젝트를 지우지 않고 보존하는 방법이며, 언제든 해제할 수 있습니다.
- 삭제(delete) — 저장소를 제거합니다. 삭제 직후 일정 기간은 복구할 수 있지만 기본적으로 되돌릴 수 없는 작업으로 간주하고, 보존이 목적이라면 아카이브를 쓰는 것이 정답 방향입니다.
- 이전(transfer) — 저장소 소유권을 다른 계정이나 Organization으로 옮깁니다. 옮긴 뒤에도 옛 URL로의 접근이 새 위치로 리다이렉트됩니다.
마무리 #
이번 글의 핵심은 세 가지입니다.
- 저장소는 README, LICENSE, CONTRIBUTING 같은 정해진 이름의 커뮤니티 파일로 안내 체계를 갖추고,
.github/디렉터리에 템플릿과 설정을 둡니다. - 태그는 커밋의 이름표(Git), 릴리스는 배포 페이지(GitHub)이며, fork·clone·템플릿은 복사 방향과 원본 연결로 구분합니다.
- 가시성은 public, private, internal 세 단계이고 internal은 Enterprise 전용입니다.
다음 글인 “GitHub Foundations #4 Domain 3-1: 협업 — Issue·라벨·마일스톤·템플릿"부터는 시험 비중이 가장 큰 협업 기능으로 들어갑니다. Issue를 중심으로 한 작업 관리 기능을 먼저 정리하겠습니다.