I'm working on a Chrome/Firefox extension. I started building it when I was using Chrome. I have since started using Firefox more. The extension is already available on the Chrome Webstore and I also wanted to make it available on Firefox as well.
In my laziness sprint for an MVP, I ended up just branching the repo to a master-ff branch to make the Firefox related changes. Which turned into a decent amount of changes, some not specific to the Firefox version which now need to get ported back to the Chrome version. The only way I could really see forward with that is to just go back through the commits to master-ff and see what needs to go back to master and merge/copy over the changes.
Am I Dumb And Lazy or is This a Valid Way to Handle Separate Versions of the Same Thing?
Any other suggestions for handling this situation? Two seperate repos? Git but I'm not doing it right?
Photo by Brina Blum on Unsplash
Top comments (3)
I'm not confident enough to answer this, but I'm subscribed to the thread because I might have follow-up questions.
But...
I find the answer to this type of question is very often "yes, that's valid".
I guess it does kind of fall into the category of "if it's dumb but it works, it's not dumb". I'm just curious to see what other ways people are solving this problem.
I wouldn't say dumb, and lazy isn't a bad thing :) But personally - and I focus more on code than git usage so I'm biased - I would try and do something with the build and module structure.
Pretty sure you aren't using gradle or maven, but if I were doing this as a Java project I would structure it with a common library module, a module for chrome, and a module for firefox. Have the build script generate the appropriate artifacts and keep the git setup as simple as possible.