In this post I will go through how to use git together with subversion side by side. Lets say your working in project which uses subversion as the SCM. But you and your team is asked to implement a CR. Now you have a requirement to share the code between your team members while you are working on different parts of the CR. One way is to commit changes to main repo. But if you have CI this will lead to build failures which is not good. So the other option is to use a searate repo for you requirment. So I have choose git for this. Its because it will not conflict with your svn metadata. And its distributed, therefore you don't need to setup a seperate server for this.
Here how you do it:
1. First tell one of your team member to checkout the project from subversion.
2. Then create a git repo for your project.
3. Create a .gitignore file and add the following line to avoid .svn metadata folders getting into to your git repo.
.svn/
4. Now add all files you want to track onto git index. Add the rest of the files you don't like to track by git in to ignore list.
5. Then commit the changes to the git repo.
6. Now tell the other members to take a copy of your .git folder and past it into their project folder. After doing that they can do a hard reset which will sync the working tree with the git repo that was just copied.
7. Now they need to add your repo as a remote repo. You need to share your project directory to do this.
8. Then they can do a fetch and do a merge to make sure it works fine.
9. Now you could add them as remote repo as well and do step 7 to make sure its working.
10. Now you all can work on your working copy as you wish and commit things into your local repo when you think it's done and ok to share with other members.
11. To get your changes they need to do a fetch and merge.
12. If they get a conflict during the merge git will not commit the changes. So they need to resolve them before committing. One way to do it is by manually resolving the conflict by using git merge tool. Other way is checkout using --ours or --theirs options. The first will keep the original file and ignore the remote changes. The second will do the opposite. After resolving the conflicts you need to add the files into the index and commit the merge changes.
13. If change your mind and want to revert the merge because you got conflicts, then do a hard reset which revert the merge.
14. When its time to commit changes to subversion, then you can do it using your favorite subversion tool. This will not be a big task since you have the svn metadata. One thing important is to do this commit by one person always. Other wise you see conflicts because you have the same change in your working copy with different subversion metadata since you have taken those changes from git. But its matter of ignoring those conflicts since you know they are not and committing the changes you want to subversion.
If you get things configured correctly you will save lot of time in applying patch files and copy past code here and there. But if you not get it configured correctly then you will loose lot of your time on just trying to share the code. Time is money for your managment ;).
