ZuoPengFei 2017.8.27
A, gitflow
- 1. Gitflow defines a strict branching model around project releases
- 2. Gitflow still uses the central repository as the interaction hub for all developers.
Gitflow schematic
What branches does Gitflow include
- Master: indicates the master branch of the maseter, which stores the history of official releases. It’s released with a tag, which is the version number
- Hotfix: debug branch, bug urgent repair branch
- Release: release branch, used when a release goes live
- Develop as a collection of features
- Feature: Feature branch. Every time a new feature is developed, there will be corresponding feature branch and several different feature branches at the same time
- The Develop branch comes from the master trunk checkout
- The feature branch is merged back to the Develop branch after the feature branch is developed
- At the same time, there may be multiple feature branches to handle different functions
- When the Develop branch reaches a milestone, it needs to merge into the Release branch for QA regression testing and, if there are no problems, merge back into the master trunk and release a version on the trunk
- When an emergent bug occurs on the line, you can merge the hotfix branch from the master trunk. After the bug is fixed, the merge trunk releases a new emergent version. Then the Hotfix branch needs to be merged into the Develop branch because the Develop branch needs to be in sync with the Master branch
- The Hotfix, Release, and Feature branches can be removed once they have completed their mission, while the Master and Develop branches remain
Four, the difference between historical branch and functional branch
Branch of history
Instead of just one master branch, the Gitflow workflow uses two branches to record the history of the project. The Master branch stores the official release history, while the Develop branch acts as the integration branch for functionality. This also makes it easier for all commits on the Master branch to be assigned a version number.
The basic concept
Each new function is located in its own branch, which can be pushed to a central repository for backup and collaboration. But instead of pulling a new branch from the Master branch, the functional branch uses the Develop branch as its parent. When the new functionality is complete, merge back into the Develop branch. New feature submissions should never interact directly with the Master branch. The feature branch is typed from Develop.
- New feature submissions should never interact directly with the Master branch.
- Branch name feature/[feature name]
The working process
- Use the Develop branch as the parent,
- Each new feature is in its own branch
- Once the new functionality is complete, merge it back into the Develop branch.
- You can initiate a feature branch from the Develop branch
- The code must be merged back into the Develop branch
- Feature branches can be named using any name except master, Develop, Release -*, hotfix-*
- The feature branch (sometimes referred to as the “topic branch”) is usually used when developing a new software feature, and code changes on this branch are eventually merged back into the Develop branch or simply discarded (for example, experimental and ineffective code changes).
- In general, feature branching code can be kept in the developer’s own code base without being forced to commit to the main code base.
Release branch
The Release branch is designed for releasing new product versions. The code on this branch allows for minor bug fixes, all the instructions (version number, release date, compile time, and so on) needed to prepare the release. By doing this on the Release branch, you can free up the Develop branch to accept code submissions on the new feature branch and start a new software development iteration cycle.
When you need a Release branch
When the code on the Develop branch contains all of the software functionality planned for the upcoming release and has passed all of the tests, it is time to consider creating the Release branch. All business requirements outside of the current upcoming release must be made sure that they are not mixed into the Release branch (so as not to introduce uncontrollable system defects).
- You can derive from the Develop branch and use the Develop branch as a parent.
- This branch should only do bug fixes, document generation, and other release-oriented tasks.
- Once the release is complete, the release branch should be merged into the Master branch and tagged with a version number.
- Changes made since the new release branch are merged back into the Develop branch.
- Branch naming convention: release-*
- Release /[Release version No.]
- Current release branch name: bug fix release – bugfix – [Version No.] / [bug name | bugs No.]
After the release of
Once the Release branch is successfully derived and given a version number, the Develop branch is ready to serve the “next version.” A “next release” is a release that follows the current upcoming release. The version number can be named according to the version number naming rules defined by the project.