Click to read the original text
Abstract: When I created a new project today, I found that in addition to the original `branch mode`, `rdc` also added `master branch development mode` and `git flow mode`, which is a very gratifying thing - after all `git flow` is a long-standing and generally accepted development model.
Introduction
When I built a new project today, I found that rdcin addition to the original one 分支模式, I also added master分支开发模式and git flow模式, this is a very gratifying thing - after all, it is git flowa development model that has been around for a long time and is generally accepted by everyone.
So I deleted the app and switched to git flowmode, and the experience is perfect so far.
Since many people may not know much about git flowit, this article will share some minor experiences.
foreword
Do you use git?
I believe most of you here will confidently answer: "Yes".
In fact, everyone may never consider whether their usage is really scientific and really robust, especially when the project is getting bigger and bigger, the number of people is increasing, and the cycle is getting longer and longer.
Among them, the typical problems are as follows:
- When I was in the middle of developing a feature, PM suddenly assigned me a new urgent task. How can I start this task without affecting the current one?
- When my code is written, how do I publish it?
- When I posted, the code went wrong, how can I fix it quickly?
- In the above situation, it is also required to include all the code developed later after the repair?
When most developers use git, they basically only use two or even one branch, so the following concepts obviously open the door to a new world.
plan
Obviously, not only the code has code specifications, but also the management and coordination of the code needs a clear process and specification. Therefore, the general solution in the industry is Git Flow.
How about it, dazzling, but I can give you a suggestion: turn your head 90 degrees to the left, don't be in a hurry to scold... This is office picture, not drawn by me.
In the above picture, the top row represents branches, which are
|Name|Explanation
|-|-
|master|The code of this branch recently released to the production environment, the recently released Release, this branch can only be merged from other branches, and cannot be modified directly in this branch
|Develop|This branch is we are us The main development branch contains all the code to be released to the next Release. This is mainly merged with other branches, such as Feature branch
|Feature|This branch is mainly used to develop a new feature. Once the development is completed, we merge it back into the Develop branch Go to the next Release
|Release|When you need to release a new Release, we create a Release branch based on the Develop branch. After the Release is completed, we merge it into the Master and Develop branches
|Hotfix|When we find new bugs in Production , we need to create a Hotfix, after completing the Hotfix, we merge back to the Master and Develop branches, so the changes of the Hotfix will enter the next Release.
Implementation details
master branch
To work on the master branch, we need to follow a basic principle, all on the masterbranch commitshould tag.
feature branch
featureAfter the branch is completed, it must be merged back to developthe branch. After merging the branch, the branch will generally be deleted feature, but we can also keep it
Start the development of a new feature
git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature
# 做一些改动
git status
git add some-file
git commit
Development completed
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
release branch
The branch name release/* branch is created releasebased on the branch. After the branch is completed, we can test, modify , etc. on this branch. At the same time, other developers can develop new ones based on it. Once branched, do not merge into and from the release branch, and at the same time mark the branch to remember the version number, and then delete the branch (of course, you can choose not to delete it). ).developreleasereleasebugfeaturereleasedevelop分支上合并新的改动到Release分支releasereleasemasterdevelopmastertagreleaserelease
start release
git checkout -b release-0.1.0 develop
# Optional: Bump version number, commit
# Prepare release, commit
complete release
git checkout master
git merge --no-ff release-0.1.0
git push
git checkout develop
git merge --no-ff release-0.1.0
git 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 --tags
hotfix
The branch name hotfix/* The branch is created hotfixbased on the branch. After the development is completed, it needs to be merged back to the branch, and amastermasterdevelopmastertag
start hotfix
git checkout -b hotfix-0.1.1 master
complete hotfix
git checkout master
git merge --no-ff hotfix-0.1.1
git push
git checkout develop
git merge --no-ff hotfix-0.1.1
git push
git branch -d hotfix-0.1.1
git tag -a v0.1.1 master
git push --tags
tool
If you can insist on seeing this, I am really happy for you, which shows that you have studied hard and are not afraid of danger. After all, the long list of codes above may have made you feel intimidated.
And obviously, as a general solution, it is impossible to be so cumbersome, then, the only possibility is - there is! work! Tool!
| OS X | brew install git-flow |
| Linux | apt-get install git-flow |
| Windows | wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh |
| IDEA | Git Flow Integration |
There are also a large part of gui, which is relatively simple, and will not be repeated in this article. The following focuses on the use of the command line
- Initialization: git flow init
- Start a new Feature: git flow feature start MYFEATURE
- Publish a Feature (that is, push to the remote): git flow feature publish MYFEATURE
- Get Feature of Publish: git flow feature pull origin MYFEATURE
- Finish a Feature: git flow feature finish MYFEATURE
- Start a Release: git flow release start RELEASE [BASE]
- Publish一个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]
- Publish a Hotfix git flow hotfix finish VERSION
If you look closely, these commands are well established, and they can probably be represented as shown in the following figure.
