Since there are several people who have been amazed with my statement on not to use branches, I better explain this a little more. To do this I’ll share a story which happened to a cousin brother of the brother-in-law of a neighbor, called Paco.
-Paco had a request Milagros (his customer) to make an iOS app for a 15 days promotion of a beauty cream for hands. This promotion started in little over 2 months.
-In this type of projects Paco usually worked with Lucia, she is an UX expert, and also knew how to manage iOS apps
-Paco (cool!) is a Xamarin developer, so taking advantage of Visual Studio Online, Paco gave permissions to Lucia and Milagros in a VSOnline instance
-Paco coordinated with Lucia and Milagros to work in 2 sprints, each one will be a 3 week duration. He also is defining this time box thinking in the leap between Sprints and possible changes. At the end they all agreed on this model.
-Paco create the basic elements and they started to use TFS as repository, work was started!.
-After of the 2nd Sprint, Milagros was Happy Happy with the application, so she give a GO to Paco and Lucia to coordinate with the Marketing team for the publication and promotion of the application.
So here ends the story of Milagros, Lucia and Paco and I asked myself…
Where are the branches? Maybe nowhere, Paco never had the need to use branches; SO HE DIDN’T CREATED!
Caution! I do not mean that create and use branches is bad. For sure Paco when he was testing or making changes, had a local Git repo with his changes, tests, branches, etc; but why does he have to create a branch to share with Lucia and Milagros?
This bring us to the bases of the branch managing: if we work in an app will not have later versions, why do you have to create a DEV – MAIN – RELEASES schema? At this point there is no idea that the application will have continuity so … what for?.
One of the excellent features of TFS and GIT is that anytime you can create a branch and start working with branches. So when the the scenario request this feature, you can start and define a scheme of branches.
Proably you think that this sample is kind of crazy (It is!). I’m trying to share a message in the background: not add XYZ to you apps when you are creating applications, if XYZ does not add value to the application that you are creating!. For example, why create an app that supports multiple cultures? if you know that that is not necessary.
If when a Sprint ends, the PBIs changes, get new changes; PO puts on the table new features that require changes in the architecture or the way of working… don’t feel bad, the architecture will emerge naturally to accommodate those changes.
What you should not do is to think in advance in scenarios that do not apply and that only complicate your application. The phrase that sums up all this, leaves the app architecture and the app itself to emerge and to adapt with the same time as the business context of the app, … and obviously relies on your team and let the team to decide.
Note: If a dev writes applications regardless of the bases of a good app developer, as for example a correct exceptions management, it is to cut off his fingers. Once a developer replied “I did an application that handles exceptions correctly because the PO not asked for this “… This serves to measure the quality of a person and also is a good opportunity to test the edge of a Katana.
Saludos @ Home