Git Branch is more flexible, if you use the branch when there is no good plan, will make the branch too much, in the merger when there are various problems, so must be in the team management of the branch have reasonable planning and design, Vincent Driessen An article a successful Git Branching model for us to determine the proper management of the branch, this way has become the default branch management of Git, so the git-flow is also in this way, so we first put this branch management way clear, Next, use the Sourcetree tool to implement Git-flow-based management.
Our branches generally need to be divided into the following
-Master
-Develop
-Feature/xx
-release-0.1.x
-hotfix-v0.1.x
The Master branch is the main branch, which basically does not do any development, just to determine the release version, the develop branch is the branch of management for development, all the new features are based on this branch, and when a new feature is identified, create a feature branch to handle, It is customary to use the Feature/feature name to create a branch, and when this feature is developed and tested and then incorporated into the develop branch, after this version is completed, a release branch is created explaining the version information and fixing some bugs, Merge this branch on Master and hit a tag tag. Next we create a new folder to emulate this branch management model.
Enter directory to execute the following command
Git init
echo A successful git branching model > readme.md
git Add.
Git commit-m "init"
git checkout-b Develop
This completes the Git factory creation and commits the first init version, creating a branch of develop. Now that we have a new feature, we need to build a new branch on the basis of develop to solve it.
git checkout-b feature/base Develop
In the future, all new features will create a branch of the Feature/feature name to develop, in the actual project development, we usually create a basic version, then the team's staff on this basis to develop their own features. After the development has completed this version, merge this branch into the develop branch and delete the branch. Here we need to emphasize the merging branch we use the--NO-FF parameter as much as possible (consider adding this parameter to Git's alias).
E:\teacher\git_teacher\08>git Branch * Develop Master e:\teacher\git_teacher\08>git checkout-b feature/base #创建一 A new branch feature/base to set the basic information switched to a new branch ' feature/base ' E:\teacher\git_teacher\08>echo base >base.txt #添加一
File contents e:\teacher\git_teacher\08>git Add. E:\teacher\git_teacher\08>git commit-m "Finish base" #完成第一个版本的提交 [Feature/base 93DF1FA] Finish base 1 file changed, 1 Insertion (+) Create mode 100644 base.txt e:\teacher\git_teacher\08>git Checkout develop #切换回develop分支 switched to BR Anch ' Develop ' e:\teacher\git_teacher\08>git branch * Develop Feature/base master E:\teacher\git_teacher\08>gi
T merge--no-ff feature/base #合并分支 merge made by the ' recursive ' strategy. Base.txt | 1 + 1 file changed, 1 insertion (+) Create mode 100644 base.txt e:\teacher\git_teacher\08>git branch-d feature/base
#删除feature分支 Deleted Branch Feature/base (was 93DF1FA). E:\teacher\git_teacher\08>git LG #查看日志, if this LG does not have this command, please check the previous lecture * c00ee0a-(HEAD-Develop) Merge branch ' feature/base ' into develop (seconds ago) <ynkonghao> |\ |
* 93df1fa-finish base (6 minutes ago) <ynkonghao> |/* 1703640-(Master) Init (minutes ago) <ynkonghao>
Here we have done the first version of the operation, this version is the basis for all other versions of the development, we can create a release branch, merge it into the Master branch, the release branch We are also created on the Develop branch, Why do you want to create this release branch? This branch is mainly to fix some bugs again before release or to add some key features and functions that explain the release version.
E:\teacher\git_teacher\08>git Checkout-b release-0.0.1 Develop
switched to a new branch ' release-0.0.1 '
e:\ Teacher\git_teacher\08>git Branch
Develop
Master
* release-0.0.1
At this point the branch will continue to be tested for a period of time, and when the test is complete, merge the branch into the master and develop branches, and label the master branch to indicate the meaning of this version, so that it can be quickly rolled back when there is a problem.
E:\teacher\git_teacher\08>mkdir RC #创建一个文件夹来说明不同版本的更新信息
e:\teacher\git_teacher\08>echo "Finish base Fun "> rc/0.0.1 #根据版本的名称创建文件来说明版本信息
e:\teacher\git_teacher\08>git Add.
E:\teacher\git_teacher\08>git commit-m "Release 0.0.1" #提交这次release版本
[release-0.0.1 e9c7ab3] Release 0.0.1
1 file changed, 1 insertion (+)
Create mode 100644 rc/0.0.1
e:\teacher\git_teacher\08>git Checkout Master #切换回master分支
switched to branch ' master '
e:\teacher\git_teacher\08>git merge--no-ff release-0.0.1 # Merges the release-0.0.1 branch merge made by the
' recursive ' strategy on the master branch.
Base.txt | 1 +
rc/0.0.1 | 1 +
2 files changed, 2 insertions (+)
Create mode 100644 base.txt
create mode 100644 rc/ 0.0.1
e:\teacher\git_teacher\08>git tag-a 0.0.1 #为该版本添加一个tag标签, explaining the role of the version
The above operation completes the release of a release version. We will then merge the release-0.0.1 branch onto the develop, and the release branch will have no real value after the merge is complete, and you can delete the branch directly.
E:\teacher\git_teacher\08>git Checkout develop
switched to branch ' develop '
E:\teacher\git_teacher\08 >git Merge--no-ff release-0.0.1
merge made by the ' recursive ' strategy.
rc/0.0.1 | 1 +
1 file changed, 1 insertion (+)
Create mode 100644 rc/0.0.1
e:\teacher\git_teacher\08>git branch-d rel ease-0.0.1
Deleted Branch release-0.0.1 (was e9c7ab3).
After this, our first version was successfully released, and then it was up to the team's developers to do their own different function development, so that each new feature would have to be developed on the basis of the develop branch to create the FEATURE/XX feature branch. What should we do if the code in this version of base is found to be problematic during development? We need to solve this problem by creating hotfix-x.x.x branches, which are created on a master basis and are based on the tag version number, and are used primarily to repair the branches used in the production environment.
E:\teacher\git_teacher\08>git checkout-b hotfix-0.0.2 Master #在master的基础上创建hotfix分支
switched to a new branch ' hotfix-0.0.2 '
E:\teacher\git_teacher\08>echo "hotfix" >> Base.txt
e:\teacher\git_teacher\08> git Add.
E:\teacher\git_teacher\08>git commit-m "update bug in 0.0.1" #完成一次修复并且提交
[hotfix-0.0.2 9d2d416] update bug in 0.0. 1
1 file changed, 1 insertion (+)
e:\teacher\git_teacher\08>git checkout master #切换到master分支
switched to Branch ' master '
e:\teacher\git_teacher\08>git merge--no-ff hotfix-0.0.2 #合并hotfix分支
Merge made by the ' Recursive ' strategy.
Base.txt | 1 +
1 file changed, 1 insertion (+)
e:\teacher\git_teacher\08>git tag-a 0.0.2 #打一个标签0.0.2
The above operation is similar to the release branch, merging to Master and adding a tag, finally merging it into the develop branch and deleting the hotfix branch.
E:\teacher\git_teacher\08>git Checkout develop
switched to branch ' develop '
E:\teacher\git_teacher\08 >git Merge--no-ff hotfix-0.0.2
merge made by the ' recursive ' strategy.
Base.txt | 1 +
1 file changed, 1 insertion (+)
e:\teacher\git_teacher\08>git branch-d hotfix-0.0.2 Deleted
Branch hotfix-0.0.2 (was 9d2d416).
E:\teacher\git_teacher\08>git Branch
* Develop
Master
This is the branch in the development process of a standard mode, git flow is based on this pattern to design a series of commands, we use the process does not necessarily need to follow the Gitflow, Git has a better visual management tool Sourcetree can also use the Gitflow command directly, and we'll talk about how to use Gitflow in Sourcetree in the next chapter.