Question

I'm a relative git newbie. I have a repo that got a little complex on me and I've now fallen down the rabbit hole.

I started out with a Joomla site that had it's own repo (we'll call it Repo A). After that site had been launched, our client wanted us to develop 3 similar sites. For the most part the sites were to be the same with just some different styles over the top. So, I took Repo A and forked it off into 3 new repos (call them B,C, and D).

As time went on, I found bugs in Repo A that needed to be sent down to it's children. To do this, I created a branch on Repo A called shared. I would then cherry-pick the commits I needed to share from "master" and bring them over to "shared". Down in the children repos I would then pull in the "shared" branch from upstream (Repo A) so I would have the most recent fixes. As you can imaging this was quite the cludgy solution (All the "shared" branch commits are also over in "master" but with different commit ids) -- but it kind of worked.

Now that these sites have matured I'm finding that there is less and less being shared amongst all of them. Nearly all commits need to be shared with another repo, but there aren't too many commits that all 4 repos need. I'm thinking that I should be organizing more along the components than the sites. For instance, Component 1 is in Repo A and Repo B -- Component 2 is in Repo A and C -- Component 3 - is in Repo A, B and D -- etc.

So, to my question:

  1. Assuming I hadn't screwed everything up, what is the best way to handle these shared components? Should those be branches or would it be better to make those unique repos?

  2. Is there anything I can do to get myself out of this rat's nest? I can't really go back through my history and move around commit by commit because there are hundreds of them. I'm trying to figure out if there's a way to make it work for going forward. I thought about branching my "Component" branches off of the "shared" branch of Repo A, but I wouldn't be able to merge that branch into Repo A "master" because I'm concerned all the cherry-picked commits on "shared" might undo/overwrite changes from commits that have occurred since the cherry-pick on "master". I had read about orphaned branches, but that doesn't seem to work either because the parents are required to not get conflicts with the existing branches.

Any git masters out there have any ideas on how to get this set up a little more usable? Thanks so much for the help.

Was it helpful?

Solution

The simplest way would be to keep your current history untouched, but:

  • remove the common files, and add them in a new Component repo
    (repeat that for every common Component you have identified)
  • declare the relevant ComponentX repos as submodules of your current existing repos.

It is easier than trying some git filter-branch to split your existing repos.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top