9

We have been using git-flow for a while for the development of a software framework. We have the masterand development branches in a single repository.

Recently, different customers became interested in buying the framework, which requires a customization of the framework per customer.

So far, we branched a new feature-customerXYZ branch for each customer from the master, did the customization there and kept the branch open, after the customization was finished (which prevents 'infection' of the product master/development branch from the customization).

Parallel to this, the development on the framework itself goes on using the usual git-flow workflow on the product master, development, features, hotfixes and release branches.

There are two common scenarios happening in this context for which I think our workflow cannot handle optimally:

  1. Development of the feature-customerXYZ branch can contain commits worthy of being implemented in the product master/development branch. Since the feature-customerXYZ branch will never be closed, those commits have to be rebased or cherrypicked to the product branches, which requires extra work after the customization and is error prone.

  2. Hotfixes discovered while a feature-customer branch is open are handled by git-flow by merging the opened hotfix branches after the fix only to the product master and development branch, but are not merged into open feature-customer branches (to be more precise: they are not merged into all open feature branches).

Is there a git workflow that can handle this in a concise way? Is there a clever alternative instead of merge, cherrypick or rebase of the commits to the product master/develop or the open feature branches, respectively?

Andrew Gray
  • 3,593
  • 3
  • 35
  • 62
gehbiszumeis
  • 3,525
  • 4
  • 24
  • 41
  • 1
    Could you move the code to GitHub and use pull requests? – Andrew Gray Sep 25 '18 at 04:37
  • Thanks for the comment. We use Bitbucket by Atlassian. There is also the possibility for pull requests. I understand, that a developer can use a pull request before merging a feature back to `develop`. What you're saying is to also use pull requests for merging the overall valid commits from `feature-customerXYZ` to `develop`? So the project maintainer can select which parts of the code are useful for the product `master`/`develop`? – gehbiszumeis Sep 25 '18 at 07:25
  • 1
    Yes, that's correct. – Andrew Gray Sep 26 '18 at 04:11

2 Answers2

3

While it is theoretically possible to maintain customer deviations in dedicated branches as @VonC proposes, I dare to say that it is technically very difficult and does not scale.

Yes, you can have jobs (in Jenkins or something) that will automatically rebase your deviations against a master branch, but when it comes to tooling, you are on your own. As a minimum, be prepared for situations like:

  • rebase will fail with conflicts - easy, git will let you know
  • rebase will succeed, but the result will contain logical conflicts - this requires a good test coverage, because no tool will be able to warn you

Instead, I recommend to minimize the deviations, and after doing so, keep them all in a single branch, side-by-side.

This is typically possible if your project is composed of modules. You did not mention any details of your project, but most languages support some form of modularity, so I hope that this is your case, too.

This way, you can try to concentrate extension points for the deviations into minimum modules (ideally one), and have multiple variants of these modules in the project.

The advantages are obvious:

  • it is simple
  • your CI is easy to configure to build all modules (=customer deviations) at once
  • you can run tests on them, and easily decide which test is for single customer, which is generic, and which is specific to a deviated feature rather than customer
  • also, you don't have to lock your branching model because of this, and can still use git-flow or whatever fits your needs

The only downside is, when you release your project for just one customer (with tagging and other ceremony), you do it also for all the others. It is not a big deal usually, and on the other hand, it motivates making the deviations feature-wise, which is good.

To minimize deviations, I recommend following techniques:

  • some deviations can be better represented by configuration options
  • others can be rather feature-specific than customer specific
  • and the best one, some deviations may be rejected - though this is rarely possible

Just to summarize - minimize the deviations and build them all, side by side.

Spreading your codebase into multiple master branches (per-customer) will quickly become unmaintainable.

Petr Kozelka
  • 7,670
  • 2
  • 29
  • 44
  • Thanks, for the detailed reply. I do believe that your approach is the more correct one and should be therefor the accepted answer in general. Although in our special case @VonC's answer is fitting better given the preconditions in our group. – gehbiszumeis Oct 01 '18 at 13:16
  • Agreed. I focused on the specific case, but your (Petr) answer is a good advice to follow. +1 – VonC Oct 01 '18 at 13:44
1

also use pull requests for merging the overall valid commits from feature-customerXYZ to develop?

Yes.

So the project maintainer can select which parts of the code are useful for the product master/develop?

No: the project maintainer should only accept PR that are trivial to merge (fast-forward), and run tests to validate the PR is working.
He/she is not in charge of selecting parts: only the developer should select them (as he/she is aware of what needs to be exposed to dev/master.

So for case 1, cherry-pick or rebase is still needed, in order to make a dedicated branch (separate from feature) which will then submitted to dev or master through a PR for validation.

For case 2, hotfix should be merged to develop, and each feature branch can, at its own time, rebase on the latest develop state, hence including the hostfix

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250