Tagging a Release

A tag is a named pointer to a specific commit — like a branch that never moves. Tags are used to mark significant moments in a project’s history, most commonly releases. When you tag v1.0.0, that label stays on that commit forever, even as the project continues.

Why tag a release

For a portfolio project, a release tag accomplishes two things:

1. Marks a finished state — v1.0.0 says “this version of the project is complete.” If you continue developing it later, the initial version is still accessible.
2. Shows professional practice — a GitHub repository with tagged releases looks more like a real project than one with only commits.

Annotated vs lightweight tags

Git has two kinds of tags:

Lightweight tag — just a pointer to a commit. No metadata.

git tag v1.0.0

Annotated tag — a full Git object with a tagger name, email, date, and a message. Stored in the object database.

git tag -a v1.0.0 -m "Version 1.0.0 — Initial release of the STO site"

Use annotated tags for releases. They are the right tool when the tag has meaning and you want it to carry a message and timestamp.

Creating the v1.0.0 tag

Make sure your local main is up to date and everything is committed:

git status     # should be clean
git log --oneline -3   # confirm you are on the right commit

Create the annotated tag:

git tag -a v1.0.0 -m "Version 1.0.0 — Initial release of Summit Trail Outfitters"

Verify it was created:

git tag

git show v1.0.0

git show on a tag displays the tag metadata (tagger, date, message) and then the commit it points to.

Pushing tags to GitHub

Tags are not pushed automatically with git push. Push the tag explicitly:

git push origin v1.0.0

Or push all tags at once:

git push origin --tags

After pushing, the tag appears on GitHub under Releases and on the Tags tab of the repository.

Creating a GitHub Release from the tag

A GitHub Release is a page built around a tag — it provides a place to write release notes, and GitHub adds a download link for the source code at that tag.

1. On GitHub, click Releases in the right sidebar (or navigate to the Tags tab)
2. Click Create release from tag (or Draft a new release)
3. Select v1.0.0 from the tag dropdown
4. Fill in the release title: Version 1.0.0
5. Write release notes describing what is in this version:

## Summit Trail Outfitters — v1.0.0

Initial release of the Summit Trail Outfitters static site.

### What's included

- 6-page static site (Home, About, Contact, Trails, Gear, 404)
- Responsive layout with CSS custom properties
- Contact form with real-time JavaScript validation
- Trail and gear listings with card components
- Custom 404 page

Built as a capstone project for an HTML, CSS, and JavaScript learning path.

6. Click Publish release

The release is now visible at https://github.com/yourusername/summit-trail-outfitters/releases/tag/v1.0.0.

Tagging a specific past commit

If you want to tag a commit that is not the latest:

git log --oneline      # find the commit hash
git tag -a v0.9.0 a1b2c3d -m "Pre-release checkpoint"
git push origin v0.9.0

Exercise

1. Confirm your local repository is clean: git status

2. Create the annotated tag:

git tag -a v1.0.0 -m "Version 1.0.0 — Initial release of Summit Trail Outfitters"

3. Push the tag to GitHub:

git push origin v1.0.0

4. On GitHub, create a release from the v1.0.0 tag with a title and release notes describing the project.

5. Visit https://github.com/yourusername/summit-trail-outfitters/releases and confirm the release is published.

Recap

• A tag is a named, permanent pointer to a commit. Annotated tags carry metadata and a message.
• git tag -a v1.0.0 -m "message" creates an annotated tag on the current commit.
• Tags must be pushed explicitly: git push origin v1.0.0 or git push origin --tags.
• A GitHub Release is a page built around a tag — with release notes and a source code download.
• For a portfolio project, v1.0.0 marks the initial complete version.

Next: publishing the STO site with GitHub Pages — making the site live at a real URL.