GitFlow code versioning

The advantages of Git

Nowadays, most companies’ R&D teams use Git as a code management tool. CVS, SVN, etc., are rarely used. For details on why you choose Git, see git, CVS, AND SVN Comparison. Git has the following advantages:

  1. Git is distributed, and the local repository contains all the content of the remote repository;
  2. Git has an excellent branch model, which is easy to manage.
  3. Because Git code is local, it is easy to branch and merge branches quickly and cheaply.

Of course, there are many advantages of Git, interested, you can take a look at the design of Git itself, the inherent architecture reflects a lot of advantages, worthy of the genius programmer Linus (father of Linux) hands.

GitFlow

Although Git is an excellent version management tool, we still face great challenges in version management. We all know that we work in the same repository, so the code collaboration between each other will inevitably bring many problems and challenges, as follows:

  1. How do I start the development of one Feature without affecting other features?
  2. Since it is easy to create new branches, how to manage more branches, and how to know what each branch is for a long time?
  3. Which branches have been merged back into the trunk?
  4. How to manage Release? How do you freeze features at the beginning of a Release, and how do you Prepare for a Release so that developers can continue working on new features?
  5. Online code has a Bug, how to quickly fix it? And the fixed code has to be included in the developer’s branch as well as the next Release, right?
  6. Most developers now use Git with just three or even two branches, one for Master, one for Develop, and one for each branch that Develops. This can barely be supported when the project is small, because many people only have one Release for the project, but various problems will occur when there are many people and the project cycle is long.

Just as code needs a code specification, so does code management need a clear process and specification. Dutch programmer Vincent Driessen proposed to solve this problemA Successful Git Branching Model. The flow chart is as follows:

  • The Gitflow workflow defines a strict branching model around project release. Although more complex than Feature Branch Workflow, it also provides a solid framework for managing larger-scale projects.
  • Compared to the Feature Branch Workflow, the Gitflow process does not add any new concepts or commands. The distinguishing feature is that it assigns very clear roles to different branches and defines usage scenarios and usages. In addition to branches for feature development, it also uses separate branches for pre-release preparation, documentation, and post-release maintenance. Of course, you can still take advantage of the benefits of Feature Branch Workflow: Pull requests, isolated experiments, and more efficient collaboration.

The common branch of GitFlow

master

  • Master branch. After all functions of the product are realized, the product will be released in master branch.
  • This branch is read-only and unique. It can only be merged from other branches (release/hotfix) and cannot be modified in this branch.
  • In addition, all push in the Master branch should be labeled to record, easy to trace;
  • For example release merged into master, or hotfix merged into master.

develop

  • Main development branch, based on the master branch clone;
  • Contains all code to be released to the next release;
  • This branch is read-only and unique and can only be merged from other branches.
  • The feature branch is complete and merged into develop(no push).
  • Develop the release branch.
  • Once the Release /hotfix branch is live, merge it into Develop and push it.

feature

  • Function development branch, based on the clone of Develop branch, mainly used for the development of new requirements and new functions;
  • After the feature is developed, open it to the Develop branch (do not push it to the remote central warehouse until it is officially launched!!). ;
  • Multiple feature branches can exist at the same time, which is used for the simultaneous development of multiple functions in the team. It is a temporary branch and can be deleted after the function is completed.

release

  • Test the branch, merge it into develop based on the feature branch and clone it from develop.
  • Bugs found during testing will be fixed in the Develop/Master branch. After the bugs are fixed, they will be merged into the Develop/Master branch and pushed (functionality completed)
  • It is a temporary branch and can be deleted after the function is online.

hotfix

  • Patch branch, based on the master branch clone, is mainly used to fix bugs in the online version;
  • After the fix is complete, merge it into the Develop/Master branch and push it to the Tag.
  • It is a temporary branch and can be deleted after patch repair goes online.
  • All hotfix branch changes go into the next release.

The working principle of

The master branch

The master branch is the original branch and the branch used to record history. All commits on the master branch should be tagged. Instead of using a single Master branch, GitFlow uses two branches to document the history of project development. In a Gitflow process, the Master branch is only used to keep the official release history, while the Develop branch is used to integrate the various features. It is also convenient to tag all submissions on master with version numbers. In fact, the Gitflow process revolves around these two distinct branches.

Feature branch

Branch name feature / *

Each new feature should be developed using a separate branch. Such branches can also be pushed to a central repository for backup or collaboration between teams. However, when creating a new feature development branch, the parent branch should select Develop (not Master). When feature development is complete, the changed code should be merged into the Develop branch. Feature development should never involve the Master directly.

The Release branch

Branch name release / *

The Release branch is based on the Develop branch. After the Release, you can test on the Release branch, fix bugs, and so on. At the same time, other developers can develop new features based on them. (note: Do not merge new changes from the Develop branch to the Release branch once you have made the Release branch.) When releasing the Release branch, merge the Release to the Master and Develop branch and Tag the Master branch to remember the Release version number. Then you can delete the Release branch.

Hotfix branch

Branch name hotfix / *

The Hotfix branch is a maintenance branch based on the Master branch. A separate branch is also required for post-release maintenance or quick fixes for urgent problems. This is the only branch that can be created directly from master. Once the problem is fixed, the changes should be merged into the Master and Develop branches (or the branch for the current release). After that, the master will be tagged with the updated version number.

Main work process

  1. Initialize the project as gitFlow, create the master branch by default, and then pull the first Develop branch from the master.
  2. Develop code from the develop feature branch (multiple developers pull multiple features for parallel development at the same time, without affecting each other);
  3. After the feature branch is completed, merge it into Develop (no push, feature feature has not been tested yet, push will affect the development of other feature branches).

The current feature cannot be changed and must be modified from the Release branch. Pull and test from the Develop release branch, and fix bugs on the Release branch during the lift test. 5. After the release branch is online, merge the Release branch to develop/ Master and push the release branch. After the merge, you can optionally delete the current Release branch. The hotfix branch must be pulled from the master if there is a problem online. 6. If online bugs are found, pull hotfix from master for BUG modification; 7. After hotfixes pass the test, merge the hotfixes branch to Master/Develop and push the hotfixes. After the merge, you can delete the current hostfix. You need to pull a new hotfix from the master. If a feature changes, merge the new features into your own branch if another developer has completed the new feature. 9. When making a release branch, if the Develop branch changes, such as other developers completing features and going live, you need to merge the completed features into your own branch, that is, merge Develop into the current Release branch (!!! Because the current Release branch passes the test and is published online, if you don’t merge the latest Develop branch, you lose code. 10.

GitFlow process command code example

General command code

Create the Develop branch

An easy way to give the default Master a Develop branch is to have a developer create an empty Develop branch locally and push it to the server. The Develop branch will contain all the history of the project, while the Master will be an abbreviated version. Other developers should now clone the central repository and create a trace branch for Develop.

git branch develop
git push -u origin develop
Copy the code

Start new Feature development

When we started to develop new features, we each had to branch out. Note that when you create a branch, the parent branch cannot select Master, but develop.

git checkout -b some-feature develop # Optionally, push branch to origin: Git push -u origin some-feature # git status git add some-file git commitCopy the code

Complete Feature

When the new functionality is developed, you need to merge the code into the Develop branch and remove the feature branch.

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature   
Copy the code

Began to Relase

When feature development is complete, a branch should be created to handle the production code release. This branch is dedicated to pre-release preparation, including some cleanup, thorough testing, documentation updates, and any other preparatory work. It is similar to the branch for feature development, except that it is dedicated to production code release. Once the branch is created and pushed to a central repository, the functionality contained in the product release is fixed. Any features that are still in development will have to wait for the next release cycle.

Git checkout -b release-0.1.0 Develop # Optional: Bump version number, commit # Prepare release, commitCopy the code

Complete Release

Once everything is ready, merge the publishing branch into the Master and Develop branches, tag the Master branch with the appropriate tags, and then delete the publishing branch. Note that merging into the Develop branch is important because the developer may have fixed key issues on the release branch that would benefit from new functionality under development. Again, if the A feature team emphasizes Code Review, this is A great time to ask for this.

Git checkout master git merge --no-ff release -- 0.1.0 Push Git branch -d release-0.1.0 # If you pushed branch to Origin: Git push origin --delete release-0.1.0 git tag -a v0.1.0 master Git push --tagsCopy the code

Start Hotfix

If a bug is found online, create a maintenance branch from the master branch to fix the bug online.

Git checkout -b hotfix-0.1.1 masterCopy the code

Complete the Hotfix

Once the bug is fixed, merge the code into the Master/Develop branch, Tag the master, and remove the maintenance branch.

Git checkout master git merge --no-ff hotfix 0.1.1 Git branch -d hotfix-0.1.1 Git tag -a v0.1.1 Master Git push --tagsCopy the code

GitFlow command code

  • Initialization:git flow init

This command does some default configuration and automatically creates all the branches described above: Master, Develop, feature, relase, hotfix, and so on. Once you’re done, the current branch becomes Develop. Any development must start with Develop.

  • To start a new Feature:git flow feature start MYFEATURE

This command creates a feature branch

  • Complete a Feature:git flow feature finish MYFEATURE

This command will merge the feature/MYFEATURE into the develope branch and then delete the feature branch.

  • Publish a Feature(i.e. push to remote server):git flow feature publish MYFEATURE
  • Get Publish Feature:git flow feature pull origin MYFEATURE
  • Start a Release:git flow release start RELEASE BASE
  • Publish the Release:git flow release finish RELEASE

When a release branch finishes, it merges all of its changes to the Master branch and back to develop, so there’s no need to worry that the Master branch is ahead of the Develop branch.

  • Publish a Release:git flow release publish RELEASE
  • Label carefullygit push --tags
  • Start a Hotfix:git flow hotfix start VERSION BASENAME
  • Release a Hotfix:git flow hotfix finish VERSION

When a maintenance branch finishes, it merges all changes to the Master branch and back to the Develop branch.