I am a member of a project team with somewhat unusual (or at least from my perspective) release methodology and team dynamic. The way we have been doing releases is rolling out a single functional bundle at a time, all of which, as a rule of thumb, was done by a single developer. Developers do work on their virtually independent functional areas, that are all nonetheless part of the same deployment bundle (WAR file and its corresponding Git repo), concurrently but it is not certain or clear whose change will go in in what order. It often depends on whoever finishes and gets their stuff tested first. So Dev1 may be working on Change1 within TeamProject and Dev2 will be working on Change2 in the same application, and sometimes their changes may be interdependent (such as changing a shared API) but it is not clear when each will be rolled out to PROD.

The way we currently do Git branch management is that each change gets its own remote branch, which defacto means there is one remote branch per developer. The biggest problem I see with that is that, in order to be refreshed of your teammate’s changes, you have to manually sync your branch to their branch, which is a manual and often a PIA process, excuse the term. It may be okay for the developer whose release is the very next one in line, for his branch is what the next version of the release will look like once it is rolled out (in the existing single change release setup). But it surely does not work for the developer whose release comes right after as (s)he has to build their changes on top of the first developer’s changes. However, they don’t want the second developer to push into the first developer’s branch as to keep the change pristine and exclude everything else from that specific release. So the 2nd developer has to do the merging of the 1st developer’s branch into his branch and then push his stuff into that branch on top of the 1st dev’s changes. That would not be half as bad if it were clear who the 1st and who the 2nd developer is, IOW, whose changes will first be rolled out but that is a contingency, as explained above.

Now, by the nature of this post thus far, it is clear that I am not the father of this process and that I am aware of many of its inherent flaws. One notable flaw happened recently when we were promoting our changes to the TEST environment. I had been working in my dedicated branch but the version that was deployed to TEST was built out of my peer’s branch (it had his changes only). I was about to push my stuff but didn’t want to lose his, as I value our QAs time and wanted his and my tester to be able to work concurrently. So I synced my branch to his (cherry picked his changes into mine, after the common ancestor) so that both his and my changes were in. It worked fine. However, he wanted to push a bug fix a day later and did it out of his own branch without syncing with mine. Guess what happened: my changes were gone from the build and only his were present. Needless to say, these multiple remote branches make continuous integration (which I would like to start doing and is not presently done), difficult or virtually impossible.

Frustrated with all this, I have been working on a proposal to my team how to change this configuration. My idea is to have an INTEGRATION SHARED REMOTE BRANCH that everyone pushes their stuff into and that is something like a work-in-progress branch that anything can go in as long as it compiles and passes tests (basically passes the build). CI daily builds could be done out of this branch. Then there is a release branch to which stuff is not pushed in directly but is cherry-picked out of the WIP branch to correspond to what we want in the release. So if we think that Dev1’s changes will go in the immediate next release, we cherry pick his changes in it. But the important thing is there is one UNIFIED branch for all the developers on the team that work on the same project as opposed to them working in each one’s isolated silo. This way, we could actually rebase our local branches with the shared remote continuously and get our peer’s changes timely as opposed to when they become part of the master (or production) when the volume of changes to be synced can make the merging process a living hell.

I would like to inquire about the pros and cons of my proposed methodology vs what the team is doing presently and is explained above. And generally, with the idea of the current release culture in mind, which perhaps is not within my powers of changing as it is affected by many members of the organization above me, what would be the most efficient and painless teamwork setup.