GitHub Release Simulation

Recap: Where We Left Off

You have an open pull request in your my-devops-portfolio repository titled feat: Create basic HTML structure for homepage. It's been "reviewed" (we'll assume it was approved!), and it's ready for the final step: integration.

1. Merging the Pull Request

Merging is the action of integrating the changes from your feature branch (feat/homepage-structure) into your target branch (main).

1. Navigate to your my-devops-portfolio repository on GitHub and click on the "Pull requests" tab.
2. Click on your open pull request.
3. At the bottom of the PR, you'll see a green button that says "Merge pull request".
   • A Note on Merge Options: If you click the small arrow next to the button, you'll see options like "Squash and merge" or "Rebase and merge". These are different strategies for combining histories. For now, the default "Create a merge commit" is perfectly fine. It preserves the entire history of your feature branch.
4. Click the "Merge pull request" button, and then click "Confirm merge".

After the merge is complete, GitHub will give you an option to "Delete branch". It is a strong best practice to delete your feature branch after it has been merged. This keeps your repository clean and prevents the branch from being used again by mistake. Go ahead and click it.

Your code is now officially part of the main branch!

2. Understanding Releases: Git Tags and Semantic Versioning

Just because the code is in main doesn't mean it's a "release." A release is a formal, stable version of your project that you can share with users. In Git, we mark these specific points in history using tags.

To give our tags meaning, we use a convention called Semantic Versioning (SemVer). It provides a clear, universal way to communicate the nature of changes in a release.

To learn the fundamentals of tags and SemVer, please read the first few sections of the following article.

3. Creating and Pushing a Tag

Now let's apply this to your project. You've added a new, backward-compatible feature (the homepage structure). Since this is the very first version of your application, we'll call it v0.1.0.

Follow these steps in your terminal, inside your my-devops-portfolio project directory.

1. Sync with the remote repository. Your local main branch doesn't have the merge commit yet. You need to pull it from GitHub.

   # Switch to your main branch
   git checkout main
   
   # Pull the latest changes (including the merge)
   git pull origin main
   

2. Create an annotated tag. We'll use an annotated tag (-a) because it's considered a best practice for releases. It stores extra metadata, like the author, date, and a message, making it a full object in Git.

   # Create an annotated tag for version 0.1.0
   git tag -a v0.1.0 -m "Initial release with homepage structure"
   

   The -m provides the tagging message, which is like a commit message for your tag.

3. Push the tag to GitHub. By default, git push does not send tags to the remote repository. You must push them explicitly.

   # Push all your local tags to the remote repository
   git push --tags
   

Your tag v0.1.0 is now associated with the latest commit on main in your GitHub repository.

4. Publishing a Release on GitHub

A Git tag is just a pointer. A GitHub Release is a much richer object built on top of a tag. It provides a permanent home for your release, complete with:

• Formatted release notes (a changelog).
• Links to the source code at that point in time.
• Optional binary files (e.g., installers, compiled executables).

This is what a finished release looks like on GitHub:

Let's create one for v0.1.0. The official GitHub documentation provides the best guide for this.

Here's a summary of the steps from the guide you'll be following:

1. On your repository page, click the "Releases" link on the right sidebar.
2. Click "Draft a new release".
3. Under "Choose a tag", select the v0.1.0 tag you just pushed.
4. For the "Release title", enter something descriptive, like Version 0.1.0: Initial Homepage.
5. In the "Describe this release" box, write your release notes. For this release, you can write:

   ### What's New 🎉
   
   *   Adds the basic HTML structure for the portfolio homepage, including header, main, and footer sections.
   
   This is the first functional version of the portfolio site.
   

   Pro-Tip: For larger projects, GitHub has an "Auto-generate release notes" button that automatically summarizes all the pull requests included since the last release.
6. Click "Publish release".

You have now successfully published your first software release! You can see it listed under the "Releases" tab, and the tag will be prominently displayed on your repository's main page.

This diagram helps visualize where tags fit into a larger development strategy, marking key points on the main (or master) branch.

Conclusion

Congratulations on completing the full feature lifecycle! You have now experienced the end-to-end process that is fundamental to DevOps and modern software engineering.

Key Takeaways:

• Pull requests are integrated into the main codebase via a merge.
• Git tags are used to create a permanent pointer to a specific commit, marking it as a version.
• Semantic Versioning (SemVer) provides a standard for version numbers (MAJOR.MINOR.PATCH).
• GitHub Releases are user-friendly pages built from Git tags that include release notes and downloadable assets.

In our next lesson, we'll step away from the "happy path" workflow and dive into troubleshooting. You will learn how to diagnose and resolve a common and sometimes confusing situation in Git: the 'detached HEAD' state.