You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+43-37Lines changed: 43 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,54 +16,60 @@ _Create a release based workflow that is built on the foundations of the GitHub
16
16
</header>
17
17
18
18
<!--
19
-
<<< Author notes: Course start >>>
20
-
Include start button, a note about Actions minutes,
21
-
and tell the learner why they should take the course.
19
+
<<< Author notes: Step 2 >>>
20
+
Start this step by acknowledging the previous step.
21
+
Define terms and link to docs.github.com.
22
22
-->
23
23
24
-
## Welcome
24
+
## Step 2: Add a new feature to the release branch
25
25
26
-
Create 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.
26
+
_Great job creating a beta release:heart:_
27
27
28
-
GitHub releases allow your team to package and provide software to your users based on a specific point in the history of your project.
28
+
### Release management
29
29
30
-
-**Who is this for**: Developers, DevOps Engineers, IT Operations, managers, and teams.
31
-
-**What you'll learn**: How to follow a release-based workflow.
32
-
-**What you'll build**: You will create tags, releases, and release notes.
33
-
-**Prerequisites**: If you need to learn about branches, commits, and pull requests, take [Introduction to GitHub](https://github.com/skills/introduction-to-github) first.
34
-
-**How long**: This course takes less than 1 hour to complete.
30
+
As 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.
35
31
36
-
In this course, you will:
32
+
There 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.
37
33
38
-
1. Create a beta release
39
-
2. Add a feature to a release
40
-
3. Open a release pull request
41
-
4. Add release notes and merge
42
-
5. Finalize a release
43
-
6. Commit a hotfix
44
-
7. Create a hotfix release
34
+
No one strategy is better than another. We always recommend being intentional about branches and reducing long-lived branches whenever possible.
45
35
46
-
### How to start this course
36
+
In this exercise, you'll use the `release-v1.0` branch to be your one long-lived branch per release version.
47
37
48
-
<!-- For start course, run in JavaScript:
49
-
'https://github.com/new?' + new URLSearchParams({
50
-
template_owner: 'skills',
51
-
template_name: 'release-based-workflow',
52
-
owner: '@me',
53
-
name: 'skills-release-based-workflow',
54
-
description: 'My clone repository',
55
-
visibility: 'public',
56
-
}).toString()
57
-
-->
38
+
### Protected branches
39
+
40
+
Like 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.
41
+
42
+
### Add a feature
43
+
44
+
Releases are usually made of many smaller changes. Let's pretend we don't know about the bug we added earlier and we'll focus on a few features to update our game before the version update.
45
+
46
+
- You should update the page background color to black.
47
+
- I'll help you change the text colors to green.
48
+
49
+
### :keyboard: Activity: Update `base.css`
50
+
51
+
1. Create a new branch off of the `main` branch and change the `body` CSS declaration in `base.css` to match what is below. This will set the page background to black.
52
+
53
+
```
54
+
body {
55
+
background-color: black;
56
+
}
57
+
```
58
+
59
+
1. Open a pull request with `release-v1.0` as the `base` branch, and your new branch as the `compare` branch.
60
+
1. Fill in the pull request template to describe your changes.
61
+
1. Click **Create pull request**.
62
+
63
+
### Merge the new feature to the release branch
64
+
65
+
Even 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.
66
+
67
+
Merge this feature pull request so that you can open the release pull request as early as possible.
1. Right-click **Start course** and open the link in a new tab.
62
-
2. In the new tab, most of the prompts will automatically fill in for you.
63
-
- For owner, choose your personal account or an organization to host the repository.
64
-
- We recommend creating a public repository, as private repositories will [use Actions minutes](https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions).
65
-
- Scroll down and click the **Create repository** button at the bottom of the form.
66
-
3. 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.
71
+
1. Click **Merge pull request**, and delete your branch.
72
+
1. Wait about 20 seconds then refresh this page (the one you're following instructions from). [GitHub Actions](https://docs.github.com/en/actions) will automatically update to the next step.
0 commit comments