Capstone project

Capstone: ship a release

Lesson 20 of 20 · 16 min · Module 6: Safe releases and the capstone

Your site is ready for version 1.0. Ship it the way teams do: start from an up-to-date main, make the change on a branch, merge it through a pull request, and mark the release with a tag.

Start this lesson →

Free. No installation: you write and run the code in your browser, and it is checked automatically.

By the end, you’ll be able to…

Start work from an up-to-date main
Deliver a change through a pull request
Tag and publish a release

The idea

One new tool: a tag is a permanent name for a commit, such as v1.0.0, used for releases. git tag -a v1.0.0 -m "Version 1.0.0" creates an annotated tag on the commit you are on, recording who tagged it, when, and why. Tags are not pushed with your branches: send one with git push origin v1.0.0. Everything else you already know.

git tag -a v1.0.0 -m "Version 1.0.0"
git show v1.0.0
git push origin v1.0.0

01Start from the latest main

Before you branch, pull. A branch made from an old main drags old code into your pull request and makes conflicts more likely.

git pull

Output

remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (3/3), 329 bytes | 329.00 KiB/s, done.
From https://github.com/learner/website
   4abfd2a..5a4cd2e  main       -> origin/main
Updating 4abfd2a..5a4cd2e
Fast-forward
 reading.md | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 reading.md

02The pull request round trip

Branch, commit, push with -u, gh pr create, and gh pr merge --merge --delete-branch. After the merge, gh switches you back to main and pulls, so main points to the merge commit you are releasing.

03Tag the release and push the tag

An annotated tag stores a message, your name and the date, and git show v1.0.0 displays them. Push it by name; git push --tags would send every tag.

git tag -a v1.0.0 -m "Version 1.0.0"
git push origin v1.0.0

Output

Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 160 bytes | 160.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To https://github.com/learner/website.git
 * [new tag]         v1.0.0 -> v1.0.0

Your project brief

Ship version 1.0.0. Bring main up to date with GitHub first: Sam pushed something. On a branch named release-1.0, add CHANGELOG.md with a ## 1.0.0 section that lists at least one change, as a line starting with - , and commit it. Push the branch, open a pull request, and merge it. Then, on an up-to-date main, create the annotated tag v1.0.0 on the merged commit and push the tag.

What the checks look for

main on GitHub has Sam's reading list and your changelog
The changelog lists a change under 1.0.0
The change went through a merged pull request from release-1.0
v1.0.0 is an annotated tag on the merged main
The tag is on GitHub
Your main is up to date and clean

Try it in the editor →

Take this with you

Pull, branch, commit, push, review, merge, tag: the release workflow in seven steps.

Go a little further

Make one more commit and run git describe --tags: it names the commit relative to the latest tag, such as v1.0.0-1-g1a2b3c4.