|
| 1 | +## 5.1 Git branching strategies |
| 2 | + |
| 3 | +So far, we have familiarised ourselves with a few simple workflows when using Git. In this section, we will have a birds-eye view of the branching strategies and discuss the choices. |
| 4 | + |
| 5 | +A note for the term **flow** - since a Git workflow always consists of stashing, commiting, pushing etc., whenever people talk about a Git-related *flow*, it is generally referring to the remaining, more dynamic parts of the workflow, particularly the **branching and merging strategies**. |
| 6 | + |
| 7 | +An organized and efficient workflow choice can be essential to the success of a project. Here we introduce four most common workflows used in Git. |
| 8 | + |
| 9 | +### Centralized workflow |
| 10 | +The simplest case which we have seen in ==Case Study 0==. There is only one branch and all changes are made on this branch. This is a nice and simple way to save *checkpoints* for your own work. |
| 11 | + |
| 12 | +```mermaid |
| 13 | +gitGraph |
| 14 | + commit id: "Initial code" |
| 15 | + commit id: "Some changes" |
| 16 | + commit id: "Some plots" |
| 17 | + commit id: "More changes" |
| 18 | +``` |
| 19 | +However, the centralized workflow does not allow easy collaboration, because every time two people make changes simultaneously, it will create a conflict on the branch. The following workflows can provide a more streamlined collaboration. |
| 20 | + |
| 21 | +### Feature branch workflow |
| 22 | +To overcome the limit with the centralized workflow, we can put a chunk of new work on a dedicated branch. This is what we did in ==case study 2==, and the method has several advantages |
| 23 | +- allows multiple collaborators to work simultaneously on different features, backing up their work along the way |
| 24 | +- no disruption to the code on `main` branch before the feature code is ready, suitable for continuous integration environment |
| 25 | +- allows discussions and assistances for a feature through e.g. pull requests |
| 26 | + |
| 27 | +```mermaid |
| 28 | +gitGraph |
| 29 | + commit |
| 30 | + branch feature1 |
| 31 | + commit |
| 32 | + commit |
| 33 | + checkout main |
| 34 | + merge feature1 |
| 35 | + branch feature2 |
| 36 | + commit |
| 37 | + checkout main |
| 38 | + branch feature3 |
| 39 | + commit |
| 40 | + checkout main |
| 41 | + merge feature3 |
| 42 | + checkout feature2 |
| 43 | + commit |
| 44 | +``` |
| 45 | +The feature branch flow is the conventional workflow for repositories hosted on GitHub (partly because the UIs of GitHub is initially designed around it). Hence, it is also commonly referred to as the *GitHub flow*. |
| 46 | + |
| 47 | +## Gitflow workflow |
| 48 | +The feature branch workflow is great for packages which can have continuous updates, but for many bigger projects, or softwares with a larger user base, it is important to have the concept of *release*. Users will want / need to know which "version number" they are using. |
| 49 | + |
| 50 | +This is where the Gitflow workflow comes in. Building upon the feature branch workflow, it adds several branches with specific roles with rules for when and how to merge. |
| 51 | + |
| 52 | +The main development work happens exactly like in the feature branch workflow, except that the features branch off and merge into the `develop` branch instead of the `main`. When the code in `develop` is ready to be released, the changes are then merged back to the `main`. The commits on `main` are always production-ready, and each has a release number. |
| 53 | + |
| 54 | +```mermaid |
| 55 | +gitGraph |
| 56 | + commit id: "v0.1" |
| 57 | + branch develop |
| 58 | + branch feature1 |
| 59 | + commit |
| 60 | + commit |
| 61 | + checkout develop |
| 62 | + branch feature2 |
| 63 | + commit |
| 64 | + commit |
| 65 | + checkout develop |
| 66 | + merge feature2 |
| 67 | + checkout feature1 |
| 68 | + commit |
| 69 | + checkout develop |
| 70 | + merge feature1 |
| 71 | + checkout main |
| 72 | + merge develop id: "v0.2" |
| 73 | +``` |
| 74 | +Another dedicated branch is the `hotfix` branch, which serves (only) to fix bugs should they appear on the `main`. |
| 75 | + |
| 76 | +```mermaid |
| 77 | +gitGraph |
| 78 | + commit id: "v1.0" |
| 79 | + branch hotfix-1.0.1 |
| 80 | + branch develop |
| 81 | + checkout hotfix-1.0.1 |
| 82 | + commit |
| 83 | + commit |
| 84 | + |
| 85 | + checkout main |
| 86 | + merge hotfix-1.0.1 id: "v1.0.1" |
| 87 | + checkout develop |
| 88 | + merge hotfix-1.0.1 |
| 89 | +``` |
| 90 | + |
| 91 | +Other possible branches include the `release` branches, which is used to prepare for a release (prepare the release metadata, fixing bugs before the release, etc.). |
| 92 | + |
0 commit comments