{"id":18282187,"url":"https://github.com/vikashpr/release-based-workflow","last_synced_at":"2025-04-09T05:24:20.923Z","repository":{"id":112434480,"uuid":"585240941","full_name":"VikashPR/Release-based-workflow","owner":"VikashPR","description":null,"archived":false,"fork":false,"pushed_at":"2023-01-04T17:49:42.000Z","size":84,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-02-14T23:47:16.644Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc-by-4.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/VikashPR.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-01-04T17:10:16.000Z","updated_at":"2024-06-18T12:17:57.000Z","dependencies_parsed_at":"2023-05-15T03:00:11.161Z","dependency_job_id":null,"html_url":"https://github.com/VikashPR/Release-based-workflow","commit_stats":null,"previous_names":[],"tags_count":3,"template":false,"template_full_name":"skills/release-based-workflow","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VikashPR%2FRelease-based-workflow","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VikashPR%2FRelease-based-workflow/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VikashPR%2FRelease-based-workflow/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VikashPR%2FRelease-based-workflow/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/VikashPR","download_url":"https://codeload.github.com/VikashPR/Release-based-workflow/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247982642,"owners_count":21028155,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-05T13:04:32.551Z","updated_at":"2025-04-09T05:24:20.904Z","avatar_url":"https://github.com/VikashPR.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"\n\u003c!--\n    The step and endstep markers will cause this \n    introduction content to be hidden once the \n    repository is created off the template\n--\u003e\n\n# Create a release based workflow\n\n\u003c!--step0\nCreate a release based workflow that is built on the foundations of the [GitHub flow](https://guides.github.com/introduction/flow/). When your team uses a release-based workflow, GitHub makes it easy to collaborate with deployable iterations of your project that you can package and make available for a wider audience to download and use.\n\nGitHub releases allow your team to package and provide software to your users based on a specific point in the history of your project.\n\n- **Who is this for**: Developers, DevOps Engineers, IT Operations, managers, and teams.\n- **What you'll learn**: How to follow a release-based workflow.\n- **What you'll build**: You will create tags, releases, and release notes.\n- **Prerequisites**: If you need to learn about branches, commits, and pull requests, take [Introduction to GitHub](https://github.com/skills/introduction-to-github) first.\n- **How long**: This course is 7 steps long and takes less than 1 hour to complete.\n\n## How to start this course\n\n1. Above these instructions, right-click **Use this template** and open the link in a new tab.\n   ![Use this template](https://user-images.githubusercontent.com/1221423/169618716-fb17528d-f332-4fc5-a11a-eaa23562665e.png)\n2. In the new tab, follow the prompts to create a new repository.\n   - For owner, choose your personal account or an organization to host the repository.\n   - We recommend creating a public repository-private repositories will [use Actions minutes](https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions).\n   ![Create a new repository](https://user-images.githubusercontent.com/1221423/169618722-406dc508-add4-4074-83f0-c7a7ad87f6f3.png)\n3. After your new repository is created, wait about 20 seconds, then refresh the page. Follow the step-by-step instructions in the new repository's README.\nendstep0--\u003e\n\n\u003c!--Step 1--\u003e\n\u003cdetails id=1 open\u003e\n\u003csummary\u003e\u003ch2\u003eStep 1: Create a beta release\u003c/h2\u003e\u003c/summary\u003e\n\n### The GitHub flow\n\nThe [GitHub flow](https://guides.github.com/introduction/flow/) is a lightweight, branch-based workflow for projects with regular deployments.\n\n![github-flow](https://user-images.githubusercontent.com/6351798/48032310-63842400-e114-11e8-8db0-06dc0504dcb5.png)\n\nSome projects may deploy more often, with continuous deployment. There might be a \"release\" every time there's a new commit on main.\n\nBut, some projects rely on a different structure for versions and releases.\n\n### Versions\n\nVersions are different iterations of updated software like operating systems, apps, or dependencies. Common examples are \"Windows 8.1\" to \"Windows 10\", or \"macOS High Sierra\" to \"macOS Mojave\".\n\nDevelopers update code and then run tests on the project for bugs. During that time, the developers might set up certain securities to protect from new code or bugs. Then, the tested code is ready for production. Teams version the code and release it for installation by end users.\n\n### :keyboard: Activity: Create a release for the current codebase\nIn this step, you will create a release for this repository on GitHub.\n\nGitHub Releases point to a specific commit. Releases can include release notes in Markdown files, and attached binaries.\n\nBefore using a release based workflow for a larger release, let's create a tag and a release.\n\n1. Open a new browser tab, and work on the steps in your second tab while you read the instructions in this tab.\n1. Go to the **Releases** page for this repository.\n    - You can click the **Code** tab at the top of your repository. Then, find the navigation bar below the repository description, and click **0 releases**.\n1. Click **Create a new release**\n1. In the field for _Tag version_, specify a number. In this case, use **v0.9**. Keep the _Target_ as **main**\n1. Give the release a title, like \"First beta release\". If you'd like, you could also give the release a short description\n1. Select the checkbox next to **This is a pre-release**, since it is representing a beta version\n1. Click **Publish release**\n1. Wait about 20 seconds then refresh this page for the next step\n\n\u003c/details\u003e\n\n\u003c!--Step 2--\u003e\n\u003cdetails id=2\u003e\n\u003csummary\u003e\u003ch2\u003eStep 2: Add a new feature to the release branch\u003c/h2\u003e\u003c/summary\u003e\n\n### Release management\n\nAs you prepare for a future release, you'll need to organize more than the tasks and features. It's important to create a clear workflow for your team, and to make sure that the work remains organized.\n\nThere are several strategies for managing releases. Some teams might use long-lived branches, like `production`, `dev`, and `main`. Some teams use simple feature branches, releasing from the main branch.\n\nNo one strategy is better than another. We always recommend being intentional about branches and reducing long-lived branches whenever possible.\n\nIn this exercise, you'll use the `release-v1.0` branch to be your one long-lived branch per release version.\n\n### Protected branches\n\nLike the `main` branch, you can protect release branches. This means you can protect branches from force pushes or accidental deletion. This is already configured in this repository.\n\n### Add a feature\n\nReleases are usually made of many smaller changes. Since we don't know of any bugs, we'll focus on a few features to update on our game before the version update.\n\n- You should update the page background color to black.\n- I'll help you change the text colors to green.\n\n### :keyboard: Activity: Update `base.css`\n\n1. Create a new branch and change the `body` CSS declaration in `base.css` to match what is below. This will set the page background to black\n```\nbody {\n    background-color: black;\n}\n```\n2. Open a pull request with `release-v1.0` as the `base` branch, and your new branch as `compare`\n3. Fill in the pull request template to describe your changes\n\n### Merge the new feature to the release branch\nEven with releases, the GitHub flow is still an important strategy for working with your team. It's a good idea to use short-lived branches for quick feature additions and bug fixes.\n\nMerge this feature pull request so that you can open the release pull request as early as possible.\n\n### :keyboard: Activity: Merge the pull request\n\n1. Click **Merge pull request**, and delete your branch.\n1. Wait about 20 seconds then refresh this page for the next step.\n\n\u003c/details\u003e\n\n\u003c!--Step 3--\u003e\n\u003cdetails id=3\u003e\n\u003csummary\u003e\u003ch2\u003eStep 3: Open a release pull request\u003c/h2\u003e\u003c/summary\u003e\n\n### Release branches and `main`\n\nYou should open a pull request between your release branch and main as early as possible. It might be open for a long time, and that's okay.\n\nIn general, the pull request description can include:\n- A [reference to an issue](https://docs.github.com/en/articles/basic-writing-and-formatting-syntax/#mentioning-people-and-teams) that the pull request addresses.\n- A description of the changes proposed in the pull request.\n- [@mentions](https://docs.github.com/en/articles/basic-writing-and-formatting-syntax/#mentioning-people-and-teams) of the person or team responsible for reviewing proposed changes.\n\nTo expedite the creation of this pull request, I've added a pull request template to the repository. When you create a pull request, default text will automatically be displayed. This should help you identify and fill out all the necessary information. If you don't want to use the template content, just remove the text from the pull request and repace it with your pull request message.\n\n### :keyboard: Activity: Open a release pull request\nLet's make a new pull request comparing the `release-v1.0` branch to the `main` branch.\n\n1. Open a new browser tab, and work on the steps in your second tab while you read the instructions in this tab\n1. Open a **new pull request** with `base: main` and `compare: release-v1.0`\n1. Ensure the title of your pull request is **Release v1.0**\n1. Include a detailed pull request body, an example is below\n    ```\n    ## Description: \n    - Changed page background color to black.\n    - Changed game text color to green.\n    ```\n1. Wait about 20 seconds then refresh this page for the next step\n\n\u003c/details\u003e\n\n\u003c!--Step 4--\u003e\n\u003cdetails id=4\u003e\n\u003csummary\u003e\u003ch2\u003eStep 4: Generate release notes and merge\u003c/h2\u003e\u003c/summary\u003e\n\n### Automatically generated release notes\n[Automatically generated release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) provide an automated alternative to manually writing release notes for your GitHub releases. With automatically generated release notes, you can quickly generate an overview of the contents of a release. Automatically generated release notes include a list of merged pull requests, a list of contributors to the release, and a link to a full changelog. You can also customize your release notes once they are generated.\n\n### :keyboard: Activity: Generate release notes\n\n1. In a separate tab, go to the **Releases** page for this repository.\n    - _Tip: To reach this page, click the **Code** tab at the top of your repository. Then, find the navigation bar below the repository description, and click the **Releases** heading link_\n1. Click the **Draft a new release** button\n1. In the field for _Tag version_, specify `v1.0.0`\n1. To the right of the tag dropdown, click the _Target_ dropddown and select the `release-v1.0` branch\n    - _Tip: This is temporary in order to generate release notes based on the changes in this branch_\n1. To the top right of the description text box, click **Generate release notes**\n1. Review the release notes in the text box and customize the content if desired\n1. Set the _Target_ branch back to the `main`, as this is the branch you want to create your tag on once the release branch is merged\n1. Click **Save draft**, as you will publish this release in the next step\n\nYou can now [merge](https://docs.github.com/en/get-started/quickstart/github-glossary#merge) your pull request!\n\n### :keyboard: Activity: Merge into main\n\n1. In a separate tab, go to the **Pull requests** page for this repository.\n1. Open your **Release v1.0** pull request\n1. Click **Merge pull request**.\n1. Wait about 20 seconds then refresh this page for the next step.\n\n\u003c/details\u003e\n\n\u003c!--Step 5--\u003e\n\u003cdetails id=5\u003e\n\u003csummary\u003e\u003ch2\u003eStep 5: Finalize the release\u003c/h2\u003e\u003c/summary\u003e\n\n### Finalizing releases\n\nIt's important to be aware of the information what will be visible in that release. In the pre-release, the version and commit messages are visible.\n\n![image](https://user-images.githubusercontent.com/13326548/47883578-bdba7780-ddea-11e8-84b8-563e12f02ca6.png)\n\n### Semantic versioning\n\nSemantic versioning is a formal convention for specifying compatibility. It uses a three-part version number: **major version**; **minor version**; and **patch**.  Version numbers convey meaning about the underlying code and what has been modified. For example, versioning could be handled as follows:\n\n| Code status  | Stage  | Rule  | Example version  |\n|---|---|---|---|\n| First release  | New product  | Start with 1.0.0  | 1.0.0  |\n| Backward compatible fix  | Patch release  | Increment the third digit  | 1.0.1  |\n| Backward compatible new feature  | Minor release  | Increment the middle digit and reset the last digit to zero  | 1.1.0  |\n| Breaking updates | Major release | Increment the first digit and reset the middle and last digits to zero | 2.0.0 |\n\nCheck out this article on [Semantic versioning](https://semver.org/) to learn more.\n\n### Finalize the release\n\nNow let's change our recently automated release from _draft_ to _latest release_.\n\n### :keyboard: Activity: Finalize release\n\n1. In a separate tab, go to the **Releases** page for this repository\n    - To reach this page, click the **Code** tab at the top of your repository. Then, find the navigation bar below the repository description, and click the **Releases** heading link\n1. Click the **Edit** button next to your draft release\n1. Ensure the _Target_ branch is set to `main`\n1. Click **Update release**\n1. Wait about 20 seconds then refresh this page for the next step\n\n\u003c/details\u003e\n\n\u003c!--Step 6--\u003e\n\u003cdetails id=6\u003e\n\u003csummary\u003e\u003ch2\u003eStep 6: Commit a hotfix to the release\u003c/h2\u003e\u003c/summary\u003e\n\nNotice that I didn't delete the branch? That's intentional.\n\nSometimes mistakes can happen with releases, and we'll want to be able to correct them on the same branch.\n\nNow that your release is finalized, we have a confession to make. Somewhere in our recent update, I made a mistake and introduced a bug. Instead of changing the text colors to green, we changed the whole game background.\n\n_Tip: Sometimes GitHub Pages takes a few minutes to update. Your page might not immediately show the recent updates you've made._\n\n![image](https://user-images.githubusercontent.com/13326548/48045461-487dd800-e145-11e8-843c-b91a82213eb8.png)\n\n\"Hotfixes\", or a quick fix to address a bug in software, are a normal part of development. Oftentimes you'll see application updates whose only description is \"bug fixes\".\n\nWhen bugs come up after you release a version, you'll need to address them.\n\nWe've already created this branch and pull request. The suggested change will be merged into the main branch. Later we will `cherry-pick` the hotfix commits into the release branch.\n\nSubmit a hotfix by approving and merging the pull request.\n\n### :keyboard: Activity: Merge the hotfix\n1. In a separate tab, go to the **Pull requests** page and view the open pull request\n1. Review the changes and approve the pull request\n1. Click **Merge pull request**\n1. Wait about 20 seconds then refresh this page for the next step\n\n\u003c/details\u003e\n\n\u003c!--Step 7--\u003e\n\u003cdetails id=7\u003e\n\u003csummary\u003e\u003ch2\u003eStep 7: Create release v1.0.1\u003c/h2\u003e\u003c/summary\u003e\n\n### A final release\n\nYou updated the source code, but users can't readily access your most recent changes. Prepare a new release, and distribute that release to the necessary channels.\n\n### Create release v1.0.1\n\nWith descriptive pull requests and auto generated release notes, you don't have to spend a lot of time working on your release draft. Follow the steps below to create your new release, generate the release notes, and publish.\n\n### :keyboard: Activity: Complete release\n\n1. In a separate tab, go to to the **Releases** page for this repository\n    - _Tip: To reach this page, click the **Code** tab at the top of your repository. Then, find the navigation bar below the repository description, and click the **Releases** heading link_\n1. Click the **Draft a new release** button\n1. Set the _Target_ branch to `main`\n    - _Tip: Practice your semantic version syntax. What should the tag and title for this release be?_\n1. To the top right of the description text box, click **Generate release notes**\n1. Review the release notes in the text box and customize the content if desired\n1. Click **Publish release**\n1. Wait about 20 seconds then refresh this page for the next step\n\n\u003c/details\u003e\n\n\u003cdetails id=x\u003e\n\u003csummary\u003e\u003ch2\u003eFinish\u003c/h2\u003e\u003c/summary\u003e\n\n### Congratulations friend, you've completed this course!\n\nHere's a recap of all the tasks you've accomplished in your repository:\n\n- Create a beta release.\n- Add a new feature to the release branche.\n- Open a release pull request\n- Automate release notes.\n- Merge and finalize the release branch.\n- Commit a hotfix to the release.\n- Create release v1.0.1.\n\n### What's next?\n\n- [We'd love to hear what you thought of this course](TBD-feedback-link).\n- [Take another GitHub Skills course](https://github.com/skills).\n- [Read the GitHub Getting Started docs](https://docs.github.com/en/get-started).\n- To find projects to contribute to, check out [GitHub Explore](https://github.com/explore).\n\n\u003c/details\u003e\n\n---\n\nGet help: [Post in our discussion board](https://github.com/skills/.github/discussions) • [Review the GitHub status page](https://www.githubstatus.com/)\n\n© 2022 GitHub • [Code of Conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/code_of_conduct.md) • [CC-BY-4.0 License](https://creativecommons.org/licenses/by/4.0/legalcode)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvikashpr%2Frelease-based-workflow","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvikashpr%2Frelease-based-workflow","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvikashpr%2Frelease-based-workflow/lists"}