Why do people always say that linus hates SVN? It’s because he has to be connected to the Internet to use it, so he doesn’t need it. It’s like GIT can be used without the Internet. How can he mention the remote server without the Internet?
It is true that you will eventually need to be connected to the Internet to merge with other people's code.
But what that sentence means is that Git不需要总是 version management can be carried out through the Internet because it has a local warehouse. You can perform a lot of version management-related work locally without the need for an Internet connection, such as creating branches, submitting, rolling back code, etc.
For regular small-scale teams that always sit in an office and work using a LAN, they may not be able to fully realize that Git的好处，换句话说，对于一般的情况，SVN is already competent enough.
However, for "unconventional" teams where project members may be distributed anywhere, Gitmay be better.
I originally wanted to reply to you directly in the comments, but there is a lot of content, so I’ll add it here.
It can be seen from your doubts that you may have created a version without fully understanding 版本管理的本质。版本管理中的版本并不单单指软件最终的发行版，0.8、1.0、2.0这些只不过是面向最终用户的版本而已。版本管理中的版本是泛指那些在开发过程中程序的中间状态。这些版本有些需要合并到公共版本里去，有些可能最终就丢弃了，甚至从此就演化出了另一个项目也不一定。可以说，你每按下一次Ctrl+S.
In order to better explain the essence of version management, let me give a few more examples. These are things we often encounter. Let’s experience them.
Scenario 1
I have an idea about this function that is currently being developed, but I don’t know if it is feasible, so I plan to try it first. I don’t want to change it directly in the workspace (the workspace in SVN often directly corresponds to the main version), because this will Contaminate the existing code. If you later find that this method is not feasible, you will delete all related code, but you may not remember what needs to be deleted at that time.
It can also be implemented in a centralized version control tool like SVN (so many functions and features are just more convenient), that is, using branches, but in this way I still have to deal with the server frequently to create branches and delete branches. , merge branches, commit code to branches, etc. But in fact, I can do all these things locally (again, this may not be a big problem in the local area network). I create a branch in the local warehouse, code and test it. If it works, merge it into the main version. If it doesn’t work, I can merge it into the main version. It doesn't matter if it works.
Scenario 2
I found that a program in a certain submission was incorrect (for example, a certain function was only half changed and could not be used, and even the compilation failed). At this time, I could only quickly roll back the server, but it may have been Too late, someone else may have already checked your code, and you have to send a group email explaining the problem (or just yell at it if everyone is together).
But in Git, since it is submitted locally first, it gives the submission behavior a buffer time, allowing me to undo it in time without affecting other people (if you find it too late, there is nothing you can do).
Scenario 3
There is also the "local" rollback capability. A function is relatively complex and takes several days to develop, but I don't want to submit it to the server before it is developed, because I don't want to affect other people due to compilation or running errors. So I wanted to change everything locally and then submit it, but in this way, these programs are not guaranteed. If I want to roll back, compare with the previous code, etc., it is difficult to do so.
Some tools also provide the local history function, but it is not easy to use. Local history cannot be compared with version. Every time you Ctrl+S may or may not form a local history. In other words, local history doesn't preserve records the way you want it to. It is very likely that a historical record you need urgently is not saved, and you can only look at it and sigh (this problem is indeed not that rare)
Summary
Having said so much, these are just some side examples between centralized and distributed. In fact, this issue is just like object-oriented and process-oriented. There is no absolute good or bad. It may be better to use object-oriented for complex programs, but process-oriented is not without merit. The choice of tools depends on the team and individual decisions
The questioner is too focused on the advantage of git, which can be used offline by a single person. Git is a distributed structure, which means that its data integrity is destined to be much better than svn. The questioner must have never encountered svn warehouse file corruption. (It's easy to happen! For example, power outage), all historical commits exported with svndump also have inexplicable problems.
In addition, the scale of the projects that the subject may be exposed to is still relatively small, and they basically still use git like svn, so they focus on conflicts and merge issues. What I want to say is that of course conflicts must be resolved, but the fundamental purpose of version management is not only to merge code and resolve conflicts. The most important thing may be to enable everyone to work without affecting others and releases
Our company's use of git follows the practice of git flow. Master is used for trunk releases (web projects, so it is a stable version that is constantly iterated), and develop is used for testing. Everyone who starts developing a new requirement creates a feature from the develop branch. Branch, merge it back to develop after finishing the work, make a release and test it in the test environment. If everything is OK, then merge the release into master and wait for the next release The purpose of saying this is to mention it in your own feature branch When working on the development branch, you don’t actually need to care too much about what happens on the develop branch (there is no need to interact with the central server), but the need for version management still exists, and you need to complete a feature many times. It can be solved only by submitting it If it is a patch that needs to be repaired urgently, create a hotfix branch from the master, and merge it back to the master (and develop) after the modification
Through these means, it is mainly solved
The development of a new feature will not affect the development of other new features (each feature is an independent branch)
The upgrade of the new version (on develop) and the bug fixing of the old version (master) will not conflict or affect each other. The bugs of the old version of master will not have to wait until someone is developing a new version. The new version can only be released once it is developed
I can say that although SVN is capable of this, its branch function is essentially another directory in the warehouse. Merging or not is actually saved through an attribute, which is definitely not easy to use
Added:
You can check out http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E4%B8%BA%E9% A1%B9%E7%9B%AE%E4%BD%9C%E8%B4%A1%E7%8C%AE introduced many git best practices
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
It is true that you will eventually need to be connected to the Internet to merge with other people's code.
But what that sentence means is that
Git不需要总是version management can be carried out through the Internet because it has a local warehouse. You can perform a lot of version management-related work locally without the need for an Internet connection, such as creating branches, submitting, rolling back code, etc.For regular small-scale teams that always sit in an office and work using a LAN, they may not be able to fully realize that
Git的好处，换句话说，对于一般的情况，SVNis already competent enough.However, for "unconventional" teams where project members may be distributed anywhere,
Gitmay be better.I originally wanted to reply to you directly in the comments, but there is a lot of content, so I’ll add it here.
It can be seen from your doubts that you may have created a version without fully understanding
版本管理的本质。版本管理中的版本并不单单指软件最终的发行版，0.8、1.0、2.0这些只不过是面向最终用户的版本而已。版本管理中的版本是泛指那些在开发过程中程序的中间状态。这些版本有些需要合并到公共版本里去，有些可能最终就丢弃了，甚至从此就演化出了另一个项目也不一定。可以说，你每按下一次Ctrl+S.In order to better explain the essence of version management, let me give a few more examples. These are things we often encounter. Let’s experience them.
Scenario 1
I have an idea about this function that is currently being developed, but I don’t know if it is feasible, so I plan to try it first. I don’t want to change it directly in the workspace (the workspace in SVN often directly corresponds to the main version), because this will Contaminate the existing code. If you later find that this method is not feasible, you will delete all related code, but you may not remember what needs to be deleted at that time.
It can also be implemented in a centralized version control tool like SVN (so many functions and features are just more convenient), that is, using branches, but in this way I still have to deal with the server frequently to create branches and delete branches. , merge branches, commit code to branches, etc. But in fact, I can do all these things locally (again, this may not be a big problem in the local area network). I create a branch in the local warehouse, code and test it. If it works, merge it into the main version. If it doesn’t work, I can merge it into the main version. It doesn't matter if it works.
Scenario 2
I found that a program in a certain submission was incorrect (for example, a certain function was only half changed and could not be used, and even the compilation failed). At this time, I could only quickly roll back the server, but it may have been Too late, someone else may have already checked your code, and you have to send a group email explaining the problem (or just yell at it if everyone is together).
But in Git, since it is submitted locally first, it gives the submission behavior a buffer time, allowing me to undo it in time without affecting other people (if you find it too late, there is nothing you can do).
Scenario 3
There is also the "local" rollback capability. A function is relatively complex and takes several days to develop, but I don't want to submit it to the server before it is developed, because I don't want to affect other people due to compilation or running errors. So I wanted to change everything locally and then submit it, but in this way, these programs are not guaranteed. If I want to roll back, compare with the previous code, etc., it is difficult to do so.
Some tools also provide the local history function, but it is not easy to use. Local history cannot be compared with version. Every time you
Ctrl+Smay or may not form a local history. In other words, local history doesn't preserve records the way you want it to. It is very likely that a historical record you need urgently is not saved, and you can only look at it and sigh (this problem is indeed not that rare)Summary
Having said so much, these are just some side examples between centralized and distributed. In fact, this issue is just like object-oriented and process-oriented. There is no absolute good or bad. It may be better to use object-oriented for complex programs, but process-oriented is not without merit. The choice of tools depends on the team and individual decisions
The questioner is too focused on the advantage of git, which can be used offline by a single person. Git is a distributed structure, which means that its data integrity is destined to be much better than svn. The questioner must have never encountered svn warehouse file corruption. (It's easy to happen! For example, power outage), all historical commits exported with svndump also have inexplicable problems.
In addition, the scale of the projects that the subject may be exposed to is still relatively small, and they basically still use git like svn, so they focus on conflicts and merge issues. What I want to say is that of course conflicts must be resolved, but the fundamental purpose of version management is not only to merge code and resolve conflicts. The most important thing may be to enable everyone to work without affecting others and releases
Our company's use of git follows the practice of git flow. Master is used for trunk releases (web projects, so it is a stable version that is constantly iterated), and develop is used for testing. Everyone who starts developing a new requirement creates a feature from the develop branch. Branch, merge it back to develop after finishing the work, make a release and test it in the test environment. If everything is OK, then merge the release into master and wait for the next release
The purpose of saying this is to mention it in your own feature branch When working on the development branch, you don’t actually need to care too much about what happens on the develop branch (there is no need to interact with the central server), but the need for version management still exists, and you need to complete a feature many times. It can be solved only by submitting it
If it is a patch that needs to be repaired urgently, create a hotfix branch from the master, and merge it back to the master (and develop) after the modification
Through these means, it is mainly solved
The development of a new feature will not affect the development of other new features (each feature is an independent branch)
The upgrade of the new version (on develop) and the bug fixing of the old version (master) will not conflict or affect each other. The bugs of the old version of master will not have to wait until someone is developing a new version. The new version can only be released once it is developed
I can say that although SVN is capable of this, its branch function is essentially another directory in the warehouse. Merging or not is actually saved through an attribute, which is definitely not easy to use
Added:
You can check out http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E4%B8%BA%E9% A1%B9%E7%9B%AE%E4%BD%9C%E8%B4%A1%E7%8C%AE introduced many git best practices
This is the difference between centralized and distributed.