1. Working with branches
Now we can modify a repo, let's discuss how to work with branches.
2. Branches
As a reminder, branches are used for concurrent work on different parts of a project. They can also reduce the risk of conflicting versions of files.
For example, we may analyze Spanish soccer data in a branch called la liga, while a colleague analyzes English Premier League data in a branch called premier league.
3. Main branch
When we create our repo, there will be one branch called main. In our repo's Code section, we can see which branch we are currently located in.
4. How many branches?
We can check how many branches our repo contains by looking at this icon, confirming we have one branch.
5. Creating a new branch
We click on this icon if we want to create a la liga branch.
6. Creating a new branch
This lists all branches. Notice main is the Default branch, meaning it was created when we made the repo.
We then click the New branch button on the right.
7. Creating a new branch
This opens a pop-up window.
We enter a branch name, la liga. The name should describe the scope of what it will be used for, such as dev or testing.
We can also choose the branch source, which is what GitHub uses to create the new branch. As we only have main, we ignore this step. Lastly, we select Create branch.
8. Creating a new branch
We now see la liga in our branch list.
9. Adding a file
We have produced a line plot of the average home and away goals per team in La Liga, which we've added to the branch.
10. Listing branches
We can check that it only exists in this branch by switching back to main.
We see there are two branches.
11. Switching branches
Clicking the arrow next to la liga produces a dropdown menu showing our active branches and confirms that main is our Default branch.
12. Switching branches
We select main to switch to it.
13. Comparing branches
Here, we see that the second la liga visualization is not in this branch.
14. Working with branches
If we're working on a small solo project, we can probably work exclusively on the main branch.
However, if we are collaborating, we use branches to work on different project tasks simultaneously. This means that, generally, the main branch holds the final versions of our files. We only incorporate contents from other branches into main once we are finished and know there are no issues.
15. Branch protection rules
GitHub offers a way to enforce rules for how we use specific branches.
For example, we can require a pull request, which we will discuss later, before branches can be merged. This adds a layer of protection against bringing incorrect code into our main branch.
We can also set a rule requiring pull requests to be approved before a merge can occur, which may help improve code quality.
We might also restrict who can delete a protected branch.
16. Branch protection rules
To add rules, we select the Settings tab of our repo.
17. Branch protection rules
We choose the Branches section.
18. Branch protection rules
This shows us our Default branch and has a section called Branch protection rules.
We click the Add rule button.
19. Adding rules
The first step is to add a name for our rule in the Branch name pattern section, which is mandatory.
We call ours protect main.
20. Require a pull request
We have many options, but let's enable the two we discussed previously.
We click Require a pull request before merging.
This expands the section and, by default, selects the Require approvals section. We can edit the required number of approvals using the dropdown menu underneath, but for now, we'll leave this as one.
21. Saving the rule
Lastly, we click Create at the bottom of the page to save our new rule.
22. Let's practice!
Now let's practice working with branches!