| |
First, I showed a fundamental standpoint, I personally prefer Git, however, this is just a personal preference. When we need a technology plan to bring the entire team when, not by our personal preferences as a major factor in the decision, but should be sufficient to balance, the selection of the team, the company more efficient solution. Set aside personal standpoint, rational assessment of the pros and cons, may be what I recognized a senior programmer, architect or a duty.
My team, and now the technique of choice as a company-wide program is Git version control system, we have a total of about 20 programmers, using five or more programming languages, development around four maintenance projects, is a small start-up companies in research and development on the middle scale enterprises. Use Git as a version control system, before I joined the company, it is already a fait accompli, and I heard this, I was very pleased, because I said, I like Git.
On Friday, our company's new engineers in the weekly meeting of sharing Git, a colleague challenging road, why Git better than SVN? This question, asked if I personally, I may have a lot of reasons, but, as my usual mode of thinking, to convince others, must be given enough compelling reasons, can not use subjective factors to convince others , that will only lead to controversy.
For, "Why Git than SVN better" this issue, I really wanted to give a definite answer, but I search for answers in the process, the difficulties encountered. So, I try to stand in the position to give a negative answer, then we'll turn the debate, so there is the title of this article.
What are the advantages of SVN in the end
Broad mass base. I started using a version control system I use is already SVN, so, in the end you want to retroactive SVN when to begin, had to resort to Wikipedia, I found, the first official version of SVN, dating back to 2000 , fifteen years ago it has a history. Before Github a big hit, SVN basically in a position to dominate the world. Almost all companies are using SVN as an internal version control system, Google Code is set off a wave of open source software, for a time, almost the entire world programmers are using SVN.
I dare say that our company is currently recruiting programmers, yet never used the SVN. This means that if companies use SVN, then the probability of them quickly get started, is very high. Now Chinese SMEs and start-ups, the degree of difficulty of hiring a programmer, I do not want to elaborate - who is responsible, who headaches - If you are using SVN then learning version control systems use this kind of thing, your mind will not become a problem.
Excellent cross-platform support. Older kind of thing, not always disadvantage in cross-platform support this point of view, it will become dominant. Fifteen years, SVN accumulated on almost all platforms outstanding client software. TortoiseSVN success of the Windows platform, almost needless to say, and even programmers think, TortoiseSVN SVN is itself a reference to a small turtle, each code will be agricultural heart smile. Moreover, SVN command line client itself, it has a very simple and easy to use. Cross-platform simply and without any place can be picky.
Easy to use. Personally, I think, SVN ease of use is unmatched. My first year of the newly recruited staff of Tencent, surrounded by programmers, is to SVN as a cloud with a folder. Entire sector, only a repository, a project folder, all items inside the trunk code is still the need to open new projects in Riga a trunk folder. Even SVN was mistakenly used this extent, it is still not to the entire development process to bring any big trouble, everything in perfect order. You have to learn, that is, in a small turtle in the little mouse only.
Later, the department gradually expanded, increase the document, in order to protect the document is not lost, the department set up their own operation and maintenance of a SVN server, so that all members of the non-programmers, are used SVN managing documents, a variety of requirements, design draft, all with SVN management, the switching process hardly spend any time is simply to give some non-technical colleagues trained a little, everything is smooth exceptions. Let V., 60 non-technical people, all of a sudden spend SVN, which shows the simplicity of it.
Functional stability. From the past seven years (in this case 2015) development experience point of view, I have not encountered any R & D management model SVN can not handle. Especially in China, manufactured by R & D team management scenarios. SVN itself proposed the development process model, it has been enough enough enough, trunk code for trunk, branches for feature development, tag for publishing snapshots, everything smooth and natural.
My team, after years of exploration and running, has formed a very smooth smooth development process. There is a new task, and open branches, the first thing in the morning every day, changing the trunk synchronization (sync trunk), the task is completed, branch testing, regression testing is completed after the trunk (reintegration), after completion of integration testing, test by playing tag, then internal self-developed on-line system, tag the whole amount of code release, the last person in charge of the branch removed used branch. Especially with the merge tracking features appear SVN 1.5 after the conflict is even very occasional incident.
SVN been developed about 15 years, dysfunction perfect, and very stable, you are familiar with the commands and parameters, it is almost always kept you familiar with that state, there is no additional learning costs, the most valuable is, SVN has been continually updated, improving efficiency.
Git SVN relatively speaking, what are the disadvantages?
The high cost of learning. Do not tell me with his eyes open, Git is very simple to learn, ah, "is very simple to learn," This a subjective feeling, that you feel is simple, you can only represent a person's feelings, if only one person the entire team, or you team pursued elitist culture, not elite if not recruiting, all of you, you may feel that learning Git is simple. But if it is just a small entrepreneurial companies, or SMEs operating for several years, consider their own from the market to get the degree of talent, you have to consider their acceptance. Of course, companies can take the effort to train, but the time and cost of training, in itself constitutes a "cost of learning."
Poor cross-platform support. For Windows, especially in unfriendly. Note, however, Windows is still the world's most widely used operating system, I believe that most grassroots programmers still work in the Windows environment, then Git that almost willful Windows unfriendly, I do not know in the end what is the purpose. Whether GitHub do, what to do all kinds of IDE, using Git on Windows, its experience is still very indirect and inconvenient.
Oops abstract, complex structures. To make good use of Git, you must understand a few very special thing, a distributed structure, the other is a version of Git repositories principle. This is no time to understand his people, the very friendly, you almost can not intuitively to use Git, as almost always mess things up. In addition, the company's non-technical colleagues and could barely use Git work, such as our company's designers, trying to use Git to manage the design draft, and collaborate, the actual experience is very bad, they are not even the new version of the library . Git also not to mention the fact the binary file is not how friendly.
You can do very bad things. Git entire system, giving users a great degree of freedom, many operations, we know that is dangerous, but the operating system does not stop you. For example, you can push any branch to any branch, for example, you are free to delete local commit history of commit, for example, you can put people to share a branch to rebase off, you can do a lot of incredible chaos full of bad care team speed, you can get into trouble, Git itself does not provide any protection mechanisms.
Not a conclusion conclusion
I'm totally on the SVN owned pump angle, to those set forth above, I would conclude that, SVN, in some cases, is really more appropriate than Git, and I think that this conclusion is relatively fair. If the research and development of low cost, small R & D team, R & D personnel experience varies, we should fully consider the direct use SVN, which may follow the development of your team, save a lot of time.
Of course, there is a factor to be considered is the development of features and content development processes, characteristics, whether high frequency coordination? Are cross-company, cross-regional collaboration? Massive development of open source systems if the people involved? And in my experience, few companies have R & D team sorted these things take sides, so SVN naturally become more rational choice. |
|
|
|