In the development process of large-scale software engineering projects, many problems related to git are often encountered, especially branch management and merging when multiple people collaborate, and code management chaos for testing and development. These problems often lead to extremely confusing commit records and even lost code. Git Flow came into being, providing a standardized branch management process.
This blog briefly summarizes the use posture of Git Flow, and also records a little bit of the problems and solutions encountered by tossing Git and Git Flow.
What problem Git Flow solved
- Different roles can be developed in parallel, keeping the isolation between roles as much as possible
- A stable source of code for the production environment
- Align with the DevOps development process
Branches in Git Flow
- For the development of different features when multiple people collaborate, there can be more than one
- Based on the develop branch, merge directly back into the develop branch
- It can be deleted after the merge is complete
- There is only one, which serves as a baseline branch for development
- Contains all the code you want to publish to release
- Bug fixes caused by merging the Feature branch and the Release branch
- CI/CD corresponding to the test environment
- Large-scale development is often a read-only branch and only accepts PRs from the Feature/Release Branch
- Corresponding to the pre-release environment CI/CD (sometimes called UAT (User Acceptance Test) environment in practice)
- Merge the develop branch, complete the test, fix the bug
- Contains all the code you want to publish to the master/main branch
- Emergency bug fix branch after the feature goes live
- After the fix is complete, add the PR to the master/develop branch
- Master branch, read-only. Only accept PRs from other branches
- When pushing, you need to play git tag to do version tracking
Git initinitializes the project and
checks outthe first
- Multiple developers
check out, forming multiple
- After the feature is developed,
- After all functions are developed in the current stage, check
the developbranch to start Release.
- After completing testing, release configuration, and minor bug fixes, create tags and
- Release production code from the master branch
- If a bug is found, the
hotfixbranch is checked
outbased on the master branch to fix the bug.
developbranch and type tag.
- If a bug is found, the
- It is strictly forbidden to use
git rebaseto merge code on several public branches (master, release, develop).
Git mergeis used, and
--no-ffis recommended to ensure that changes to each
mergecan be clearly tracked.
- On private branches, such as your own feature branch, you can use
git rebaseto synchronize the progress of the