Search code examples
gitversion-controlgit-rebasegit-flowgit-cherry-pick

Which git workflow to use for both product development and product customization

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?

Solution

  • 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