Mono/Multi Repo, Balancing Feature Branches and Continuous Integration
If you are confused between mono repository or multi-repository or a branch and merge strategy for micro-services - feature branches, trunk based development or release branches, then this post will have something for you. There is no one right way, but as with life, to choose a better way ,you need to be first self aware. Similarly to choose a source control strategy for your project, you need to be aware of the analysis process, development process, balance of parallel feature development with CI and CD,code review and merge process and component ownership patterns in your teams.
Git is by default the version control system used by most modern software projects. I have seen that the perspective is different if you have worked in worse version control systems at first. But for the new generation of programmers Git may be the their first ‘worst’ source control system. And for those many now and many more in the future, maybe it is good to start with a little about Git first.
Most SW developers who has worked for a decade or more would be familiar with one or the other of the centralised version control systems that was prevalent at that time. I started out with building a windows client for CVS as part of industry project. After that, for quite a lot of years was using the monster called ClearCase, and then I moved to a more modern project based on Java and Agile practices and there was introduced to Subversion/SVN and things started looking good. Everything looks good after ClearCase.
SVN looked good, and it seems there was nothing better to wish for. But then came Git and it suddenly felt empowering; that’s something strange to be said about a version control system. Git was built by a developer for the developer. Very few people would write a poem about SVN, ClearCase or the like, but Git is different.
Till then I dreaded to branch fearing the cost,Or more the dread to think of the merge,But then came Git,And lo! I am in branching heaven!`
There was no more need to be heavily depended on the source control operations team. Since it is a distributed version control system, everyone has a copy of the repository in his laptop, that one can work offline with. That is incrementally commit to, branch out etc as with any SCM (source code management). Linus designed and implemented Git as a SCM replacement for Linux as the one they were using Bitkeeper became licensed. The key here is distributed version control system. Linus Torvalds presentation regarding the rationale of why he developed Git , in his inimitable style is a must watch before you do anything with Git.
What should be realized is that there are more important things than branching strategy that has to be correct for CI and CD to work. This could start as early as requirement analysis and splitting features to smaller User Stories that can be released independently and integrated more frequently to trunk.