Branching strategies: choose wisely to minimise costs

Georgiana Gligor (12.May.2017 at 14:30, 1 hr )
Talk at phpDay 2017 (English - UK)

Rating: 3 of 5

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.

Who are you?

Claim talk

Talk claims have been moved to the new Joind.in site.

Please login to the new site to claim your talk

 
Comments closed.

Comments

Rating: 3 of 5

12.May.2017 at 15:22 by Nicole Bartolini (39 comments) via Web2 LIVE

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

Rating: 2 of 5

12.May.2017 at 15:45 by Emiliano 'AlberT' Gabrielli (20 comments) via Web2 LIVE

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 ;)

Rating: 3 of 5

12.May.2017 at 15:58 by Stefano "Steve" Maraspin (114 comments) via Web2 LIVE

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.

Rating: 3 of 5

12.May.2017 at 16:47 by Francesca Borra (12 comments) via Web2 LIVE

More real-life cases would be appreciated

Rating: 3 of 5

12.May.2017 at 18:19 by Tony Mrakovcic (19 comments) via Web2 LIVE

Introductory, I was expecting something regarding comparing real problems in the processes and how to solve them

Rating: 5 of 5

12.May.2017 at 22:19 by Andy Johnson (16 comments) via Web2 LIVE

as I'm new to git, I found interesting the considerations of the branches, the comparisons and I liked the Agile of GitLab

Speaker comment:

13.May.2017 at 14:54 by Georgiana Gligor (30 comments) via Web2 LIVE

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.

Rating: 2 of 5

15.May.2017 at 12:11 by Simone C. (10 comments) via Web2 LIVE

More real-life cases would be appreciated.

Rating: 3 of 5

16.May.2017 at 20:50 by Jaromir Dalecky (3 comments) via Web2 LIVE

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.

Rating: 2 of 5

26.May.2017 at 19:38 by Samuele Lilli (41 comments) via Web2 LIVE

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".

© Joind.in 2017