How I shipped my first GitHub release (and what I learned)

Published: 3 weeks ago (May 17, 2026 at 08:35 PM EDT)

4 min read

Source: Dev.to

My journey with Git

Software development and I have never been the best of friends — which is exactly why I avoided going too deep into it for a long time. As I work towards becoming a junior IT specialist, I’ve been forcing myself to properly learn Git instead of just memorising enough commands to survive.

Following the roadmap.sh Git & GitHub roadmap, I went from knowing the basics to actually understanding releases — not just pushing to main and hoping for the best. Today I shipped my first ever tagged, released, and wikied project.

Meet the project

A terminal clone of Wordle written in Python.

Guess the hidden 5‑letter word in 6 tries.
Get symbol feedback on each guess.
Try not to lose your mind.

github.com/xaviermontane/Wordle

I had two goals with this project:

Sharpen my Python and CLI skills on something more interesting than another to‑do app.
(Secret) Eventually reverse‑engineer a Wordle cracker from the game’s core logic — a story for another post.

For now it’s terminal‑only, though I’d love to eventually port it into something more visual. Today’s goal was simpler: Ship it properly.

What surprised me

Tags are not branches — they’re permanent references to a specific commit.
Two types of tags:
- lightweight tags (just a named pointer)
- annotated tags (full Git objects containing metadata, author, date, and messages)
GitHub Releases are built on top of tags, not the other way around.
README vs. Release notes:
- README = evergreen project documentation.
- Release notes = what changed in this version specifically.

That last point especially changed how I think about documenting projects.

Tagging

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

I quickly realised “stable release” is a terrible tag message. Tag annotations show up in:

git show
git log
GitHub’s tag UI

So the message should actually explain what shipped.

git push origin v1.0.0

This caught me off guard the first time: tags don’t automatically push with a normal git push. You either:

Push them individually, or
Use git push --tags.

Release notes

Instead of treating the release like an afterthought, I wrote:

Actual release notes
A summary of what shipped
A “What’s Next” section

I wanted anyone landing on the repo to immediately understand:

What the project does
What changed
Whether the project is still active

Wiki

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.

Versioning & Conventions

A few things became obvious almost immediately:

Start at v0.1.0, not v1.0.0.
v1.0.0 implies a level of stability I wasn’t ready to promise on a 9‑commit repo.
Use Conventional Commits from day one:
```
feat:   new feature
fix:    bug fix
chore:  maintenance
```
This becomes especially useful once GitHub starts auto‑generating release notes.

CI

Set up CI before the first release. Even a tiny “does this run?” workflow is infinitely better than nothing.

Support

If you’d like to try the project, feel free to clone it and mess around with it. Any support is massively appreciated:

⭐ Stars
🍴 Forks
🐛 Issues
💬 Feedback

Version history

v1.0.1 – fixing a bug I spotted in my own word list (STRIN is not a real word)
v1.1.0 – ANSI colour output so feedback becomes green/yellow/grey instead of symbols

Full roadmap

Conclusion

If you made it this far, thank you. This is one of my first technical posts, and writing it helped me consolidate everything I learned. If it helps even one person understand Git releases a little better, that’s already a win.

If you’re also learning Git from scratch, keep experimenting and happy releasing!