I've inherited some code base that has been deployed into the field with minimal version control in the past year. In short, I have a main branch that is 1 year out of date, and 10 deployed versions of the code with varying newer features. I'm trying to figure out the best git practices to manage this. From reading about best git practices it seems like I could potentially go down a couple routes.

1. I could wait on version control until I have updated the main branch to include every feature from all 10 deployed versions of code... This is not ideal because I want to have version control right away.
2. I could keep updating the main branch while considering the currently deployed code as different releases with the ultimate goal as having all deployed code to be up to the same release. The problem here is I don't know which machines have which features. Is there a way to make a branch a release without the edit history from the master? i.e. How can I import a "released" codebase into a branch? Is it as simple as making a new branch, overwriting the main code with the release code and calling it a day?
3. I keep up ~10 different repos or projects with each individualized source code so I have source control immediately. (This seems like the worst idea.)

In any of the scenarios, it seems like I have to put a priority on making sure that the main branch has all of the needed features. I've only used git for very basic source control so any advice is appreciated!

CodePudding user response：

I'd call this so close to answerable I'm just going to go ahead.

git checkout -B snapA master
git --work-tree /path/to/deploymentA add .
git commit -m 'snapshot of deployment A'
git checkout -B snapB master
git --work-tree /path/to/deploymentB add .
# . . .

with .git/info/excludes set up to ignore unwanted things. Excluding all and only what you want will probably be fiddlier than that, you'll probably want to do some add -n testflights to tune the exclusions each time, but that's the idea.

Now you've got ten branches, and you can start test-merging them. Remember every commit is a draft until it's published and people not on your personal team are relying on it, you're doing first-draft work here, trying to construct a usable history from the existing content.

If you're sure deployment "A" is the oldest you can just tag that snapA commit and that's deployment A sorted. The important thing is, if you realize there's a better history than the one you're constructing, it's easy to just abandone the missteps and construct the better version, plus you're getting better with the tools every time.

The Git part of this will not be difficult.