Great example on using git for small projects, simple merge
I asked the following question on stackoverflow:
"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 is the response.
--- Begin Quote ---
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.
--- End Quote ---
Quote is from user, 'gahooa'. Thanks for the response.
Note: this material is attributed to stackoverflow,
what-are-some-simple-good-ways-to-eventually-merge-two-directories-of-source/1112232#1112232
"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 is the response.
--- Begin Quote ---
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.
--- End Quote ---
Quote is from user, 'gahooa'. Thanks for the response.
Note: this material is attributed to stackoverflow,
what-are-some-simple-good-ways-to-eventually-merge-two-directories-of-source/1112232#1112232
Comments