Question

I have a source directory that includes a mix of different languages and files. Probably 100+ total files. I want to ‘fork’ that code and create a completely different version of the source. At this point, I will have version-1 of the code and version-2 of the code. I will not make that much development on version-1. I want to change the documentation headers and some other small changes. I will do a lot of development on version-2 and then come back a month or two later and merge version-2 with version-1 (set the latest version-2 to version-1).

But, I don’t want to lose any changes that I made to version-1 (say after months of small fixes).

---

Here are some other conditions that I would like to have.

1. I don’t want to centralized version control like subversion (This source isn’t under subversion anyway).

2. I was thinking I could use ‘git’ and then perform git on version-1 and version-2 as of right now. Do development on version-1 and then do two months of development on version-2 and then do a merge with git.

My only concern with git.
A. Ideally, I wish I could create the git repositories ‘after’ I have done ALL of my development on both version-1 and version-2 at one moment in time, say after two months of development on both repos. I would rather do this one time git create repository so that I could avoid doing a bunch of incremental commits?

B. I assume I might need some git GUI tools once I need to merge? Does git have any tools.

C. I hate the .git repository files, I would have to remove all of that after all my development on both repos. It might be hard to clear those.

…back to my numbered options.

3. Use the diff and patch command. I really hate to do this because duff/patch seems to basic.

4. Some other merge tool?

Answer 1

git only creates A SINGLE .git directory. svn is the one that scatters .svn directories in EVERY directory.

Your time would be far better spent learning useful git commands (such as git merge --squash). Use git, it will do exactly what you want with no trouble.

---

Edit:

With git, you can keep it all in one place, switch back and forth at a whim, and make as many commits as you want.

In order to reduce conflicts, you may want to keep Phase1 merged into Phase2 (as you make infrequent changes in Phase1). But that is totally up to you.

Here is how I would do it with git:

cd /path/to/project
git init
git add .
git commit -m "Initial Commit"

At this point, you are on the master branch with a single commit called “Initial Commit”. Now, let’s create branches.

git branch Phase1
git branch Phase2

Now, to work on Phase2:

git checkout Phase2
... work ...
git add ...
git commit

Switch to Phase 1 and do some work.

git checkout Phase1
... work ...
git add ...
git commit

Switch to Phase 2 and do some more work.

git checkout Phase2
... work ...
git add ...
git commit

At the appropriate time, pull changes from Phase1 into Phase2 (or the other way around):

git checkout Phase2
git merge Phase1
... resolve any conflicts and commit if needed ...

Repeat… You’ll be able to make as many commits, merges, and branches as you need to stay on top of the project.

Also, use git tag ... to create tags that point to a given commit. That way you can always go back without having to sort through the history.

---

Edit:

We run git from the command line, so I am not very familiar with what GUI tools exist. It should not be hard to find.

When you run into a conflict, git marks the files as conflicted (git status) and also merges them as best possible. Where the merge cannot complete, it leaves very clear markers in the files:

<<<<<<< yours:sample.txt
Conflict resolution is hard;
We went shopping yesterday.
=======
We go shopping today.
>>>>>>> theirs:sample.txt

So you simply delete one of the two, and edit the remainder to suit.

It rarely happens and is very easy to clean up.