This article was last updated on August 5, 2018, and has not been updated for more than a year. If the article content or picture resources are invalid, please leave a message for feedback, and we will deal with it in a timely manner. Thank you!
Although I have used git, I don't know much about git. So I went to search it today and learned about version management tools. Now I want to share it with you.
The birth of Git
It is said that although Linus created Linux, the growth of Linux depends on the participation of enthusiastic volunteers all over the world. So how is Linux code managed when so many people write code for Linux around the world?
In fact, before 2002, volunteers from all over the world sent source code files to Linus by diff, and Linus merged the code manually!
Although inus created Linux, its growth depends on the participation of enthusiastic volunteers all over the world. So many people write code for Linux around the world. How is Linux code managed?
You may think, why doesn't Linus put Linux code into version control system? Isn't there a free version control system such as CVS and SVN? Because Linus firmly opposes CVS and SVN, these centralized version control systems are not only slow, but must be networked to use. There are some commercial version control systems that are easier to use than CVS and SVN, but they are paid, which is inconsistent with the open source spirit of Linux.
However, with the development of time, the Linux system has been developed for 10 years. The size of the code base makes it difficult for Linus to continue to manage manually. The brothers in the community also expressed strong dissatisfaction with this way, so Linus chose a commercial version control system BitKeeper. BitMover, the owner of BitKeeper, was in a humanitarian spirit, Authorize the Linux community to use this version control system for free.
In fact, before 2002, volunteers from all over the world sent source code files to Linus by diff, and Linus merged the code manually!
You may think, why doesn't Linus put Linux code into version control system? Isn't there a free version control system such as CVS and SVN? Because Linus firmly opposes CVS and SVN, these centralized version control systems are not only slow, but must be networked to use. There are some commercial version control systems that are easier to use than CVS and SVN, but they are paid, which is inconsistent with the open source spirit of Linux.
The good situation of stability and unity was broken in 2005, because the gathering of cattle and men in the Linux community inevitably infected the Jianghu habits of some Liangshan heroes. Andrew, who developed Samba, tried to crack BitKeeper's protocol (he was not the only one who did so), but BitMover found out (the monitoring work was good!), so BitMover was angry and wanted to take back the free use right of the Linux community.
Linus can apologize to BitMover and promise to discipline the brothers strictly in the future. Well, this is impossible. The actual situation is as follows:
Linus spent two weeks writing a distributed version control system in C, which is Git! Within a month, the source code of Linux system has been managed by Git! How is cattle defined? You can experience it.
Git has quickly become the most popular distributed version control system. Especially in 2008, the GitHub website was launched. It provides free Git storage for open source projects. Numerous open source projects began to migrate to GitHub, including jQuery, PHP, Ruby, and so on.
History is so accidental. If BitMover had not threatened the Linux community in those years, we might not have a free and super easy-to-use Git now.
Of course, this is a statement or a fiction. After all, I haven't found any evidence to prove it. So I just wrote it and you just looked at it. I hope you don't take it seriously. It would be better if you could add some interest to people's understanding of Git.
Version Control Tools
Let's take a look at a picture to understand the development of version control tools:
- CVS is a C/S system. Multiple developers record file versions through a central version control system to ensure file synchronization.
- SVN is the abbreviation of Subversion. It is an open source version control system. Compared with RCS and CVS, it uses a branch management system. Its design goal is to replace CVS. Many version control services on the Internet have been migrated from CVS to Subversion. To put it simply, SVN is used for multiple people to jointly develop the same project and share resources.
- Git is an open source distributed version control system, which can effectively and quickly handle project version management from very small to very large. Git is an open source version control software developed by Linus Torvalds to help manage Linux kernel development.
- GitHub is a Open Source And private Software The project's hosting platform is named gitHub because it only supports git as the only version library format for hosting.
- So at present, Git has the highest cost performance ratio.
Differences between version control tools
| features |
CVS |
Git |
Subversion |
| Atomic submission or not |
CVS : No CVS submission is not atomic |
Git: Yes Submissions are atomic |
Subversion: Submissions are atomic |
| Whether files and directories can be moved or renamed |
CVS : No Renaming is not supported If done manually, the history may be damaged |
Git: It supports renaming, which is very practical Git can even detect file changes after renaming However, based on the special storage structure, the git can deduce the renaming of records that will not be displayed (which is easy to do in actual use) |
Subversion: Yes Support renaming |
| Smart merge after move or rename |
CVS : No Renaming is not supported, so there is no need for intelligence |
Git: Not supported For details, please refer to Git FAQ: "Git has a rename command, git mv, but this is just for convenience. The effect is no different from removing a file and adding another file." |
Subversion: not supported "Svn help me" mentioned "Note: this subcommand is equivalent to copy and delete." There may be a bug |
| File and directory copies |
CVS : No Copy not supported |
Git: No Copy not supported |
Subversion: Yes And copying is very easy (O (1)) Include branch generation |
| Backup of remote storage warehouse |
CVS : Indirect CVSup written by John Polstra can be used |
Git: Yes Is the internal feature of git |
Subversion: Indirect You can use Chia liang Kao's SVN:: Mirror plug-in (like a Taiwanese) or Shlomi Fish's SVN Pusher tool |
| Transfer changes to parent warehouse |
CVS : No |
Git: Yes (this feature is often used in Linux kernel development) |
Subversion: Yes, use either Chia Ling Kao's SVN:: Mirror script or Shlomi Fish's svn push tool |
| Warehouse permission |
CVS : Very limited "Pre commit hook scripts" can be used to implement various permission control systems |
Git: Please see the contrib/books/update paranoid Look at the code of path_rules similar to svnperms |
Subversion: Yes The WebDAV based module based on HTTP permissions can support directory level warehouses |
| Changeset |
CVS : No Changes are document based |
Git: Yes Yes, it is easy to create them |
Subversion: partially supported A changeset will be implicitly created for one submission |
| Track linear file history |
CVS : Yes cvs annotate |
Git: Yes (git blame) |
Subversion: Yes (svn blame) |
| It can only be used in a single directory of the warehouse |
CVS : Yes |
Git: No However, the number of submissions can be limited. Please refer to "Repository Permissions" |
Subversion: Yes |
| Track uncommitted changes |
CVS : Yes Through cvs diff |
Git: Yes In addition, branches are very intelligent in git, and can be used as another repository of uncommitted code in some workflow See the "git stash" command |
Subversion: Yes Use svn diff |
| Submissions based on a single file |
CVS : No The information submitted is based on a single change |
Git: Yes Submit information based on changeset |
Subversion: not No such feature |
| file |
CVS : Very good There are many online tutorials and resources, online books The command line client also supports an online help system |
Git: Good Short help is more concise and difficult to understand Man pages are weighty, but easy to misunderstand There are many tutorials |
Subversion: Very good There are some online books and some online tutorials and resources And books are written in docbook/xml, so they can be easily transformed into other formats The command line also provides an online help system |
| Whether the configuration is easy |
CVS : Good It's a de facto standard Based on each system and easy to configure |
Git: OK Binary is available on existing platforms Requires C compiler and Perl Cygwin is required on Windows And some Unix features |
Subversion: Subversion server needs to be installed in the Apache 2 module (if someone wants HTTP as the underlying protocol) or use its own server The client needs Subversion logic and WebDAV library (for HTTP) Installing components is straightforward, but requires some additional work (assuming that subversion does not have binary packages available on some platforms) |
| Command Set |
CVS : A simple command set containing three frequently used commands (cvs commit, cvs update, and cvs checkout) and others |
Git: The command set is rich and incompatible with CVS |
Subversion: CVS like command set, which can be easily used by CVS users |
| Network support |
CVS : Good CVS uses different protocols in different situations The protocol can be implemented through the encrypted tunnel of the ssh link |
Git: Very good The local git protocol can be used, but it can also be used on rsync, ssh, HTTP and HTTPS |
Subversion: Very good Subversion server supports WebDAV+DeltaV (based on HTTP or HTTPS) as the underlying protocol, or its own protocol can also be used in the ssh link channel |
| Portability |
CVS : Good The client can be used on UNIX, Windows and Mac OS The server can be used on UNIX and Windows with UNIX simulation layer |
Git: The client runs on most UNIX systems, but there is no MS Windows local program Cygwin based systems also seem to work |
Subversion: Very good Both client and server can run on UNIX, Windows and Mac OS X |
| Web interface |
CVS : Yes CVS Web, ViewVC, Chora and wwCVS |
Git: Yes Gitwib included in the release package |
Subversion: Yes ViewVC, SVN ::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac, SVN ::RaWeb::Light, SVN Browser, Inquiry and perl_svn. In addition, Subversion's Apache service also provides a basic web interface |
| graphical user interface |
CVS : Very good There are many graphical interfaces available: WinCVS, Cervisia (for KDE), TortoiseCVS (Windows browser plug-in) |
Git: Gitk is included in the distribution Qqit and Git gui tools can also be used |
Subversion: Very good There are many GUIs available: RapidSVN (cross platform), TortoiseSVN (Windows browser plug-in), Jsvn (java), etc Most are still under development |
The form is transferred from the Internet and deleted. The introduction to this picture is quite detailed, but it seems very messy. Let me explain it easily.
Differences between Git and CVS:
- Branching is faster and easier.
- Support offline work; Local submission can be submitted to the server later.
- Git submission is atomic and project wide, unlike in CVS, it is for each file.
- Each working tree in Git contains a repository with a complete project history.
Differences between Git and SVN
one Git is distributed, SVN is not
But Git is not the first or only distributed version control system at present. There are also some systems such as Bitkeeper , Mercurial It also runs in the distributed mode, but Git does better in this respect and has more powerful features.
two Git stores content as metadata, while SVN stores content as file
Because the. git directory is a clone version of the version library on your machine. It has all the things on the central version library, such as labels, branches, version records, etc Comparing the size of the git directory with that of. svn, you will find that there is a big gap between them.
three Git does not have a global version number, while SVN does
So far, this is the biggest feature that Git lacks compared with SVN.
four Version library: SVN can only have one specified central version library
When there is a problem with the central repository, all the working members will be paralyzed together until the repository is repaired or a new repository is set up. Git can have unlimited version libraries. Or, to put it more correctly, every Git is a version library. The difference is whether they have an active directory (Git Working Tree). If something happens to the major version library (for example, the version library placed in GitHub), the staff members can still submit it in their local repository and wait for the recovery of the major version library. Work members can also submit to other version libraries!
five Branch is in SVN, and a branch is a complete directory
And this directory has complete actual files. If a staff member wants to open a new branch, it will have a great impact! For Git, each worker can open unlimited branches in his/her local version library.
six Dependence on network, SVN>Git
SVN cannot commit to the central repository when there is no network, but Git can do anything without relying on the network and has better support for branching and merging
In conclusion, Git has the highest cost performance.
Finally, tips+summary
Milestone=stable version number Milestone means: a stable version, officially submitted and released. Zip download is available
Operation steps:
- Go to the project homepage on github website
- Horizontal bar button (Commits, branches, release, etc.), find the release button
- Find button: Create a new release Click to enter the next page
- Fill in the version number and description information
- After that, click publish release to release the software
- This completes the milestone establishment and automatically generates a zip download link
Small Tips
- Diff your own code before submitting each time to avoid submitting wrong code
- Organize your work area before closing the project
- Parallel projects, using branch development
- When encountering conflicts, understand the causes of conflicts and never discard other people's code at will
- After the product is released, remember to tag, so that you can pull branches to fix bugs in the future
Part of the content was transferred from the Internet, which was sorted out and published by myself.
Thank you for reading
