The use of Git flow

• Brief introduction

The Gitflow workflow defines a rigorous branching model around a project release. Although more complex than the feature Branch workflow, it also provides a solid framework for managing larger-scale projects.

Unlike feature Branch workflow, the Gitflow process does not add any new concepts or commands. The feature is that it assigns very specific roles to different branches and defines usage scenarios and usage. In addition to branching for feature development, it uses separate branches for pre-release preparation, logging, and post-maintenance. Of course, you can still take advantage of the benefits of feature Branch workflow: Pull requests, isolated experiments, and more efficient collaboration.

• Working principle

The process still uses a central code repository, which is the information Exchange Center for all developers. As with other workflows, developers are doing their own development locally, and then pushing the branch code to the central repository. The only difference is the structure of the branch in the project.

　　A branch used to record history

Gitflow uses two branches to record the history of project development, rather than using a single master branch. In the Gitflow process, master is only used to preserve the official release history, while the develop branch is the branch used to integrate various feature development. It is also convenient to use the version number for all submissions on Master (tag).

　

In fact, the Gitflow process revolves around these two distinct branches.

Branches for feature development

Each new feature should be developed using its own separate branch. For backup or collaboration between teams, this branch can also be pushed to the central repository. However, when you create a new feature development branch, the parent branch should select develop (not master). When the feature development is complete, the changed code should be merged (merge) to the develop branch. Functional development should never be directly involved in master.

　　Branches for publishing

Once the develop branch has amassed enough new functionality (or the scheduled release date is near), you can build a branch for the product release based on the develop branch. The creation of this branch means the beginning of a release cycle, and it also means that the release will not add new functionality-only bugs can be fixed on this branch, documentation work, or tasks related to publishing. When everything is ready, the branch is merged into Master and tagged with the version number. Also, the changes on the release branch should be merged into the develop branch-the develop branch is still being used during the release cycle (some developers will integrate other functions into the develop branch). The advantage of using a dedicated branch to prepare for a release is that while one team is busy with the current release, another team can continue to develop new features for the next release.

　　Branches for maintenance

Post-release maintenance or quick fixes for urgent issues also require a separate branch. This is the only branch that can be created directly based on master. Once the problem is fixed, the changes should be merged into the master and develop branches (or for the currently published branch). After that, use the updated version number on master to label it.

　　

• Development examples

Create Develop Branch

　　

The first step is to equip the default master with a develop branch. A simple practice is to have a developer create an empty develop branch locally and then push it to the server.

Git branch Developgit push-u origin Develop

The develop branch will contain all the history of the project, and master will be a reduced version. Now, other developers should clone the central repository and create a tracking branch for develop.

git clone ssh://[email protected]/path/to/repo.gitgit checkout-b Develop Origin/develop

A and B develop new features

　　

Start by developing new features separately. They both set up their own branches. note that when they create the branch, the parent branch cannot select master, and the develop is selected.

git checkout-b some-feature Develop

Both of them work on their own functional development branch. This is usually the Git trilogy: Edit,stage,commit:

Git statusgit add <some-file>git commit

A has developed his function.

　　

After submitting the code a few times, a thinks his function is done. If her team were to use pull requests, it would be a good time-she could propose a request to merge her completed functions into the develop branch. Otherwise, she can merge her code into the local develop branch and then push it to the central repository, like this:

Git pull Origin developgit checkout developgit merge Some-featuregit pushgit branch-d some-feature

The first command ensures that the local develop branch has the latest code-This step must be done before the feature code is merged! Note that the newly developed feature code can never be merged directly into master. If necessary, you also need to resolve conflicts during the code merge process.

A start to prepare A release

　　

Although B is still busy developing his features, a can start preparing for the first official release of the project. Similar to feature development, she used a new branch to prepare for the release of the product. In this step, the release number is also initially determined.

git checkout-b release-0.1 Develop

This branch is dedicated to pre-release preparation, including some cleanup work, comprehensive testing, documentation updates, and any other preparation. It is similar to the branch used for feature development, except that it is dedicated to product publishing.

Once a has created this branch and pushed it to the central repository, the functionality of the product release is fixed. Any feature that is still in the development state can only wait for the next release cycle.

A completed the release

　　

　　

When everything is ready, a will merge the publishing branch into the master and develop branches, and then delete the publishing branch. note that merging to the develop branch is important because developers may have fixed some key issues on the publishing branch that are useful for new features under development. Again, if the team where a is emphasizing code Review, this is a good time to make such a request.

git checkout mastergit merge release-0.1git pushgit checkout developgit merge Release-0.1git pushgit branch-d release-0.1

The role played by the release branch is a buffer between functional development (develop) and official release (master). Whenever you merge something into master, you should immediately put the appropriate tag on it.

git tag-a 0.1-m "Initial public release" Mastergit Push--tags

GIT supports hooks, which means that some pre-defined scripts can be executed when certain events occur in the Code warehouse. As a result, it is possible to configure a hook on the server side, and when you push master to the central repository or push a tag, the GIT server can be automatically built for the release of the product.

　　A bug was discovered by the user

　　

When a release is complete, a goes back to developing other features with B. Suddenly, a user complained that there was a bug in the product currently being released. To solve this problem, a (or b) creates a branch for maintenance based on master. She fixes the bug on this branch and then merges the changed code directly into master.

git checkout-b issue-#001 master# Fix the buggit checkout mastergit merge issue-#001git push

As with the branch used for publishing, it is important that the changes on the maintenance branch be merged into the develop branch. Therefore, the pony must not forget this step. She can then remove the maintenance branch.

git checkout developgit merge issue-#001git pushgit branch-d issue-#001

The detailed process of git flow is described above, but it is cumbersome to develop, and git flow encapsulates it for simplicity.

Use

• Initialize: git flow init

• start new feature: git flow feature start myfeature

• publish a feature (i.e. push to remote): git flow feature publish Myfeature

• get publish feature: git flow feature pull Origin myfeature

• complete a feature: git flow feature finish myfeature

• start a release: git flow release start release [BASE]

• Publish a release: git flow release publish release

• Release Release: git flow release finish release
  Don't forget git push--tags

• Start a hotfix: git Flow hotfix start VERSION [BASENAME]

• release a hotfix: git Flow hotfix finish VERSION

git flow init

This command makes some default configurations that automatically create all the branches described above: master, develop, feature, relase, hotfix, and so on.

After completion, the current branch becomes develop. Any development must start with develop:

　　When developing new features:

Git flow feature start some_awesome_feature

After the feature development is complete:

Git flow feature finish some_awesome_feature

This command merges the feature/some_awesome_feature into the Develope branch and then removes the function (feature) branch.

Push a feature branch to the remote server

When your feature point is complete (a new version needs to be published), a release branch is created based on develop.

When you finish a publishing branch, it merges the changes you made into the master branch and merges back into the develop branch, so you don't have to worry about your master branch being more advanced than the develop branch.

When there is a problem with the system, it is good to create a maintenance (hotfix) branch based on master when urgent changes are needed.

Git flow hotfix start v0.1.0

When you finish a maintenance branch, it merges the changes you made into the master branch and merges back into the develop branch.

The use of Git flow