CODEWITHSUNDEEP
gitgit-clonegit-checkout
giuliocatte
giuliocatte

Reputation: 259

generating a Git repo from two different codebases

We have this software which lived without version control for a long time, both in the production environment and the development one, with developers patching manually the files at every change (or changing only the production env for hotfixes, sometimes). Like in the jungle. Now, we are putting this under Git version control: I created a repo on the production env with a "master" branch, and pushed it into a new "origin" remote on a dedicated server. Now I'd like to have the dev env as a working copy too, but I'd like to NOT lose the differences with the prod env (something might be useful, who knows?).

I guess a possibility would be: a) moving away all the files b) cloning from origin c) re-moving my files in their original positions

In this case, probably Git would correctly highlight differences between the two codebases. There is a less brutal way to obtain the same result?

Upvotes: 2

Views: 106

Answers (3)

Raul Nohea Goodness
Raul Nohea Goodness

Reputation: 2579

You need to decide on a long-term git workflow. A simple one would be to:

  • keep the "master" branch as the production branch
  • create a "development" branch as the development branch

You already have production in master, so you can do the following to get dev in "development"

  • git branch development
  • git checkout development
  • # delete all production files in your working directory (except the .git directory)
  • # copy all the development files to your working directory
  • git add .
  • git commit -m "import of development branch files"
  • git push origin development

At this point, you will have a master (production) branch and the development branch in the same git repository, both on your working directory, and on the origin server.

You may now do diffs between either branch's commits and see the changes.

You may also maintain each branch separately. Eventually, you can decide to merge commits from development into master as you see fit, or else cherry-pick (hotfix) specific commits on both.

Upvotes: 3

fejese
fejese

Reputation: 4628

  1. git init in the soon-to-be working copy to initialize repo
  2. git add remote origin ... to add reference to remote repository
  3. git fetch origin to make the remote branches available without modifying you local files
  4. git checkout -b dev to create development branch
  5. git add :/ && git commit to add and commit all local changes

Now you have your dev env committed in a branch and you can work with it from here. Push it to make it available on the dedicated server as well.

Upvotes: 1

Tadeusz A. Kadłubowski
Tadeusz A. Kadłubowski

Reputation: 8345

On your development machine initialize an empty Git repo: git init .. Add the origin repo: git remote add .... Fetch all the changes from the remote origin repo: git fetch origin. Fetching will only create a remote branch origin/master, and will not affect local files at all. Diff the local files against the remote branch you just fetched from the origin repo.

Maybe before you fetch you can commit all the local files into a local branch. That would make it more comfortable.

Upvotes: 0

Related Questions