CODEWITHSUNDEEP
git
Allen Hu
Allen Hu

Reputation: 665

Maintaining multiple versions with same code base

I'm currently working on a (laravel) project that should result in two versions, but I find myself constantly rebasing and merging my code. I guess it's my git workflow that is mistaken, but I need some heads up on what I'm doing wrong.

My macro-question is: Much like IntelliJ maintains dozens of IDEs that have almost the same basic functionalities but are built into different versions, is there some specific VCS tactic or best practices for doing so?

In Detail

Say I have a project (one code base) that is for two clients A and B. A wants a blue theme and B wants a green one, so currently I just have them on two separate branches. These branches often have client-specific changes.

Now I have a new feature that I want to work on, which applies to both A and B. This is how I do it now:

  1. Create branch new_feature_branch from main
  2. Finish the code on new_feature_branch
  3. Send PR and merge to main
  4. Rebase client_a_branch and client_b_branch on main

This works fine on normal features, but when there is a minor bug (say, a typo) on the main branch, having to go over all these every time just so that the patched code could get to the client branches just seem kind of awkward and... unintuitive(?) to me.

I just want to make sure if this is how "multiple versions with same code-base" projects are handled generally? If not, how is it commonly done? (A simple link or keyword to what I should look into would be helpful enough)

I'm totally unaware of how things work in production, and I'm also not confident about my git knowledge, so sorry if this question seems naive or whatsoever.

Thanks in advance!

Upvotes: 4

Views: 1386

Answers (1)

TTT
TTT

Reputation: 29129

Rebase should be fine if:

  1. All of the unique commits on your client branches are linear. This means you don't have new merge commits (perhaps from PRs).
  2. The client branches are not actively being developed by other people. This is (normally) important because after rebasing you have to force push, and if other developers are actively branching off of the client branches, coordination will become necessary every time you rebase.
  3. The client branches don't stray too far from main. "Too far" is certainly subjective and case dependent, but imagine a scenario where each client branch has 100 of its own commits that heavily modify shared code. Eventually the rebase could become tedious with many merge conflicts needing to be resolved during rebase.

Note: Commonly held beliefs regarding rebase are ending here, my opinions are below.

What should/could you do?

  1. Continue with your rebase strategy temporarily until either you can't or it becomes too tedious, or you make a change such that you no longer need separate client branches (described in #2 below). If you can no longer rebase but haven't achieved #2 yet, then start periodically merging main into the client branches instead of rebasing them onto the main. I tend to prefer that workflow in general: "Rebase when you can and it makes sense, otherwise merge."
  2. Take steps toward having just one main branch with minimal configs/templates per customer to handle the differences at deployment time. I've worked with many companies that have multiple clients ranging from slightly different code bases, to vastly different code bases. Obviously the closer the code bases are, the easier it is to merge them. Note whether you can do it at all often comes down to who owns the code. If you own the software, then it's easier for you to control who gets what features and when, and a single code base with flags/switches/etc is likely achievable. If the customer hires you to do custom code for them only, it's more difficult, perhaps even impossible to have a single code base. At my company we recently finished merging 3 different customer code bases into one main branch. It took years to complete because of the complexity. Now we have different configs for each customer that have separate deployments, and for those that share the same physical runtime environments we have code switches or DB data differences based on the logged in user's company. Since we made the switch, all new development and deployments have been greatly simplified.

If as you described, the only difference between clients is color themes or minor differences, then #2 should be fairly easy to achieve, I think.

Upvotes: 2

Related Questions