git flow comes from a successful git branching model, which uses a front-end project to implement Git flow with this document and document the process for presentation and reference, with a slight reference to hotfix and continuous deployment, intended to be used as a company The internal technology Amway.
The source code used and the documentation itself is found in GitHub Jusfr/hellogitflow
Objective
Gitflow is a GIT branch management tool that is not thought too, it uses established strategies to differentiate and manage code versions of development, testing, production environments, and is friendly to testing and continuous integration, consistent with agile, iterative thinking.
1 Preparatory work
1.1 Creating a blank directory
mkdir HelloGitflowcd HelloGitflow
1.2 Start current directory work, example create and save a index.html
<! DOCTYPEHtml><Html lang="EN" xmlns="Http://www.w3.org/1999/xhtml"><Head><Meta charset=" utf-8 " /> <title></ Title></head><body> <div></div></body></HTML>
git add index.htmlgit commit -m "init commit"
2 Git Flow Init
git flow init
The default configuration is used here, all the way next
3 A complete development cycle
3.1 Task Disassembly, example added branch about and navigation
git flow feature start aboutgit flow feature start navigation
Task disassembly is equivalent to story claiming, and the steps in actual development are more cumbersome.
3.2.1 About Branch Creates a about.html
git checkout feature/about# more work to dogit add about.htmlgit commit -m "add about.html"
The 3.2.2 Navigation Branch creates a nav.html
git checkout feature/navigation# more work to dogit add nav.htmlgit commit -m "add nav.html"
3.3 Start Merging branches
3.3.1 Merger about
git flow feature finish about
3.3.2 Merge navigation, there is a merge process
git flow feature finish navigation
Version 3.4 released
3.4.1 Release released when feature cumulative quantity reached can be release
git flow release start v0.1
3.4.2 part of the content needs to be modified, here to add the title for each page
git add index.html about.html nav.htmlgit commit -m "add title for each page"
3.4.3 End current Release branch
# git push git flow release finish v0.1
4 Continuous development cycle
We start working on the remote branch and can push it to the remote branch before ending the branch to avoid local retention
git remote add github https://github.com/jusfr/HelloGitflow.gitgit push github --all
Although many branches are opened, you can observe master and merge two times, and are marked as v0.1 and v0.2, respectively.
Regardless of the test, the master version of the tag v0.1 and v0.2, or release/v0.1 and release/v0.2 are all versions that you can deploy.
Bug fixes on the 5 line
The branch development of account and react is now based on v0.2, but it is found that the v0.2 version on the line needs to be fixed immediately, branching status
Turn on hotfix/v0.2.1 to fix this problem
bash git flow hotfix start v0.2.1
From the hotfix/v0.2.1 point of view, it is checkout down from the nearest Mater branch, so there is no impact on the ongoing account and react
From a global point of view, hotfix/v0.2.1 and account and react do not intersect.
Now fix the problem, merge hotfix/v0.2.1
bash git flow hotfix finish ‘v0.2.1‘
Of course, you can still push to the remote branch first, and you can see that there are several steps
- Merge hotfix/v0.2.1 to Master Branch, Master branch is tagged with v0.2.1
- Merge master to develop branch.
In the 2nd step, if develop has changed, such as a feature merge, there may be conflicts that need to be resolved
In this example, Master was tagged with v0.1, v0.2, and v0.2.1, which is very friendly to master-based continuous deployment: it can be quickly deployed and rolled back in these versions, without worrying about how many changes and branches exist, and so on.
Practice Git flow from a front-end project with reference