Use of git flow and gitflow

Use of git flow and gitflow

• Introduction

Gitflow workflow defines a strict branch model around project release. Although it is more complex than Feature Branch Workflow, it also provides a solid framework for managing larger projects.

Compared with Feature Branch Workflow, Gitflow does not add any new concepts or commands. It assigns clear roles to different branches and defines use cases and usage. In addition to the branches used for function development, it also uses independent branches for pre-release preparation, recording, and post-maintenance. Of course, you can still make full use of the benefits of Feature Branch Workflow: Pull requests (Pull requests), isolated experiments, and more efficient cooperation.

• Working Principle

The process still uses a central code repository, which is the information exchange center for all developers. Like other workflows, developers can complete local development and then push the branch code to the central repository. The only difference is the branch structure in the project.

　　Branch used to record history

Gitflow uses two branches to record the project development history, rather than a single master branch. In the Gitflow process, the master is only used to save the official release history, and the develop branch is used to integrate various functions for development. It is also convenient to use the version number to tag all commits on the master.

　

In fact, the Gitflow process is centered around these two distinctive branches.

Branch used for function development

Each new function should be developed using an independent branch. To back up data or facilitate collaboration between teams, such branches can also be pushed to the central repository. However, when creating a new function development branch, the parent branch should select develop instead of master ). When the function development is complete, the changed code should be merged (merge) to the develop branch. Function development should never directly involve the master.

　　Branch used for release

Once the develop branch has accumulated enough new features (or the scheduled release date is approaching), you can create a branch for product release based on the develop branch. The creation of this branch means the beginning of a release cycle, and it also means that no new features will be added in this release-only bugs can be fixed on this branch, and some documentation or release-related tasks can be done. When everything is ready, this branch will be merged into the master and tagged with the version number. In addition, changes to the Production Branch should also be merged into the develop branch-during the release cycle, the develop branch is still in use (some developers will integrate other functions into the develop branch ). The advantage of using a dedicated branch to prepare for release is that while one team is busy with the current release, another team can continue to develop new features for the next release.

 

　　Branch used for maintenance

An independent branch is also required for post-release maintenance or quick fixing of urgent problems. This is the only branch that can be directly created based on the master. Once the problem is fixed, the changes should be merged into the master and develop branches (or used for the currently released branches ). After that, the updated version number will be used on the master to lay the tag.

　　

• Development Instance

Create a develop Branch

　　

 

The first step is to assign a develop branch to the default master. A simple method is to allow a developer to create an empty develop branch locally and push it to the server.

git branch developgit push -u origin develop

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

git clone ssh://user@host/path/to/repo.gitgit checkout -b develop origin/develop

A and B develop new functions

　　

 

Start to develop new functions separately. They both created their own branches.Note:When creating a branch, the parent branch cannot select master but develop.

git checkout -b some-feature develop

Both of them work on their own feature Development Branch. This is usually the Git trilogy: edit, stage, commit:

git statusgit add <some-file>git commit

A has developed his functions.

　　

 

After several times of code submission, A thought that his function was complete. If her team uses "pull requests", this is the right time-she can make a request to merge all her 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 merging the function code!Note:The newly developed function code can never be directly merged into the master. When necessary, you also need to resolve conflicts during code merging.

AStart preparing for a release

 

　　

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

git checkout -b release-0.1 develop

This branch is designed for pre-release preparation, including cleanup, comprehensive testing, document updates, and any other preparations. It is similar to the Branch used for function development, except that it is designed for product release services.

Once A creates this branch and pushes it to the central repository, the features included in this product release will be fixed. Any function that is still in the development status can only wait for the next release cycle.

A finished release

　　

 

　　

After everything is ready, A will merge the Production Branch into the master and develop branches, and then delete the Production Branch.Note:Merge to the develop branch is very important, because developers may fix some key issues on the release branch, and these fixes are useful for new features under development. Once again, if A's team emphasizes Code Review, it would be very appropriate 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 function development (develop) and the official release (master. Whenever you merge something into the master, you should immediately add the appropriate tag.

git tag -a 0.1 -m"Initial public release" mastergit push --tags

Git supports the hook function. That is to say, you can execute some predefined scripts when some specific events in the code repository occur. Therefore, a feasible method is to configure a hook on the server side. When you push the master node to the central repository or push the tag, the Git server can automatically build the product release.

　　The user found a bug.

　　

After A release is completed, A goes back to develop other functions with B. Suddenly, a user complained that there was a bug in the current product. To solve this problem, A (or B) creates A branch for maintenance based on the master. She fixed the bug on this branch and then merged the changed code into the master.

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

Like the Branch used for release, changes to the Maintenance Branch also need to be merged into the develop branch, which is very important! Therefore, the pony must not forget this step. Then, she can delete the Maintenance Branch.

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

The above describes the detailed process of git flow, but it is difficult to develop it. git flow encapsulates it and simplifies it.

Use

• Initialization:Git flow init

• Start new Feature:Git flow feature start MYFEATURE

• Publish a Feature (that is, push to remote ):Git flow feature publish MYFEATURE

• Obtain the Feature of Publish: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:Git flow release finish RELEASE
  Don't forget git push -- tags

• Start a Hotfix:Git flow hotfix start VERSION [BASENAME]

• Publish a Hotfix:Git flow hotfix finish VERSION

git flow init

This command performs some default configurations and automatically creates all the branches described above, such as master, develop, feature, relase, and hotfix.

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 function is developed:

git flow feature finish some_awesome_feature

This command combines feature/some_awesome_feature into the develope branch, and then deletes the feature branch.

Push a feature Branch to a remote server

Git flow feature publish some_awesome_feature or git push origin feature/some_awesome_feature

When all your function points are completed (new versions need to be released), you can create a release branch based on develop.

git flow release start v0.1.0 

When you finish a Production Branch, it will merge your modifications to the master branch and merge them back to the develop branch, you do not need to worry that your master node is more advanced than the develop branch.

When there is a problem with the system and urgent modifications are required, you can create a maintenance (hotfix) branch based on the master.

git flow hotfix start v0.1.0

When you finish a Maintenance Branch, it will merge your modifications to the master branch and merge them back to the develop branch.

Reference blog: http://www.cnblogs.com/cnblogsfans/p/5075073.html