Talk in English - UK at phpDay 2017
Track Name:
Track 2
View Slides: https://speakerdeck.com/gbtekkie/branching-strategies-choose-wisely-to-minimise-costs-at-phpday-verona-2017
Short URL: https://joind.in/talk/0f19e
(QR-Code (opens in new window))
Is your team choosing the branching strategy from the beginning, or is it switching after a while to better accommodate the current project stage? How does this affect you, and what are the costs involved? Multiply this by the number of repositories, each playing a definite role in a large-scale project, and you will want to know how to minimise the impact.
In the inception phase, developers are the ones producing code, and oftentimes they choose the project branching strategy that mostly fits their immediate needs. In some teams the developers don't have DevOps knowledge, so when there is a working prototype that needs to see the light of day (err... server), they need a packagist to help them assemble the code so that it can be deployed in a specific environment, which often translates into a branching change. When the codebase matures and bug hunts start to occur, new constraints are imposed, and a more mature strategy is transitioned to.
The branching model needs to be simple - so that everyone involved can grasp it quickly, flexible - so it can serve the needs of very different roles within the project lifecycle, adaptable - when you have a particular unforeseen need, it should not be a barrier.
See what's already being used by others, ask a few questions that might drive an adaptation of your choice, then choose wisely. Then let your team spend their time on coding rather than painfully switching strategies.
Comments
Comments are closed.
Quite basic talk, theory is well known, interesting the view on linux flow. More real cases will be appreciated over theory.
Georgiana's English is hard to understand
Well known concepts that would be more interesting if coupled with real life cases, how known problems could be solved at best by one strategy over another.
A little difficult to follow cause of the "plane" tone of the presentation, especially because it is an after-lunch talk.
Could be refactored a bit ;)
I have to agree with others here. From the talk title, I was expecting to learn a bit more about specific development contexts and "edge cases" of real life experiences.
Presented theory is solid, and nice are the examples (IE the Linux Kernel development workflow). Talk was also good (especially for beginners), but IMHO it has a lot of more potential if specific examples (and suggestions) on things like front-end/back-end/documentation/different-services codebases handling are also added .
I think that changing the presentation pace, practicing a bit beforehand (so to make the English speech more fluent) and adding real life examples can improve it a lot.
More real-life cases would be appreciated
Introductory, I was expecting something regarding comparing real problems in the processes and how to solve them
as I'm new to git, I found interesting the considerations of the branches, the comparisons and I liked the Agile of GitLab
Thank you for your feedback, it is very valuable and will help me to fine tune this.
The 6 strategies presented in the talk are already used on a day-to-day basis by companies like Atlassian, GitHub, GitFlow, and as you mention the Linux Kernel. I wanted to have a balance between strategies used by software-as-a-service companies and ones constrained to do long-term releases.
My goal is to raise awareness on the fact that our history is being used by so many other team roles than just developers, and to shift your mindset towards this. Because a few months down the road somebody will be in a bug hunter or release manager shoes and they will have so different needs from the history.
Knowing the concepts introduced in the 2nd part of the talk will enable anyone to assemble them in a way that makes sense for their particular project or team, and make them more productive.
More real-life cases would be appreciated.
I was probably expecting a different content of the talk based on the annotation. However, the overview of some of the strategies used was useful.
I agree with others.
Moreover I would have liked to see some concrete examples as it was totally unclear what are the advantage of a branching strategy compared to others: I mean, git-flow has the "problem" of merge commits but I really didn't understood how, with other branching strategies, this problem "disappear".