A Git Workflow Model or Branching Strategy
0 likes1,003 views
Vivek Parihar is a serial entrepreneur and polyglot engineer who currently serves as VP of Engineering at XOXODay. He has co-founded two startups and previously served as Head of Engineering for Mobile at Yatra. When not working, he enjoys extreme thrill-seeking adventures like trekking and boxing. The document then outlines Gitflow, a branching model for managing code development, including feature branches for new features, release branches to prepare releases, and hotfix branches for urgent bug fixes in production.
![Creating a release branch
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)
Finishing a release branch
The first two steps in Git:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2 The release is now done, and tagged for future reference.
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
To keep the changes made in the release branch, we need to merge those back into develop, though.
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.](https://image.slidesharecdn.com/agitworkflowmodel-190719003425/85/A-Git-Workflow-Model-or-Branching-Strategy-12-320.jpg)
![Creating the hotfix branch
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)
Then, fix the bug and commit the fix in one or more separate commits.
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)](https://image.slidesharecdn.com/agitworkflowmodel-190719003425/85/A-Git-Workflow-Model-or-Branching-Strategy-14-320.jpg)
A Git Workflow Model or Branching Strategy
- 2. ➔ I’m a Serial Entrepreneur(Co-founded 2 startups) Currently serves as VP oF Engineering at XOXODay ➔ Ex-Head’s Engineering for Mobile @ Yatra's all verticals. ➔ A Polyglot Engineer*. Big fan of The Law of “T” ➔ A staunch supporter of Open Source. ➔ Public Speaker ➔ A mad Geek and an Explorer. When not scaling the applications or servers of the Internet world, I ‘unwinds’ on extreme thrill-seeking adventures from trekking to boxing. Get in touch with me: LinkedIn:https://in.linkedin.com/in/pariharvivek Twitter: @vparihar About Me
- 6. Supporting branches Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually. The different types of branches we may use are: ● Feature branches ● Release branches ● Hotfix branches
- 7. May branch off from: develop Must merge back into: Develop Branch naming convention: anything except master, develop, release-*, or hotfix-* Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. The essence of a feature branch is that it exists as long as the feature is in development Eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment). Feature branches typically exist in developer repos only, not in origin Feature branches
- 8. Creating a feature branch When starting work on a new feature, branch off from the develop branch. $ git checkout -b myfeature develop Switched to a new branch "myfeature" Incorporating a finished feature on develop Finished features may be merged into the develop branch to definitely add them to the upcoming release: $ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop
- 9. The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.
- 10. Release branches May branch off from: develop Must merge back into: develop and master Branch naming convention: release-*
- 12. Creating a release branch $ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-) Finishing a release branch The first two steps in Git: $ git checkout master Switched to branch 'master' $ git merge --no-ff release-1.2 The release is now done, and tagged for future reference. Merge made by recursive. (Summary of changes) $ git tag -a 1.2 To keep the changes made in the release branch, we need to merge those back into develop, though. $ git checkout develop Switched to branch 'develop' $ git merge --no-ff release-1.2 Merge made by recursive.
- 13. May branch off from: master Must merge back into: develop and master Branch naming convention: hotfix-* Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. A hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version to fix a critical bug in a production Other team members (on the develop branch) can continue, while another person is preparing a quick production fix. Hotfix branches
- 14. Creating the hotfix branch $ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-) Then, fix the bug and commit the fix in one or more separate commits. $ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)
- 15. Finishing a hotfix branch First, update master and tag the release. $ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) $ git tag -a 1.2.1 Next, include the bugfix in develop, too: $ git checkout develop Switched to branch 'develop' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop
- 16. Summary The overall flow of Gitflow is: ● A develop branch is created from master ● A release branch is created from develop ● Feature branches are created from develop ● When a feature is complete it is merged into the develop branch ● When the release branch is done it is merged into develop and master ● If an issue in master is detected a hotfix branch is created from master ● Once the hotfix is complete it is merged to both develop and master