`Phlow Pronunciation: /floʊ/ ...exactly as in "flow"
There are many recommended work processes out there, that are specifically designed to be git centric. Git flows — So one could ask: "why do we need another?". Well the justification for this particular one is that "It's elegant and simple".
As opposed to most flows which are pull request centric — that is; all changes to repository happens in context of pull requests and peer-reviews. This one is instead issue centric. We still get a place where we can discuss and collaborate around - well; issues. But we don't get the tedious stop-go process that pull requests enforces.
Where pull request centric flows are control flows – this one is about collaboration.
This flow is delivered to you as a git extension when you install it you have simply extended your local git with five new commands:
git workon <issue number>
git wrapup
git deliver
git share
git sync <issue number>That's it - and it's all you need.
Both as a git newbie and an old-timer professional you can use these five new commands to open up a world into git, GitHub, GitHub issues and GitHub projects that makes collaboration among software developers - simple and delicious.
Documentation is built in. From you terminal just run git phlow and head on from there.
Although the intended end-users of this phlow are developers, the argument for using it is not very technical. Often (too often) the choice of tools stack and process falls on managers and chickens, They too need to know that optimizing the workday of an arbitrary developer has a huge impact on business.
The branching strategy underneath is a simple release-train branching strategy (master being the only long-lived branch). It is fully supported by a declarative pipeline - free of choice - and that is including the test, deploy and release process.
This is Git Ops; you just work in git, and then the entire World happens!
The process is so simple that even non-techies will fall in love with GitHub. The phlow is also used by non-tech employees like marketing workers and event managers working The Phlow when they update our JAM stack website.
The contemporary buzz goes: Infrastructure as code, test as code, deployment as code well anything as code basically. In the light of this buzz, it seems ironic, that most software development processes today are still plastered with manual processes.
Pull request centric flows included.
In Praqma we worked with our clients on optimizing issue centric work processes. Over the course of more than 5 years we built developer collaboration platforms rather than SCM systems. Embracing the Agile doctrine "People over processes and tools". The Phlow strive for a process, that is so efficient, that it becomes invisible.
The Phlow is the manifest of all these learnings and customer collaborations.
I have been working with version control systems since the age of dawn - my first presentation on branching strategies (in ClearCase) was in Denver at Rational User Conference 2001.
Since then I've made version control in general my thing, and when git buried all competition in the field I specifically made git my thing.
I co-founded Praqma - The Continuous Delivery company. It's gone now, acquired by another company. But in Praqma is specialized in helping companies who develop software, to organize themselves in a way that allows quality to be built in - as opposed to glued on.
Companies like Volvo, Grundfos, Kamstrup, Novo Nordisk, Atmel (now Microchip) and many other were actively participating in using, tearing and wearing this particular phlow into it's current level of simplicity and elegance.