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: content/full-day/7-github-flow.md
+37-15Lines changed: 37 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,27 +1,31 @@
1
1
# GitHub flow
2
2
3
-
The [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) is a lightweight, [branch-based](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) workflow. It's designed to allow for free testing and exploration of ideas and novel approaches which are then reviewed and, if accepted, brought into the codebase. At a high level, the GitHub flow follows this pattern:
3
+
|[← Add new functionality][walkthrough-previous]|[Next: Deploy the application →][walkthrough-next]|
The [GitHub flow][github-flow] is a lightweight, [branch-based][about-branches] workflow. It's designed to allow for free testing and exploration of ideas and novel approaches which are then reviewed and, if accepted, brought into the codebase. At a high level, the GitHub flow follows this pattern:
4
7
5
8
1. Create a branch
6
9
1. Make the desired changes
7
-
1. Create a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
10
+
1. Create a [pull request][about-prs]
8
11
1. Review changes, gather feedback and make updates
9
12
1. Review results of automated operations such as testing for continuous integration
10
13
1. If changes are approved, merge into codebase
11
14
12
15
The GitHub flow is designed to work as a cycle, where contributors continuously explore, test, review, and build upon their work and the work of others.
13
16
14
-
> **NOTE:** One key philosophy for GitHub flow is not every pull request needs to be merged. Sometimes exploration is the goal, the feature isn't one which is desired by the greater team, or wholesale changes need to be made necessitating starting over. This is part of the process, and allows for free experimentation.
17
+
> [!NOTE]
18
+
> One key philosophy for GitHub flow is not every pull request needs to be merged. Sometimes exploration is the goal, the feature isn't one which is desired by the greater team, or wholesale changes need to be made necessitating starting over. This is part of the process, and allows for free experimentation.
15
19
16
20
## Scenario
17
21
18
-
With the code changes created in the [prior exercise](./6-code.md), it's time to walk through the GitHub flow to create a pull request and incorporate the updates into the codebase. While the changes have already been made (meaning we are slightly out of order from the "traditional" flow), you can still perform the steps to explore.
22
+
With the code changes created in the [prior exercise][code-exercise], it's time to walk through the GitHub flow to create a pull request and incorporate the updates into the codebase. While the changes have already been made (meaning we are slightly out of order from the "traditional" flow), you can still perform the steps to explore.
19
23
20
24
## Creating a branch
21
25
22
-
A [branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) is a copy of the code stored in the same repository. By using branches to test updates you have a safe space to explore while keeping all code in the same repository.
26
+
A [branch][about-branches] is a copy of the code stored in the same repository. By using branches to test updates you have a safe space to explore while keeping all code in the same repository.
23
27
24
-
There are different ways to create a branch when using [GitHub Codespaces](https://github.com/features/codespaces). You can utilize the command-line to run [git](https://git-scm.com/docs/git-branch) commands. You can use the Source Control pane in your codespace to get the support of the UI for creating your branch. In our example we're going to use the command-line to create the branch.
28
+
There are different ways to create a branch when using [GitHub Codespaces][github-codespaces]. You can utilize the command-line to run [git](https://git-scm.com/docs/git-branch) commands. You can use the Source Control pane in your codespace to get the support of the UI for creating your branch. In our example we're going to use the command-line to create the branch.
25
29
26
30
1. Return to your codespace, or reopen it by navigating to your repository and selecting **Code** > **Codespaces** and the name of your codespace.
27
31
2. Open a **terminal window** by pressing <kbd>Ctl</kbd> + <kbd>`</kbd>.
@@ -50,12 +54,12 @@ There are different ways to create a branch when using [GitHub Codespaces](https
50
54
51
55
## Create the pull request to suggest updates
52
56
53
-
A [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) is a request to pull or incorporate new code into the existing codebase. When a pull request is made it's customary to have other team members review the code and make comments, and for [CI/CD](https://resources.github.com/ci-cd/) processes to run. Once everything is completed and the code is in a stage where everyone has signed-off, it's then merged into the codebase.
57
+
A [pull request][about-prs] is a request to pull or incorporate new code into the existing codebase. When a pull request is made it's customary to have other team members review the code and make comments, and for [CI/CD][cicd-resources] processes to run. Once everything is completed and the code is in a stage where everyone has signed-off, it's then merged into the codebase.
54
58
55
-
Pull requests can be made through the source control pane in the codespace, the repository's website, or through the command-line using the [GitHub CLI](https://cli.github.com/). In our example we're going to create the pull request in the CLI, then navigate to the website to see the pull request and the actions running, and merge the code into the codebase.
59
+
Pull requests can be made through the source control pane in the codespace, the repository's website, or through the command-line using the [GitHub CLI][github-cli]. In our example we're going to create the pull request in the CLI, then navigate to the website to see the pull request and the actions running, and merge the code into the codebase.
56
60
57
61
1. Return to your codespace.
58
-
1. Find the number forthe [issue you created earlier](./2-issues.md) titled **Add component to display hours** by entering the following commandin the terminal window:
62
+
1. Find the number forthe [issue you created earlier][issues-exercise] titled **Add component to display hours** by entering the following commandin the terminal window:
59
63
60
64
```bash
61
65
gh issue list
@@ -71,22 +75,40 @@ Pull requests can be made through the source control pane in the codespace, the
71
75
72
76
When the pull request is created, you will see a link appear to the page for the pull request. From there you can add comments, see any workflows running, and decide to close or merge the pull request. You can also see any workflows associated with the pull request run.
73
77
74
-
In our scenario, we created an automated workflow for front-end tests for our application, which runs whenever a push or pull request is made to `main`. We also enabled [code scanning](../exercises/1-code-scanning.md), which was set to run on the same triggers. We've just created a pull request, which will cause both of those workflows to run!
78
+
In our scenario, we created an automated workflow for front-end tests for our application, which runs whenever a push or pull request is made to `main`. We also enabled [code scanning][security-exercise], which was set to run on the same triggers. We've just created a pull request, which will cause both of those workflows to run!
75
79
76
80
Let's explore the pull request and watch the workflows run. We'll ensure the tests now run successfully and, assuming they do, merge the pull request.
77
81
78
82
1. Follow the link displayed in the terminal window by using <kbd>Ctl</kbd> - **Click** (or <kbd>Cmd</kbd> - **Click** on a Mac).
79
-
1. In the page displayed, note the workflow running the [end-to-end tests created earlier](./4-testing.md) and [code scanning](../exercises/1-code-scanning.md).
83
+
1. In the page displayed, note the workflow running the [end-to-end tests created earlier][testing-exercise] and [code scanning][security-exercise].
80
84
1. When the workflows complete successfully, select **Merge pull request** to merge your changes into the **main** branch.
81
85
82
86
Congratulations! You've now used the GitHub flow to suggest changes, perform a review, and merge those into your codebase.
83
87
84
88
## Summary and next steps
85
89
86
-
The GitHub flow is a workflow for managing changes and incorporating new features into a codebase. GitHub flow gives you the freedom to explore and experiment, while ensuring all code follows a validation process before being merged. Let's get our [application deployed](./8-deployment.md).
90
+
The GitHub flow is a workflow for managing changes and incorporating new features into a codebase. GitHub flow gives you the freedom to explore and experiment, while ensuring all code follows a validation process before being merged. Let's get our [application deployed][walkthrough-next].
0 commit comments