35 lines
4.2 KiB
Markdown
35 lines
4.2 KiB
Markdown
# A Successful Git Branching Model
|
||
|
||
|
||
|
||
## Metadata
|
||
- Author: [[Vincent Driessen]]
|
||
- Full Title: A Successful Git Branching Model
|
||
- Category: #articles
|
||
- URL: https://nvie.com/posts/a-successful-git-branching-model/
|
||
- Archive: https://web-archive.alecodes.page/bookmarks?bf=1&search=&title=A%20Successful%20Git%20Branching%20Model
|
||
> [!tldr]
|
||
> The Git branching model, git-flow, is widely used but can be seen as overly rigid by some teams. It is beneficial for versioned software and managing multiple versions. Git has revolutionized how developers handle branching and merging in version control.
|
||
|
||
## Highlights
|
||
If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like [GitHub flow](https://guides.github.com/introduction/flow/)) instead of trying to shoehorn git-flow into your team.
|
||
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. [View Highlight](https://read.readwise.io/read/01j548q3y82vb6tgpcxkff732r))
|
||
|
||
We consider `origin/master` to be the main branch where the source code of `HEAD` always reflects a *production-ready* state. [View Highlight](https://read.readwise.io/read/01j548s6wn5tww0q86agt4mc3b))
|
||
|
||
We consider `origin/develop` to be the main branch where the source code of `HEAD` always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from. [View Highlight](https://read.readwise.io/read/01j548sbx0chxzjqhbdxbfkd34))
|
||
|
||
Next to the main branches `master` and `develop`, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
|
||
The different types of branches we may use are:
|
||
• Feature branches
|
||
• Release branches
|
||
• Hotfix branches [View Highlight](https://read.readwise.io/read/01j548v29py8ken2hnj4kqn7d4))
|
||
|
||
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into `develop` (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment). [View Highlight](https://read.readwise.io/read/01j548xe9jrd2c98pd2kch582r))
|
||
|
||
The `--no-ff` flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Compare: [View Highlight](https://read.readwise.io/read/01j548z6jfdzegbyxqcbw9qzg8))
|
||
|
||
Release branches support preparation of a new production release. __They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release__ (version number, build dates, etc.). By doing all of this work on a release branch, the `develop` branch is cleared to receive features for the next big release. [View Highlight](https://read.readwise.io/read/01j54919d0891s3web647x0zkt))
|
||
|
||
Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. __They arise from the necessity to act immediately upon an undesired state of a live production version__. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. [View Highlight](https://read.readwise.io/read/01j5498mt0tq7m5y0gk06rst3t))
|
||
|