inter-branch tracking

We have a lot of branches (because we have a single repo) at any one time. As is common, feature branches frequently get merged into master as code is released.

I’m seeking a way to have some form of automatic analysis performed so that whenever new commits get merged into master we can see which other branches must be updated.

Clearly if a file in a commit merged to master also appears in a commit on some other branch then that branch must be updated (have master merged in and the app rebuilt). 

But we must also merge and rebuild (from master into some branch) if there is a folder in common, not just a file.

The folder may represent an app and we might merge some new stuff to master including a change to ProjectX/FileM.

Then if we have some other branch that touches a file ProjectX/FileK then we need to know and may want to merge master into the branch and rebuild the app.

The goal here is to try to automatically discover if merges to branches (often master but not exclusivley) require an app rebuild on some other branch, this is done “manually” now by people “knowing” what’s going on.

Of course Git knows nothing about projects, solutions (we’re primarily Microsoft based here) but a folder based analysis might be sufficient, at least as a first step.

So is there any way to do this currently?

It sounds like what you’re describing is that you have a repo with master plus a number of additional branches. Some of those additional branches are off of master and some of those additional branches are off of branches that are off of master. As you’ve noticed, things can get pretty complex pretty quickly.

There are a number of techniques for managing this complexity. The most common are:

  1. Branch off of master
  2. Do your work
  3. Merge changes back into master
  4. Go back to step 1

You’ll recognize the above as the essentials of the GitHub Flow. Or for longer-lived changes:

  1. Branch off of master
  2. Do some work
  3. Periodically merge the latest master into the feature branch
  4. Repeat 2 and 3 until work is done
  5. Merge changes back into master

For your situation where you have branches off of non-master branches, the flow is the same … just replace “master” with the name of the upstream branch.

Now, as to your specific problem. From your description, it sounds like you’re working with a bunch of really long-term feature branches. The whole point of having branches though is to decouple work from depending on each other. If you force branches to accept new changes as soon as they’re made, then you’ll be giving up the benefit of that decoupling. If that is really your goal, I would recommend working in shorter change cycles so you never diverge very far from master because you’re always making small changes and merging them back and then starting another small change.

Thanks for responding.

The problem is that if we have several branches (say all from master) and these branches touch the same app, each branch represents some “project” say June, July and Aug (assume the buisness expects monthly rollouts).

Now if each branch represents about two months work, then it’s essential that we do not begin to QA the app on the July branch unless it includes the changes to that app that are present in the June branch.

I’m seeking some way to track these kinds of relationships so that when a change is made to June we KNOW that July has not fallen behind (as has Aug) and we can at least be aware of this, we may not worry about it right away but at least we’d know.

So when the time comes to send the July version of the app to QA the tools would remind us that we MUST merge June in (or of June is now in master then we must merge master in).

This is not possible currently, Github offers no such capability and our GUI tool (Smartgit) also doesn’t.

Now imagine you have a few more than just three branches and imagine there are rather more than one app and you’ll see this is a very real problem.

I can envisage how such a tool might work, I mean all the metadata is already present and by “app” we could just mean “folder” (i.e. we could in such a systems define a list of apps - as metadata - by simply adding specific folders to some list) armed with the Git metadata (branches, commits etc) and the “list of apps” one could craft the logic for this, it would be neat to go to an overview page that graphically shows you branches that need to be updated and so on.

 Two branches that do not have any apps (app folders) in common can be regarded as “unrelated” whereas two branches that do have an app in common can be regarded as “related”. Related branches have commits somwhere along them, that refer to one or more apps (in the app folder list).

I’d love it if Github considered doing this since they are in a great position, alternatively I’ve toyed with creating a simple proof of concept MVC application myself that could do this analysis and present some nice looking web pages…

I posted a detailed reply to this, it didn’t appear but did appear later in a list (somewhere) saying it would appear after moderation, now there’s simply no sign of it - very frustrating.