Git Flow

GIT Flowfacebook.com/mfernandes.fernando

Friday, August 10, 12

mailto:[email protected]

mailto:[email protected]

Why GIT?


Why GIT?• Distributed



• A clone of the *entire* repository (history, tags) in each dev machine




• Code on the road! You are the repository. Multiple backups.





• Branching model





• Branching model

• Easy: git checkout -b <someFeature>





• Branching model


• Convenient: Create, try out an idea, commit, switch back, merge or discard.





• Branching model



• Small and Fast





• Branching model



• Small and Fast

• Written in C (which reduces runtime overhead associated with high-level languages)





• Branching model



• Small and Fast

• Written in C (which reduces runtime overhead associated with high-level languages)

• Built to work on the Linux kernel (it has had to effectively handle large repositories from day one)


Benchmarks


Benchmarks


Benchmarks


Benchmarks


Benchmarks


Benchmarks


Benchmarks


Benchmarks


Staging (or index) Area






Free and Open Source



• GPLv2



• GPLv2

• Free, forever



• GPLv2

• Free, forever

• Download, inspect and modify GIT source


Workflows


Workflows

• getBestWorkflow()


Workflows


• NPE


Workflows


• NPE

• ANY!


Subversion-Style


Subversion-Style


Integration Manager


Integration Manager


Dictator and Lieutenants


Dictator and Lieutenants


gitflow


gitflow• GIT abstraction



• Just a bunch of scripts




• Greatly inspired by existing models





• Main branches:





• Main branches:

• master





• Main branches:

• master

• develop





• Main branches:

• master

• develop

• Support branches:





• Main branches:

• master

• develop


• feature





• Main branches:

• master

• develop


• feature

• release





• Main branches:

• master

• develop


• feature

• release

• hotfix


gitflowThe BIG picture




gitflow: Main branches


gitflow: Main branches


gitflow: Main branches• origin/master is

where the source code of HEAD always reflects a production-ready state.


gitflow: Main branches• origin/master is

where the source code of HEAD always reflects a production-ready state.

• origin/develop is where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.


gitflow: Supporting branches - FEATURE





• Definition: used to develop new features for the upcoming or a distant future release.




• Tipically exist in developer repos only, NOT IN ORIGIN





• Branch off from: DEVELOP






• Must merge back into: DEVELOP







• Branch naming convention:








• <devName>-* (fernando-gallery)








• <devName>-* (fernando-gallery)

• (!) Not allowed: master, develop, release-* or hotfix-*


gitflow: Supporting branches - RELEASE


gitflow: Supporting branches - RELEASE


gitflow: Supporting branches - RELEASE• Definition: support preparation of a new

production release. Allow for MINOR bug fixes and preparing meta-data for a release (version number, build dates, etc.)




• When? develop (almost) reflect the desired state of the new release. All planned features were implemented.











• Must merge back into: DEVELOP and MASTER















• <release>-* (release-1.0)Friday, August 10, 12

gitflow: Supporting branches - HOTFIX


gitflow: Supporting branches - HOTFIX


gitflow: Supporting branches - HOTFIX• Definition: arise from the necessity to

act immediately upon an undesired state of a live production version. CRITICAL bugs!




• Branched off from the corresponding tag on the master branch that marks the production version.





• Branch off from: MASTER





















• hotfix-* (hotfix-1.2.1)Friday, August 10, 12


(again)



(again)


Feature. How?


Feature. How?• git checkout -b myfeature develop



• Switched to a new branch “myfeature”




• Do some work. When done...





• git checkout develop






• Switched to branch ‘develop’







• git merge --no-ff myfeature








• Updating ea1b92a...









• git branch -d myfeature










• Deleted branch myfeature










• Deleted branch myfeature

• git push origin develop


--no-ff


--no-ff• This flags causes the merge to

always create a new commit object.




• Without it, it’s impossible to see from Git history which of the commit objects together have implemented a feature.





• You will have to read all the log messages manually.






• Compare:






• Compare:


Create a release. How?



• git checkout -b release-1.2 develop




• Switched to a new branch “release-1.2”





• Manually modify the README, RELEASE NOTES, etc.






• git commit -a -m “Bumped to version 1.2”







• [release-1.2 74d9424] Bumped to version 1.2







• [release-1.2 74d9424] Bumped to version 1.2

• 1 files changed, 1 insertions(+), 1 deletions(-)


Finish a release. How?


Finish a release. How?• When the release branch is ready to become a real release, it is merged into master (every commit on

master is a new release by definition) and the commit is tagged for easy future reference to this historical version. Finally it’s merged back into develop, so future releases contain the bug fixes.




• git checkout master





• Switched to branch “master”






• git merge --no-ff release-1.2







• Merge made by recursive. (Summary of changes)








• To keep the changes made in the release branch, we need to merge those back into develop.









• git tag -a 1.2 // Can use -s or -u <key> to sign cryptographically





















• Switched to branch “develop”







































• It may lead to a merge conflict. Fix it and commit.















• Now we are really done and the release branch may be removed, since we don’t need it anymore.
















• git branch -d release-1.2
















• git branch -d release-1.2

• Deleted branch release-1.2 (was ff452fe)


Create a hotfix. How?


Create a hotfix. How?• git checkout -b hotfix-1.2.1 master



• Switched to a new branch “hotfix-1.2.1”









• git commit -a -m “Bumped to version 1.2.1”






• [hotfix-1.2.1 416e61] Bumped to version 1.2.1















• Fix the bug and commit the fix.









• git commit -m “Fixed severe production problem”










• [hotfix-1.2.1 416e61] Fixed severe production problem.










• [hotfix-1.2.1 416e61] Fixed severe production problem.



Finish a hotfix. How?


Finish a hotfix. How?• git checkout master







• git merge --no-ff hotfix-1.2.1











• git tag -a 1.2.1 // Again, this can be done cryptographically







• Include the bugfix in develop too. The exception: if there is a release branch, the hotfix changes need to be merge into that release branch instead of develop.


















































• Finally remove the temporary branch













• git branch -d hotfix-1.2.1













• git branch -d hotfix-1.2.1

• Deleted branch hotfix-1.2.1 (was abbe5d6)


It was just a flesh wound, right?

That’s it!


Referenceshttp://nvie.com/posts/a-successful-git-branching-model/

http://learn.github.com/p/tagging.html

http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

http://stackoverflow.com/questions/1616957/how-do-you-roll-back-reset-a-git-repository-to-a-particular-commit

http://stackoverflow.com/questions/1457103/what-is-the-difference-between-a-tag-and-a-branch-in-git


http://nvie.com/posts/a-successful-git-branching-model/

http://nvie.com/posts/a-successful-git-branching-model/













Thanks!


Date post:	06-May-2015
Category:	Technology
Upload:	fernando-fernandes
View:	612 times
Download:	1 times

Git Flow

Technology