This approach of one long-lived branch doesn’t mean that there aren’t other branches involved using it. In comparison to the GitFlow model, the direct difference is the absence of the “develop” branch. OneFlow consists of having only one eternal branch – “master”. This adds all the changes that were made inside the hotfix to the feature branch, but only those changes. After merging, the branch is then tagged accordingly as well. It can be merged directly into MASTER if necessary. Hotfixes can bypass the process of having to go through DEV. At this time, the branch is no longer needed, and it can be deleted. The GitFlow model asks you to merge the hotfix also to the development branch, which is feature1 in your case. These are done by creating a hotfix branch from the faulty branch, applying the changes, and merging the hotfix branch back into its original branch. Finally, when the release is ok, a merge to “master” is done and a Tag version is built. Some bug fixing could be made over this kind of branch, but when the fix is done, it must be incorporated back on the “develop”. When a release is about to be prepared, a “release” branch should be created using the HEAD of “develop” as a baseline. Besides, all hotfixes are conceived using the “master” branch as a baseline and must be merged back to “master” when the fix is done – those changes must be merged simultaneously to “develop”.
Edit: You might as well want to use the -s or -u
git checkout master Switched to branch 'master' git merge -no-ff hotfix-1.2.1 Merge made by recursive.
#Hotfixes in master git update#
All features (“feature” branches) are established using the “develop” branch as a baseline and, when features are done, they are merged back to be developed. First, update master and tag the release.
The main vision of this branching modelis that a “master” is created and then, taking it as a baseline, the “develop” branch is initially formed.
0 kommentar(er)
