Collaborative Git branching strategies

Lets talk about some Git branching strategies for a cohesive, collaborative development environment. This should successfully work even for globally distributed teams, as long as people use the following guidelines, while naming their branches. Just to reiterate, I assume you are comfortable with the various git concepts, such as branches, tags, pull requests.

master -  should only hold code run through the complete regression cycle and ready for release, each product release should be separately tagged in the master branch.

dev - should include the latest feature-complete development code. Hence code in this branch is feature-developed and feature tested but not necessarily full regression tested.

feature branches - should be branched out of dev/another feature branch and should only include development code. Once the feature is developed and tested a pull request should be raised, which once reviewed should merge the feature branch back to its parent branch.

feature branch naming strategies - feature development branches should be named using the following format : -

Developer Initials/parent branch_feature_name_feature_ticket_num, 

The reason behind the use of a back-slash '/' after the dev initials is; this would help us group all branches created by a particular developer in most git GUI tools.

E.g if Donald Trump is working on a Jira ticket named 1234 - UI Fixes and the parent branch is dev, I would suggest the feature branch should be named in the following format : -

dt/dev_ui_fixes_1234

Moreover always merge branches back to their parent branches using a pull request, followed by a code review by your peer. And please don't forget to delete your feature branch once its merged back to its parent branch.

If you have comments/feedback please share them below.

Clean Code Architecture

There is a lot of hoopla ongoing in the software world with the term 'Clean code architecture'/'Onion architecture' introduced by 'Uncle Bob'. Here I would like to illustrate on it, without all the hoopla!

Over the years I have developed several apps using the Clean code architecture - and I feel it can be suitably described as an extension of the best practices preached by several of the 'dyed in the wool' enterprise frameworks like Spring. So lets get on with it:-

What is it?

As I said its a bunch of architectural best practices which has long been promoted in the Spring (and other enterprise-y) web development community. Its an architectural pattern based on the SOLID design principles and incorporates a layered architecture, where each layer interacts with the layer below it and pushes data to layer above it.


What do I gain from it?

Well finally this might be your fool-proof way to develop SOLID code. What you do is develop code based on your application 'use cases' and group them together based on clearly defined responsibilities. Usually the components can be grouped in the following categories: -

• Views - its the presentational layer and is strictly responsible for displaying the 'formatted' data and nothing else.
• ViewModels - its the model for the view, to illustrate further its a set of data structures, that contain formatted data to be displayed by the view.
• Controllers/Presenters - they are the conduit/pipe between the views and the rest of the system. They inform the application of user interaction and push updated system data back to the view in a suitably formatted format.
• Interactors - they hold the application specific use cases and manipulate the system data in accordance with the requirements of the specific use case.
• Repositories - this is where the system data is stored, usually every entity has its own repository and the repository stores the system data related to that particular entity.
• Entities - they are the business objects of an application, e.g. a Customer entity in a Billing system etc.

You can find more information about each of the several layers here and here.

Its also very important to observe the Dependency rule, items in the list above depend on items below in the list and not the other way. Just follow the arrows in the picture below, they clearly illustrate the dependency flow. Its always pointing inwards.

As like anything else I would forbid you to copy it blindly, but rather soak it in, understand it, and then use what works for you - you can certainly use this document as your guideline. Also please ensure to visit the several other links in this document to learn more about it.

Where can i learn more about it?

Sample iOS App demonstrating Clean code architecture.