Reputation: 325
I have a problem that's very hard to google, so I decided to ask about it here.
I've created a system (a rails app) that handles user registration for a conference. The system is under active development.
Now, I'm helping to run another conference, and I want to use pretty much the same system, with only minor changes to the codebase. However, I want to maintain some level of parallelism between the two projects, so I can easily push generic improvements to both systems. I also want to be able to change both independently.
My gut feeling is that I should use a branch for each conference's system, and then whenever I have a master change, run git merge master
in both projects.
Is there a smoother way to do this? Does git have a built-in method for handling automatic pushes to branches?
Thanks in advance. I apologize if this question isn't as "answerable" as stackoverflow likes.
Upvotes: 2
Views: 55
Reputation: 48566
I would use two branches for now, but heavily prioritize fixing the code itself to support the modifications in a single codebase. Otherwise you'll experience more and more pain as the code changes and/or the variants diverge: bigger merges, more space for conflicts, harder refactoring, etc.
Upvotes: 2
Reputation: 8324
What you propose (3 branches) would certainly work, but if I were to do it, I'd probably make 3 git repositories rather than 3 branches.
There is no way for git to automatically merge the master branch (your shared library) into the two implementation branches. You would need to do that yourself.
Upvotes: 2