1

Brief overview

We are product company and we are providing solutions to more than 50 clients and they are growing each month and we have fairly simple branching model which I would like to upgrade if possible.

The model

We are doing agile therefore we have sprints and releases. Each month or two we are opening new release branch from master which will be stabilized and later will be given to clients that are interested in features in it. So far so good. During development new clients are created. Let's say we start working on a client A and we decide that this client will go with certain version, let's say release/1.0 so we make branch release/A_1.0 and we start our development there, once we are done we merge release/A_1.0 -> release/1.0 and we deploy to production from release/1.0 branch this client.

Before I continue to explain where the problem is I will set some rules that we are keeping:

  • Once release branch is open master is never merged there.
  • release/{client}_{version} branches are occasionally updated with release/{version} branch (version numbers should match).
  • Only hotfix branches are merged into release/{version} branch.
  • Before opening new release/{version} branch 2-3 previous version release branches are merged to master so all the hotfixes from these previous versions are in the new version as well.
  • Hotfixes from previous version are not allowed once release/{version} branch is opened.

Where is the problem?

Tbh problem is bad planning, but this happens and it can't be avoided. Let's say we negotiated with a client(B) and we decided to give them version 1.0, that would be opening a branch making it release/B_v1.0 while we are developing this client in this branch time goes by and our product team sprint opens another release, for instance 1.1.Sometimes development process of client takes enough time for product to open if not one but two or three new release/{version} branches. So if this happens management and the client might decide to go live with newer version(let's say 1.3 - previously it was developed for 1.0). Now what it has to be done is that we need to open branch from release/1.3 for this client and then merge previously opened branch - that would be making merge release/B_1.0 --> release/B_1.3 and this can be PAINFUL to be done. Why?

Because release/B_1.0 is occasionally updated with release/1.0 this means that all hotfixes from version 1.0 will be in release/B_1.0 (this can't be avoid as some hotfixes are crucial to development of the client) and when it comes time to merge release/B_1.0 --> release/B_1.3 this will include all these hotfixes from version 1.0 in release/B_1.3 and later when release/B_1.3 --> release/1.3 merge is introduced they will be included in version 1.3 which is forbidden.

What I do in situations like this?

I cherry-pick all commits/merges, that were in release/B_1.0 and are not hotfixes that came from release/1.0, into release/B_1.3 but this can be really time consuming and mistakes can be made also due to the fact how git history works.

I proposed that these client branches can be locked for committing so only merges goes in there and when this kind of merge can be made I can easily cherry-pick only the merges from relevant branches(ignoring merges from release/{version}) and not worry about leaving trailing commits, but this means that everyone working in this branch has to make his own branch and merge it in it which kinda slows the development process in my opinion.

Do you have any other suggestions that would ease such merges?

Improve this question
2
  • 1
    This question is too broad IMO. You would get a better response showing us a careful branching diagram and pointing out where the problems are happening. Commented Jun 8, 2017 at 8:04
  • Do you know any tool that might help me reproduce my behaviour without much overhead , cause I didn't find anything useful beside learngitbranching.js.org and create my case but still doesn't seem it will do the job? Commented Jun 8, 2017 at 9:22

1 Answer 1

Reset to default
1

Why not manage these clients for different git repositories?

Manage all the clients in a git repo seems efficient, but actually it’s not. And it based on that all the clients have the same requriemnts/bugs or you must negotiate them to sync with the other.

So you’d better manage them separately. Even if two clients have the same features, you can use the features cross repositories easily:

# In repoA git remote add B <URL for repo B> -f gitk --all # find the commit of repoB you want to use in repoA git cherry-pick <commit in repoB>
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

It seems to me that this is a lot of redundancy, but I will investigate it further, thanks for the suggestion.
Doesn't that mean that we need to configure automated deployment for each repository everytime? Most likely yes .. I don't think this is a good idea.
If it's easy to align all your clients to use the same version, of cause you can put them in the same repo. But generally, it's hard to carry out since different clients have different requirements and features, and it make more sense to treat them differently.
I think I'd rather suggest my company doing this model but instead of repositories we would have multiple release branches, one for each client. I think that multiple repositories is a bit too much overhead since we have 70-80 clients thats a lot of repositories...

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.