... | ... | @@ -61,7 +61,7 @@ this, so that theoretically, we could use a Git hook script to |
|
|
automatically build and roll-out our software to production servers
|
|
|
every time there was a commit on `master`.
|
|
|
|
|
|
####### Supporting branches
|
|
|
##### Supporting branches
|
|
|
|
|
|
|
|
|
Next to the main branches `master` and `develop`, our development model
|
... | ... | @@ -86,7 +86,7 @@ By no means are these branches “special” from a technical perspective. |
|
|
The branch types are categorized by how we *use* them. They are of
|
|
|
course plain old Git branches.
|
|
|
|
|
|
####### Feature branches
|
|
|
##### Feature branches
|
|
|
|
|
|
May branch off from: `develop`\
|
|
|
Must merge back into: `develop`\
|
... | ... | @@ -105,7 +105,7 @@ case of a disappointing experiment). |
|
|
Feature branches typically exist in developer repos only, not in
|
|
|
`origin`.
|
|
|
|
|
|
####### Creating a feature branch
|
|
|
##### Creating a feature branch
|
|
|
|
|
|
When starting work on a new feature, branch off from the `develop`
|
|
|
branch.
|
... | ... | @@ -133,7 +133,7 @@ avoids losing information about the historical existence of a feature |
|
|
branch and groups together all commits that together added the feature.
|
|
|
|
|
|
|
|
|
####### Release branches
|
|
|
##### Release branches
|
|
|
|
|
|
May branch off from: `develop`\
|
|
|
Must merge back into: `develop` and `master`\
|
... | ... | @@ -154,7 +154,7 @@ future releases may not — they must wait until after the release branch is |
|
|
branched off.
|
|
|
|
|
|
|
|
|
######## Creating a release branch
|
|
|
###### Creating a release branch
|
|
|
|
|
|
Release branches are created from the `develop` branch. For example, say
|
|
|
version 1.1.5 is the current production release and we have a big
|
... | ... | @@ -183,7 +183,7 @@ this branch (rather than on the `develop` branch). Adding large new |
|
|
features here is strictly prohibited. They must be merged into
|
|
|
`develop`, and therefore, wait for the next big release.
|
|
|
|
|
|
######## Finishing a release branch
|
|
|
###### Finishing a release branch
|
|
|
|
|
|
When the state of the release branch is ready to become a real release,
|
|
|
some actions need to be carried out. First, the release branch is merged
|
... | ... | @@ -224,8 +224,7 @@ don’t need it anymore: |
|
|
$ git branch -d release-1.2
|
|
|
Deleted branch release-1.2 (was ff452fe).
|
|
|
|
|
|
####### Hotfix branches
|
|
|
|
|
|
##### Hotfix branches
|
|
|
|
|
|
May branch off from: `master`\
|
|
|
Must merge back into: `develop` and `master`\
|
... | ... | @@ -242,7 +241,7 @@ production version. |
|
|
The essence is that work of team members (on the `develop` branch) can
|
|
|
continue, while another person is preparing a quick production fix.
|
|
|
|
|
|
######## Creating the hotfix branch
|
|
|
###### Creating the hotfix branch
|
|
|
|
|
|
Hotfix branches are created from the `master` branch. For example, say
|
|
|
version 1.2 is the current production release running live and causing
|
... | ... | |