Git Branching – the battle of the ages
Download as PPTX, PDF0 likes160 views
The document discusses the importance of having a defined Git branching strategy to avoid chaos in version control, contrasting trunk-based development and branch-based development. It emphasizes the lifecycle of a project from starting to shipping features, detailing both strategies' processes, benefits, and challenges. Ultimately, it encourages choosing a Git strategy that best fits the project's needs while ensuring effective planning and clear task management.
Git Branching – the battle of the ages
- 1. Git Branching – the battle of the ages What’s better? Extensive branching or trunk-based development? Jasmin Fluri Gianni Ceresa
- 2. Disclaimer This presentation is intended for educational purposes only and does not replace independent professional judgment. Statements of fact and opinions expressed are those of the presenters and are subject for bias.
- 3. Why do we need a branching strategy?
- 4. Why you absolutely need a defined git strategy!
- 5. … not having a git strategy means… some people push their changes directly to main… … others create branches, some create merge requests and expect a review… tags are sometimes created, sometimes not… … it’s a mess.
- 6. Without a defined git strategy…
- 7. … we need to define what happens … a branching strategy covers the FULL lifecycle … from when we start implementing a feature… … until it is installed in production!
- 8. 2 different git strategies Jasmin Fluri Schaltstelle GmbH @jasminfluri Trunk-based development Branch-based development I first started with CVS back in ... can’t remember... Gianni Ceresa DATAlysis LLC I’m supposed to play the old man here... @G_Ceresa I’m supposed to play the young gun here... Born in the Git century – never used SVN or CVS
- 9. The Science of Database CI/CD 12:00 – 12:45 Ashstead 1 & 2
- 10. 4 Steps in a Project Lifecycle Start project 1 Review code 2 Build an integration pipeline 3 Ship feature 4
- 11. 4 Steps in a Project Lifecycle Start project 1 Review code 2 Build an integration pipeline 3 Ship feature 4
- 12. Starting a project … Trunk based development is easy!
- 13. Trunk based does not mean you have no branches!
- 14. Trunk-based development combines both speed (bringing changes into production fast) and safety (automated testing in the pipeline).
- 15. Trunk based development and infrastructure code! Source: https://github.com/michaellihs/presentations/blob/main/2021-10-21-infra-pipelines-baselone/presentation.pdf
- 17. Branch based development is …. Also easy! Until Jasmin finds a fun picture of it...
- 18. Branch based development is ….
- 19. GitFlow Everything can be a branch Everything “needs” a branch Once you start using branches, no reason to stop! And then you merge, merge and merge branches...
- 21. COMMIT
- 23. Branch based development is... suggested by Oracle
- 24. Branch based development: many ways GitFlow has been the first, presented in 2010 • In development age this is a loooooong time ago! Many more followed: • GitHubFlow • GitLabFlow • OneFlow • *whatever*-flow
- 25. Good luck with Trunk based! Image by Anita S. from Pixabay Photo by Alexandre Debiève on Unsplash
- 26. Or relax with Branch based! Alone Singapore Airlines
- 27. Or relax with Branch based! Or in a team Qatar Airways
- 28. 4 Steps in a Project Lifecycle Start project 1 Review code 2 Build an integration pipeline 3 Ship feature 4
- 29. Code Reviews in Trunk-based Development • Either happens directly during pair programming …. • … or code reviews are very small due to very small merge requests! • But we want to avoid merging…
- 30. Handovers in software development
- 31. Merging is bad for you! • Merging is hard work • Merging is a change to the codebase • requires testing before and after the merge • No guarantee that integration works both before and after the merge • No branches == no merging • Small batches == short test cycles
- 32. But we need a way to introduce changes step by step!
- 33. Branching by Abstraction is your Friend!
- 34. Code Reviews in Branch-based Development • Either happens directly during pair programming …. • … or code reviews happen once when the development is over before merging! • And we aren’t afraid of merging…
- 35. Code Reviews in Branch-based • There isn’t one unique universal way for this • Heavily depends on what you are versioning and your processes • Regression testing is your friend • If you have a full set of regression tests covering your code base, no regression = no issues and you can safely merge • If you aren’t happy with the quality of the code, no issues: the branch is independent, nothing will be impacted by keeping it there and work on it again • Somebody else can easily take over a feature and keep working on the branch
- 36. Merging can be your friend! • Again ... It all depends on what you are versioning and your processes • Not everybody is versioning just “some code” • The better your tests, the more you can “blindly” merge • Of course it requires testing before and after, but is this a bad thing? • If you have full coverage with your tests, tests are successful, there is little reason to believe something will break in an unexpected way
- 37. Branching for real is better than “virtually” • Why branching by abstraction instead of a real branch? • No need of any “_v2” or other weird name when replacing something • Who do not love a Big Bang release? • Having a business sign off on a branch is easier than on ... nothing
- 38. 4 Steps in a Project Lifecycle Start project 1 Review code 2 Build an integration pipeline 3 Ship feature 4
- 39. continuous integration best practices • Don’t commit broken code • Don’t commit untested code • If the build is broken, fix it before you continue developing • Don’t go home if the build is broken • Commit frequently (at least once a day) • Every commit must trigger the integration • Keep the build fast (to get fast feedback)
- 40. Building an integration pipeline trunk-based! On Merge Request On Commit Main Linting Regression Testing Regression Testing Deploy CI Linting
- 41. But … if you have a high test coverage, it means your code quality is good, right?
- 42. … only because you have a high test coverage, it doesn’t mean your tests are any good….
- 43. Building an integration pipeline branch-based! On Merge Request Regression testing Linting On Commit Main Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting On Commit … Regression testing Deploy CI Linting
- 44. Building an integration pipeline branch- based! A bit more seriously... • Having various kinds of branches requires different/multiple integration pipelines • A solid naming convention allows to make it extremely simple • A pipeline can be linked to a branch by a suffix (like “feature-”, “release-” etc.) • Integration pipelines can be custom tailored for some special needs applying only to a given branch • Warning: More customization == more work to implement it and maintain it
- 45. Building an integration pipeline branch-based! An example of a GitLab CI/CD pipeline definition • A condition link a job only with branches matching a name condition
- 46. 4 Steps in a Project Lifecycle Start project 1 Review code 2 Build an integration pipeline 3 Ship feature 4
- 47. Shipping features into prod trunk-based! On Commit Main Linting Testing Deploy Test Deploy Int Deploy Prod Release Deploy CI • The integration pipeline is extended with deployment steps • Those steps can be triggered manually (so not every commit is automatically pushed into prod).
- 48. Shipping features into prod branch-based! On Commit «Release candidate» branch Linting Testing Deploy Test Deploy Int Deploy Prod Release Deploy CI • Just what she said … • But applied to a branch with the release candidate, every time there is one • Doing all the required changes in that branch, and some more cooking • Merge back into Main the changes, if any
- 50. Choose the git strategy that fits your project best! You might need to adjust one.
- 51. You can stay out of trouble if you plan your tasks well! • No overlapping tasks with other team members • Clear architecture that allows to do work in parallel • Clear interfaces that separate components
- 52. There are many good git branching strategies available! Know them!
- 53. Use Git and its features how they are supposed to be used! As a versioning tool!
- 54. What questions do you have? Thank you for your time! @jasminfluri @G_Ceresa
- 55. The Science of Database CI/CD 12:00 – 12:45 Ashstead 1 & 2
- 56. References / Sources • https://trunkbaseddevelopment.com/ • https://nvie.com/posts/a-successful-git-branching-model/
Editor's Notes
- #7: If you don’t have a defined git strategy, you won’t be fine… .. We all agree on this – there are multiple things that can go wrong and will go wrong.
- #9: [GC] It looks like many people took the original Git-Flow and just did minimal changes but felt like naming the result as a new strategy.
- #11: .. Let’s have a look how those two git strategies perform on these five steps in a project lifecycle
- #12: .. Let’s have a look how those two git strategies perform on these five steps in a project lifecycle
- #13: You either commit directly to the trunk (done in pair programming) or you work in very short lived feature branches, that get merged very quickly. We don’t need to merge a lot and because we all work on the same branch, we commit very small code changes that again reduce the risk of introducing changes. Active time of a developer is much higher… less waiting times – almost no hand-overs
- #20: [GC] Everybody has its own private place where to work, nothing will be mistakenly make it into a shared branch till you really wants it. No half-releases, it’s more a Big Bang kind of release.
- #26: [GC] Why to all share a wardrobe when you could have one each?
- #27: [GC] Why to all share a wardrobe when you could have one each?
- #28: [GC] Why to all share a wardrobe when you could have one each?
- #29: .. Let’s have a look how those two git strategies perform on these five steps in a project lifecycle
- #39: .. Let’s have a look how those two git strategies perform on these five steps in a project lifecycle
- #41: In trunk based development, there are only two type of branches – you don’t have different rules for different branches.
- #44: Every branch in gitflow workflow has its own little rules – you have a nightmare list of processes – building an automated pipeline for so many scenarios is quite a pain
- #45: Every branch in gitflow workflow has its own little rules – you have a nightmare list of processes – building an automated pipeline for so many scenarios is quite a pain
- #46: Every branch in gitflow workflow has its own little rules – you have a nightmare list of processes – building an automated pipeline for so many scenarios is quite a pain
- #47: .. Let’s have a look how those two git strategies perform on these five steps in a project lifecycle