Git Flow

  • 521 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
521
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
13
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. GIT Flow facebook.com/mfernandes.fernandoFriday, August 10, 12
  • 2. Why GIT?Friday, August 10, 12
  • 3. Why GIT? • DistributedFriday, August 10, 12
  • 4. Why GIT? • Distributed • A clone of the *entire* repository (history, tags) in each dev machineFriday, August 10, 12
  • 5. 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.Friday, August 10, 12
  • 6. 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 modelFriday, August 10, 12
  • 7. 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 • Easy: git checkout -b <someFeature>Friday, August 10, 12
  • 8. 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 • Easy: git checkout -b <someFeature> • Convenient: Create, try out an idea, commit, switch back, merge or discard.Friday, August 10, 12
  • 9. 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 • Easy: git checkout -b <someFeature> • Convenient: Create, try out an idea, commit, switch back, merge or discard. • Small and FastFriday, August 10, 12
  • 10. 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 • Easy: git checkout -b <someFeature> • Convenient: Create, try out an idea, commit, switch back, merge or discard. • Small and Fast • Written in C (which reduces runtime overhead associated with high-level languages)Friday, August 10, 12
  • 11. 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 • Easy: git checkout -b <someFeature> • Convenient: Create, try out an idea, commit, switch back, merge or discard. • 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)Friday, August 10, 12
  • 12. BenchmarksFriday, August 10, 12
  • 13. BenchmarksFriday, August 10, 12
  • 14. BenchmarksFriday, August 10, 12
  • 15. BenchmarksFriday, August 10, 12
  • 16. BenchmarksFriday, August 10, 12
  • 17. BenchmarksFriday, August 10, 12
  • 18. BenchmarksFriday, August 10, 12
  • 19. BenchmarksFriday, August 10, 12
  • 20. Staging (or index) AreaFriday, August 10, 12
  • 21. Staging (or index) AreaFriday, August 10, 12
  • 22. Staging (or index) AreaFriday, August 10, 12
  • 23. Free and Open SourceFriday, August 10, 12
  • 24. Free and Open Source • GPLv2Friday, August 10, 12
  • 25. Free and Open Source • GPLv2 • Free, foreverFriday, August 10, 12
  • 26. Free and Open Source • GPLv2 • Free, forever • Download, inspect and modify GIT sourceFriday, August 10, 12
  • 27. WorkflowsFriday, August 10, 12
  • 28. Workflows • getBestWorkflow()Friday, August 10, 12
  • 29. Workflows • getBestWorkflow() • NPEFriday, August 10, 12
  • 30. Workflows • getBestWorkflow() • NPE • ANY!Friday, August 10, 12
  • 31. Subversion-StyleFriday, August 10, 12
  • 32. Subversion-StyleFriday, August 10, 12
  • 33. Integration ManagerFriday, August 10, 12
  • 34. Integration ManagerFriday, August 10, 12
  • 35. Dictator and LieutenantsFriday, August 10, 12
  • 36. Dictator and LieutenantsFriday, August 10, 12
  • 37. gitflowFriday, August 10, 12
  • 38. gitflow • GIT abstractionFriday, August 10, 12
  • 39. gitflow • GIT abstraction • Just a bunch of scriptsFriday, August 10, 12
  • 40. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing modelsFriday, August 10, 12
  • 41. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches:Friday, August 10, 12
  • 42. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches: • masterFriday, August 10, 12
  • 43. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches: • master • developFriday, August 10, 12
  • 44. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches: • master • develop • Support branches:Friday, August 10, 12
  • 45. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches: • master • develop • Support branches: • featureFriday, August 10, 12
  • 46. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches: • master • develop • Support branches: • feature • releaseFriday, August 10, 12
  • 47. gitflow • GIT abstraction • Just a bunch of scripts • Greatly inspired by existing models • Main branches: • master • develop • Support branches: • feature • release • hotfixFriday, August 10, 12
  • 48. gitflow The BIG pictureFriday, August 10, 12
  • 49. gitflow The BIG pictureFriday, August 10, 12
  • 50. gitflow: Main branchesFriday, August 10, 12
  • 51. gitflow: Main branchesFriday, August 10, 12
  • 52. gitflow: Main branches • origin/master is where the source code of HEAD always reflects a production-ready state.Friday, August 10, 12
  • 53. 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.Friday, August 10, 12
  • 54. gitflow: Supporting branches - FEATUREFriday, August 10, 12
  • 55. gitflow: Supporting branches - FEATUREFriday, August 10, 12
  • 56. gitflow: Supporting branches - FEATURE • Definition: used to develop new features for the upcoming or a distant future release.Friday, August 10, 12
  • 57. 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 ORIGINFriday, August 10, 12
  • 58. 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: DEVELOPFriday, August 10, 12
  • 59. 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: DEVELOPFriday, August 10, 12
  • 60. 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:Friday, August 10, 12
  • 61. 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)Friday, August 10, 12
  • 62. 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) • (!) Not allowed: master, develop, release-* or hotfix-*Friday, August 10, 12
  • 63. gitflow: Supporting branches - RELEASEFriday, August 10, 12
  • 64. gitflow: Supporting branches - RELEASEFriday, August 10, 12
  • 65. 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.)Friday, August 10, 12
  • 66. 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.Friday, August 10, 12
  • 67. 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. • Branch off from: DEVELOPFriday, August 10, 12
  • 68. 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. • Branch off from: DEVELOP • Must merge back into: DEVELOP and MASTERFriday, August 10, 12
  • 69. 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. • Branch off from: DEVELOP • Must merge back into: DEVELOP and MASTER • Branch naming convention:Friday, August 10, 12
  • 70. 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. • Branch off from: DEVELOP • Must merge back into: DEVELOP and MASTER • Branch naming convention: • <release>-* (release-1.0)Friday, August 10, 12
  • 71. gitflow: Supporting branches - HOTFIXFriday, August 10, 12
  • 72. gitflow: Supporting branches - HOTFIXFriday, August 10, 12
  • 73. gitflow: Supporting branches - HOTFIX • Definition: arise from the necessity to act immediately upon an undesired state of a live production version. CRITICAL bugs!Friday, August 10, 12
  • 74. 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.Friday, August 10, 12
  • 75. 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: MASTERFriday, August 10, 12
  • 76. 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 • Must merge back into: DEVELOP and MASTERFriday, August 10, 12
  • 77. 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 • Must merge back into: DEVELOP and MASTER • Branch naming convention:Friday, August 10, 12
  • 78. 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 • Must merge back into: DEVELOP and MASTER • Branch naming convention: • hotfix-* (hotfix-1.2.1)Friday, August 10, 12
  • 79. gitflow The BIG picture (again)Friday, August 10, 12
  • 80. gitflow The BIG picture (again)Friday, August 10, 12
  • 81. Feature. How?Friday, August 10, 12
  • 82. Feature. How? • git checkout -b myfeature developFriday, August 10, 12
  • 83. Feature. How? • git checkout -b myfeature develop • Switched to a new branch “myfeature”Friday, August 10, 12
  • 84. Feature. How? • git checkout -b myfeature develop • Switched to a new branch “myfeature” • Do some work. When done...Friday, August 10, 12
  • 85. Feature. How? • git checkout -b myfeature develop • Switched to a new branch “myfeature” • Do some work. When done... • git checkout developFriday, August 10, 12
  • 86. 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’Friday, August 10, 12
  • 87. 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 myfeatureFriday, August 10, 12
  • 88. 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...Friday, August 10, 12
  • 89. 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 myfeatureFriday, August 10, 12
  • 90. 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 myfeatureFriday, August 10, 12
  • 91. 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 • git push origin developFriday, August 10, 12
  • 92. --no-ffFriday, August 10, 12
  • 93. --no-ff • This flags causes the merge to always create a new commit object.Friday, August 10, 12
  • 94. --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.Friday, August 10, 12
  • 95. --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.Friday, August 10, 12
  • 96. --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:Friday, August 10, 12
  • 97. --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:Friday, August 10, 12
  • 98. Create a release. How?Friday, August 10, 12
  • 99. Create a release. How? • git checkout -b release-1.2 developFriday, August 10, 12
  • 100. Create a release. How? • git checkout -b release-1.2 develop • Switched to a new branch “release-1.2”Friday, August 10, 12
  • 101. 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.Friday, August 10, 12
  • 102. 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”Friday, August 10, 12
  • 103. 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.2Friday, August 10, 12
  • 104. 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 • 1 files changed, 1 insertions(+), 1 deletions(-)Friday, August 10, 12
  • 105. Finish a release. How?Friday, August 10, 12
  • 106. 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.Friday, August 10, 12
  • 107. 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 masterFriday, August 10, 12
  • 108. 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”Friday, August 10, 12
  • 109. 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.2Friday, August 10, 12
  • 110. 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)Friday, August 10, 12
  • 111. 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.Friday, August 10, 12
  • 112. 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 cryptographicallyFriday, August 10, 12
  • 113. 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 • git checkout developFriday, August 10, 12
  • 114. 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 • git checkout develop • Switched to branch “develop”Friday, August 10, 12
  • 115. 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 • git checkout develop • Switched to branch “develop” • git merge --no-ff release-1.2Friday, August 10, 12
  • 116. 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 • git checkout develop • Switched to branch “develop” • git merge --no-ff release-1.2 • Merge made by recursive. (Summary of changes)Friday, August 10, 12
  • 117. 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 • git checkout develop • Switched to branch “develop” • git merge --no-ff release-1.2 • Merge made by recursive. (Summary of changes) • It may lead to a merge conflict. Fix it and commit.Friday, August 10, 12
  • 118. 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 • git checkout develop • Switched to branch “develop” • git merge --no-ff release-1.2 • Merge made by recursive. (Summary of changes) • 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.Friday, August 10, 12
  • 119. 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 • git checkout develop • Switched to branch “develop” • git merge --no-ff release-1.2 • Merge made by recursive. (Summary of changes) • 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.2Friday, August 10, 12
  • 120. 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 • git checkout develop • Switched to branch “develop” • git merge --no-ff release-1.2 • Merge made by recursive. (Summary of changes) • 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 • Deleted branch release-1.2 (was ff452fe)Friday, August 10, 12
  • 121. Create a hotfix. How?Friday, August 10, 12
  • 122. Create a hotfix. How? • git checkout -b hotfix-1.2.1 masterFriday, August 10, 12
  • 123. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1”Friday, August 10, 12
  • 124. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc.Friday, August 10, 12
  • 125. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1”Friday, August 10, 12
  • 126. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1” • [hotfix-1.2.1 416e61] Bumped to version 1.2.1Friday, August 10, 12
  • 127. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1” • [hotfix-1.2.1 416e61] Bumped to version 1.2.1 • 1 files changed, 1 insertions(+), 1 deletions(-)Friday, August 10, 12
  • 128. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1” • [hotfix-1.2.1 416e61] Bumped to version 1.2.1 • 1 files changed, 1 insertions(+), 1 deletions(-) • Fix the bug and commit the fix.Friday, August 10, 12
  • 129. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1” • [hotfix-1.2.1 416e61] Bumped to version 1.2.1 • 1 files changed, 1 insertions(+), 1 deletions(-) • Fix the bug and commit the fix. • git commit -m “Fixed severe production problem”Friday, August 10, 12
  • 130. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1” • [hotfix-1.2.1 416e61] Bumped to version 1.2.1 • 1 files changed, 1 insertions(+), 1 deletions(-) • Fix the bug and commit the fix. • git commit -m “Fixed severe production problem” • [hotfix-1.2.1 416e61] Fixed severe production problem.Friday, August 10, 12
  • 131. Create a hotfix. How? • git checkout -b hotfix-1.2.1 master • Switched to a new branch “hotfix-1.2.1” • Manually modify the README, RELEASE NOTES, etc. • git commit -a -m “Bumped to version 1.2.1” • [hotfix-1.2.1 416e61] Bumped to version 1.2.1 • 1 files changed, 1 insertions(+), 1 deletions(-) • Fix the bug and commit the fix. • git commit -m “Fixed severe production problem” • [hotfix-1.2.1 416e61] Fixed severe production problem. • 5 files changed, 32 insertions(+), 17 deletions(-)Friday, August 10, 12
  • 132. Finish a hotfix. How?Friday, August 10, 12
  • 133. Finish a hotfix. How? • git checkout masterFriday, August 10, 12
  • 134. Finish a hotfix. How? • git checkout master • Switched to branch “master”Friday, August 10, 12
  • 135. Finish a hotfix. How? • git checkout master • Switched to branch “master” • git merge --no-ff hotfix-1.2.1Friday, August 10, 12
  • 136. Finish a hotfix. How? • git checkout master • Switched to branch “master” • git merge --no-ff hotfix-1.2.1 • Merge made by recursive. (Summary of changes)Friday, August 10, 12
  • 137. Finish a hotfix. How? • 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 // Again, this can be done cryptographicallyFriday, August 10, 12
  • 138. Finish a hotfix. How? • 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 // 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.Friday, August 10, 12
  • 139. Finish a hotfix. How? • 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 // 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. • git checkout developFriday, August 10, 12
  • 140. Finish a hotfix. How? • 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 // 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. • git checkout develop • Switched to branch ‘develop’Friday, August 10, 12
  • 141. Finish a hotfix. How? • 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 // 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. • git checkout develop • Switched to branch ‘develop’ • git merge --no-ff hotfix-1.2.1Friday, August 10, 12
  • 142. Finish a hotfix. How? • 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 // 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. • git checkout develop • Switched to branch ‘develop’ • git merge --no-ff hotfix-1.2.1 • Merge made by recursive. (Summary of changes)Friday, August 10, 12
  • 143. Finish a hotfix. How? • 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 // 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. • git checkout develop • Switched to branch ‘develop’ • git merge --no-ff hotfix-1.2.1 • Merge made by recursive. (Summary of changes) • Finally remove the temporary branchFriday, August 10, 12
  • 144. Finish a hotfix. How? • 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 // 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. • git checkout develop • Switched to branch ‘develop’ • git merge --no-ff hotfix-1.2.1 • Merge made by recursive. (Summary of changes) • Finally remove the temporary branch • git branch -d hotfix-1.2.1Friday, August 10, 12
  • 145. Finish a hotfix. How? • 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 // 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. • git checkout develop • Switched to branch ‘develop’ • git merge --no-ff hotfix-1.2.1 • Merge made by recursive. (Summary of changes) • Finally remove the temporary branch • git branch -d hotfix-1.2.1 • Deleted branch hotfix-1.2.1 (was abbe5d6)Friday, August 10, 12
  • 146. That’s it! It was just a flesh wound, right?Friday, August 10, 12
  • 147. References http://nvie.com/posts/a-successful-git-branching-model/ http://learn.github.com/p/tagging.htmlhttp://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-gitFriday, August 10, 12
  • 148. Thanks!Friday, August 10, 12