내가 첫 GitHub 릴리스를 배포한 방법 (그리고 배운 점)

Source: Dev.to

Git와 함께한 나의 여정

소프트웨어 개발과 나는 절대 친한 친구가 아니었다 — 그래서 오랫동안 깊게 파고들지 않으려 했던 이유이기도 하다. 주니어 IT 전문가가 되기 위해 노력하면서, 이제는 살아남기 위해 최소한의 명령만 외우는 것이 아니라 Git을 제대로 배우려고 스스로를 강요하고 있다.

roadmap.sh Git & GitHub 로드맵을 따라 기본을 아는 수준에서 실제 릴리스를 이해하는 단계까지 올라갔다 — 단순히 main에 푸시하고 운에 맡기는 것이 아니라. 오늘 나는 처음으로 태그가 붙고, 릴리스되고, 위키가 작성된 프로젝트를 배포했다.

프로젝트 소개

Python으로 만든 Wordle 터미널 클론.

• 6번의 시도 안에 숨겨진 5글자 단어를 맞춘다.
• 각 추측에 대해 기호 피드백을 제공한다.
• 정신을 잃지 않도록 노력한다.

github.com/xaviermontane/Wordle

이 프로젝트에는 두 가지 목표가 있었다:

1. 또 다른 할 일 앱보다 흥미로운 무언가를 통해 Python과 CLI 실력을 갈고닦는다.
2. (비밀) 언젠가 게임의 핵심 로직을 역공학하여 Wordle 크래커를 만들고 싶다 — 다음 포스트를 위한 이야기다.

현재는 터미널 전용이지만, 언젠가 더 시각적인 형태로 포팅하고 싶다. 오늘의 목표는 더 간단했다: 제대로 배포하기.

나를 놀라게 한 점

• 태그는 브랜치가 아니다 — 특정 커밋을 가리키는 영구적인 레퍼런스이다.
• 태그에는 두 종류가 있다:
  • 경량 태그 (단순히 이름이 붙은 포인터)
  • 주석이 달린 태그 (메타데이터, 작성자, 날짜, 메시지를 포함하는 전체 Git 객체)
• GitHub 릴리스는 태그 위에 구축된다, 그 반대는 아니다.
• README와 릴리스 노트:
  • README = 지속적인 프로젝트 문서.
  • 릴리스 노트 = 해당 버전에서 구체적으로 변경된 내용.

그 마지막 점은 특히 내가 프로젝트를 문서화하는 방식을 바꾸었다.

태깅

git tag -a v1.0.0 -m "Terminal Wordle in Python — 6‑guess game with colour‑coded feedback and custom word list support"

나는 곧바로 “stable release”가 끔찍한 태그 메시지라는 것을 깨달았다. 태그 주석은 다음에 표시된다:

• git show
• git log
• GitHub의 태그 UI

따라서 메시지는 실제로 배포된 내용을 설명해야 한다.

git push origin v1.0.0

처음에는 이것이 나를 당황하게 만들었다: 태그는 일반 git push로 자동으로 푸시되지 않는다. 당신은 다음 중 하나를 해야 한다:

• 개별적으로 푸시하거나,
• git push --tags를 사용한다.

릴리스 노트

릴리스를 사후 생각처럼 다루는 대신, 나는 다음과 같이 작성했습니다:

• 실제 릴리스 노트
• 배포된 내용 요약
• “다음은?” 섹션

저는 레포지토리에 들어오는 모든 사람이 즉시 이해하길 원했습니다:

• 프로젝트가 무엇을 하는지
• 무엇이 변경되었는지
• 프로젝트가 아직 활발한지 여부

위키

I also built a small wiki containing:

• Home
• How to Play
• Custom Word Lists
• Changelog
• Roadmap

Keeping longer‑form documentation inside the wiki made the repo itself feel way cleaner.

버전 관리 및 규칙

몇 가지는 거의 즉시 명확해졌습니다:

• v1.0.0이 아니라 v0.1.0부터 시작하세요.
  v1.0.0은 9개의 커밋만 있는 레포지토리에서 약속하기엔 너무 높은 안정성을 의미합니다.

• 처음부터 Conventional Commits를 사용하세요:

  feat:   new feature
  fix:    bug fix
  chore:  maintenance

  이는 GitHub가 자동으로 릴리즈 노트를 생성하기 시작하면 특히 유용합니다.

CI

첫 번째 릴리스 전에 CI를 설정하세요. 아주 작은 “does this run?” 워크플로라도 전혀 없는 것보다 훨씬 낫습니다.

지원

프로젝트를 직접 사용해 보고 싶다면 자유롭게 복제해서 마음대로 만져보세요. 모든 지원에 깊이 감사드립니다:

• ⭐ 별
• 🍴 포크
• 🐛 이슈
• 💬 피드백

버전 기록

• v1.0.1 – 내 단어 목록에서 발견한 버그 수정(STRIN은 실제 단어가 아님)
• v1.1.0 – ANSI 색상 출력으로 피드백이 기호 대신 초록/노랑/회색으로 표시됨

전체 로드맵

• GitHub Wiki
• Semantic Versioning
• Keep a Changelog
• GitHub Docs — Releases

결론

여기까지 읽어주셔서 감사합니다. 이것은 제가 처음 쓴 기술 포스트 중 하나이며, 글을 쓰면서 배운 모든 것을 정리하는 데 도움이 되었습니다. 만약 이것이 한 사람이라도 Git 릴리스를 조금 더 잘 이해하는 데 도움이 된다면 이미 성공입니다.

Git을 처음부터 배우고 있다면, 계속 실험해보고 릴리스를 즐기세요!