SVN + GIT = have both fish and bear's paw

Git has been used for some time. from the first day of using git, we plan to gradually discard svn. all functions of svn can be done by git, and git is doing better. besides, git has many other features that svn cannot meet. what is the reason for continuing to use svn? Well, there are many reasons. for example, it has been some time for git to be used on windows. from the first day of using git, we plan to gradually discard svn.
 
All functions of svn can be done by git, and git is doing better. besides, git has many other features that svn cannot meet. what is the reason for continuing to use svn?
 
Well, there are many reasons. for example, TortoiseGIT has not been developed (or is there no such plan at all?) due to the performance problem of git on windows ?), Other people in the team are not used to using git.
 
So can I have both fish and bear's paw?
 
=== SVN pain points and itch ===
 
The biggest problem with svn is that it does not support distributed development. distributed is not necessarily a large-scale collaborative development scenario like Linux Kernel.
 
For example, if you want to bring the unfinished work home, but you cannot connect the home to the company's svn server, you cannot commit. In fact, this is also a distributed development scenario.
 
You will say, then you should not commit... I can't do it. I have a bad habit. I often make small changes, but I regret it 10 minutes later and want to change it back. I can only retrieve the previous and previous changes with frequent commit.
 
Of course, I have bad habits, so I won't commit it to the trunk or main branch, otherwise it will be squashed to death :-)
Therefore, I often have many temporary branch requests for merge, which is very frequent... the merge in svn is not fun.
 
I have to say that the repository design of svn is very poor. it is slow, especially when the project scale is up and the development cycle is long. The repository is rapidly expanding. The project tree is everywhere. svn is also annoying.
 
However, TortoiseSVN is really convenient. many people use SVN because of its convenience.
There are countless IDEs that support SVN.
 
SVN, both painful and itchy ....
 
=== GIT power ====
 
Git is very fast. it is really very fast. it is faster than Xiao Li Feidao... (of course in Linux ).
Try the various tags of the checkout Linux Kernel. you have to admire the speed ~
 
In fact, for small projects, the speed does not matter, not a few seconds, git has a lot of cool things.
 
Git diff is very powerful and really powerful. compared with any two historical versions, it is fast.
 
Branch in git is too simple, and branch merge is also very nice, not to mention three way merge. of course there are many cool features, such as merge with others' git tree... in fact, these are more or less due to distributed features.
 
There are other features that are not available for development by small teams such as email commit.
 
=== Have both the fish and the bear's paw ===
 
First, svn is used, and svn is used for main version management (take care of the team ).
 
Create git repository: git init in the project directory.
This only adds a. git directory under the root directory of the project. it does not have garbage like svn or cvs.
 
Next, create the. gitignore file and add the files that do not need to be managed by git to this table, such as. svn. or enter. git/info to edit the exclude file.
 
Add git: git add.
 
It's that simple.
 
Since then, small and temporary changes can be managed by using git, which is fast and accurate and does not affect others. because you only use local git repository, it has nothing to do with others.
 
Each person builds his/her own git tree and does not interfere with each other. of course, if you want to merge others' trees one day in the future, you should create a bare public tree, clone one for each person, and then work under your own branch, offline commit is usually used, and push is required.
 
Working at home? No problem. you can still commit it. git is distributed.
 
After returning to the company, want to commit to svn? No problem. in git, checkout the "working code" version you want, then commit in svn, git then checkout HEAD, and proceed.
 
=== Conclusion ===
 
Combining svn with git brings the following benefits:
1) it does not conflict with other members who use svn separately
2) enjoy the benefits of git Distributed
3) meets svn commit working code requirements
4) svn large-granularity management to reduce the pressure on svn repository.
5) svn continues to take advantage of the convenience of the GUI.
 
Therefore, SVN + GIT = both fish and bear's paw
 
 
Interestingly, when Linus was designing git, it said :"... when we encounter a feature that is not sure what design should be taken, we just need to design it in the opposite direction of svn..."


From Step Third