Learn about git recently and compare it with the previously used SVN to get a better understanding of the pros and cons of both.
In fact, git and SVN are quite similar, there are submissions, merging, and so on, it seems that this is the basic operation of the source management tools.
1. Git is distributed, SVN is centralized, the advantage is not too much conflict with other colleagues, their own code written on their own computer, after a period of time to submit, merge, or do not use the network to submit locally;
2. Git download down, the local do not have to network to see all the log, very easy to learn, SVN needs to network;
3. Git encourages sub-branch, and SVN, to be honest, I use branch a few times, SVN comes with the branch merge I really useless, there is a merge with the Beyond Compare tool merge and then commit;
4. Tortoise also has a git version, really good stuff;
5. SVN before committing, we all suggest is to update first, with the local code compiles no problem, and ensure that the development of the function of the normal and then submitted, it is actually very troublesome, several times colleagues did not first Updata,
Commit, there have been some errors, the delay in the time, git may be less of this situation.
You can also search for a comparison of git and SVN commands.
There is an article in this discussion, landlord think SVN no use, I more agree with Ghoststears's point of view.
With GIT,SVN, pure trash.
Ghoststears:
Everything, in the final analysis, is a human problem, and tools are just tools.
SVN is centralized, and you say the coupling. But on the other hand, this also requires the specification of the developer code: Do not have a function to do a lot of things, do not write a file a lot of classes.
In addition, it is meaningless to commit non-operational code to any version control system. This is one of the core ideas of version control. That is, the granularity of the commit: atomicity. The so-called atomicity, that is, to accomplish a task, this task can be a function declaration, or a function implementation, or a subsystem. But the sign of the completion of this task is that the code can run, the code cannot run, at most, half the task is completed. This is not in line with the idea of version control. Just think, you update to a certain version of the time, the code unexpectedly is not running, what is the mood ...
Submitting code that cannot be run is entirely a matter of developer quality or company management processes and mechanisms.
In addition, many people stressed: I work at night to work at home, can not be submitted ... To attack the centralized version control tool. And do not speak of attitude towards work and life. First look at the domestic enterprises, anti-personnel such as anti-thief more to go. How many people can carry a notebook, the company's source code to check out ...
In a version control system, the tool is just one of the rings. Use the company's strategy to choose the right tool. Version Control! = Version Control Tool!!! = Source code control.
Finally, people have their own preferences. Excessive, no need at all.