I have inherited a large codebase where the development branch has been under git for some time, but production has not been under any version control.
..I KNOW.
The method for promoting code to production was to manually copy all changed files back and forth from dev and prod until they're synced up, and deal with the subsequent disasters as quickly as possible, over the weekend.
I have since put production under under a brand new instance of git git init/add/commit, and now all these hotfixes made live on production can be tracked, (as I go back behind everyone and make checkpoint commits daily). I have set 'origin' on production to the be the same as development, so that production is now a separate branch of the same repository, without a common ancestor.
I want to have a real development process going here, and that means I want to merge the branches together.
It's worth mentioning at this point that development goes on on both development and production branches, as the lead developer likes to hotfix things live on production. I believe I can change this habit of his, if I can offer the alternative of applying a fix to another branch and merging that into production.
But to do that, I need a branch that shares a common ancestor with production.
..what do I do? I could merge production into dev, which would generate a ton of conflicts that I could try to resolve by hand (that is, mergetool), but that sounds like a TON of work.
Is there any better way?
I'm still learning to be a git guru, and I want to get this done, but.. what's the best way?
First: Sorry Jon, that sounds like a mess. :-(
Here's one approach:
git master branch: This should be current production. (easy)
hotfix branch(es), from master: These should be the hotfixes you describe being done on production (easy, assuming the person making the fixes actually does this)
development branch: Start with a branch from master. Then copy the files / changes into this branch just like the team was already doing to get files from development on to production anyway. Merge in master anytime a hotfix gets applied to master. This will result in a branch that can be merged into master conflict free, but with a large diff that can be reviewed by the whole team. (hard, but worth it)
Once you get through this once you'll be able to start following a much more standard approach like git-flow.