Branching strategy in the real world

I’ve been using Git for over five years now and have read numerous articles and posts about branching models and strategies and frankly these all seem too simplistic and implicitly assume things that are unrealistic.

1. Multiple apps in a repo

They seem to assume a repo contains just one app so naturally the branching patterns described looks nice on paper but really gets challenging when a repo contains many disparate applications (for example 40+).

2. Unexpected delivery changes

Many projects deliver three, four or more applications so a branch dedicated to the project accumulates changes to all of these apps as developers progress. However at short notice we could be told "OK we don’t want to include the changes to SuperApp in this release, we’d like them in the next. (The next of course is another branch - perhaps already being worked on).

Reality

We’ve been creating dedicated project branches to do our work, every deevlopers has a fork and so they have the same branch in their fork (if their working on that project). The pull frequently and push to their fork and create pull requests, these eventually get approved and merged to project branch in the main repo.

Once tested and released the branch is merged to master and deleted.

However if we’re asked to not include this or that app in the release of the project it can be hard to unravel these from the branch, sometimes a single commit might have touched several projects for example. This becomes time consuming and error prone but we’re expected to be able to adapt to this short notice change.

Because of 1. we can get situations were several developers are working on different projects but one or more apps appear in these projects, so Tony might update two or three apps and Jill and Mike might also be updating some of these, this results in disparate changes to several apps on several branches and always increases merge conflicts probability, especially when coupled with 1. above.

Personally I do not think there is a strategy described anywhere that caters for this, unless developers apply very strict discipline and are very robustly policed by admin staff we’ll get problems and we frequently do.

Discuss…

Don’t you think about having different repositories for apps?

We use different repos ,but we have one repo which aggregates all repos as submodules.

@amarazm wrote:

Don’t you think about having different repositories for apps?

We use different repos ,but we have one repo which aggregates all repos as submodules.

I’ve never seen the point of multiple repos when you have a large base of applications. Any project could potentially touch any app and so you then need to create identically named project branches in each repo and police these and so on.

Additionally having all apps in a single repo makes it easy to share certain files and so on.