Why git is better than X

Why git is better than X

Hg Bzr SVN Perforce

Recently I spent a lot of time defending gitsters against fanboyism, bandwagonism, and koolaid-thirst accusations. Therefore, I have built this website to explain why we need to switch from X to git, and why you should do the same. Click any reason to expand to view details. Expand All |
Fold all Hg bzr
SVN perforce cheap local branch
Git stands out from almost all SCM and has the most attractive characteristics. I'm afraid it is not its branch model. It is totally different from all other models I used here for comparison. The best branch method recommended by those models is to copy the Library (repository) to a new directory. Git does not. Git allows you to have multiple completely independent local branches. It takes only a few seconds to create, merge, and delete these branches. This means you can do this:

• Create a new branch and try a new idea. Submit it several times, switch back to the original branch, apply a patch, switch to the new branch in the experiment, and merge it.
• One branch is used to store the version to be released, the other test branch is used to merge development work, and several other small branches are used to store daily development work.
• Create corresponding branches for each new feature in development, so that you can seamlessly switch between these branches, and delete the corresponding branches after a feature is developed and merged into the main branch.
• Create a branch to do the experiment. If it doesn't work, delete the branch directly. Give up the branch and others don't even know it exists (even if you have pushed other branches in this period ).

It is important that when you push data to a remote databaseNoPush all branches. You can share only one branch, not all. This will encourage everyone to try new ideas without worrying about how and when to merge or share with others. Using other systems, you can alsoYesFind some methods to do the same thing, but it will be much more difficult and prone to errors. Git makes this process extremely simple, and when most developers learn git, they also change their way of working. SVN perforce: All content is stored locally.
Although all distributed SCM Features This, git is better developed based on my experience. In addition to 'fetch', 'pull ', and 'push', you rarely use commands that need to deal with things other than your hard disk. This not only makes most operations much faster than you are used to, but also allows you to work offline. This sounds bad, but I am often surprised that I need to do so much work offline. When you can build branches, merge, submit, and browse project history on airplanes or trains, your work productivity will be very high. Even if you use mercurial, Common commands such as 'incoming' and 'outgoing' need to be connected to the server. Git allows you to 'fetch' all data on the server before going offline, then compare, merge, or view historical data that does not exist in your local branch. This means that you can easily store multiple branches of yourself and other people working with you in your git repository without obfuscation. Bzr SVN
Perforce git is fast
Git is fast. Git is commented on by many loyal users in other systems. All git operations are performed locally to make it faster than SVN and perforce, because the common operations of the latter two require network connection. Git is much faster than other distributed SCM instances that allow local operations. This is partly because git was created for Linux kernel development, which means it needs to efficiently process large libraries from the very beginning. In addition, git is written in C language, which reduces the cost of collaboration with high-level languages at runtime. Another reason why git is so fast is that its main developers regard this as the design goal. I used git, mercurial, and bazaar to store the Django source code and perform some tests. Below are some test results. I also used SVN for some tests, but it would be slower for me-basically, the bazaar test results plus network latency...

Test results show that all operations except adding new files are git's fastest. (In addition, in some very large commit Operation tests, Hg is basically as fast as git, but the commit operation I tested is too large, you are unlikely to encounter that situation-Git processes normal commits much faster than other SCM)

	Git	Hg	Bzr
Init	0.024 S	0.059 s	0.600 s
Add	8.535 s	0.368 s	2.381 s
Status	0.451 s	1.946 s	14.744 s
Diff	0.543 s	2.189 s	14.248 s
Tag	0.056 s	1.201 s	1.892 s
Log	0.711 s	2.650 s	9.055 s
Commit (large)	12.480 s	12.500 s	23.002 s
Commit (small)	0.086 s	0.517 s	1.139 s
Branch (cold)	1.161 s	94.681 s	82.249 s
Branch (hot)	0.070 s	12.300 s	39.411 s

Cold and Hot are the results of the first and second branch operations on a database-the second branch uses the hard disk cache. Note that although 'add' operations on git are much slower, it is a new operation on a large number of files-more than 2000 files. For most people's daily work, adding operations on any system takes only a few minutes. Other tested operations (except for large submissions) are similar to those in routine use. These test results are not difficult to reproduce. You only need to copy a Django project from different systems to compare them.

• git clone git://github.com/brosner/django.git dj-git
• hg clone http://hg.dpaste.com/django/trunk dj-hg
• bzr branch lp:django dj-bzr
• svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn

SVN git is very small
Git is really good at saving disk space. Your git directory is generally a little bigger than a SVN checkout directory-sometimes smaller (obviously, a lot of content in the. SVN directory can be removed ). The clone of different parts extracted from the same historical record of the Django project is provided to us.

	Git	Hg	Bzr	Bzr *	SVN
Repo alone	24 m	34 m	45 m	89 m
Entire directory	43 m	53 m	64 m	108 m	61 m

* The second bar number is obtained after I run 'bzr pack '. I thought this command would make it smaller, but the result would make it much larger.
Hg bzr
SVN perforce temporary storage area
Unlike other systems, git has something that is called a temporary storage area ("staging area") or "Index. This is a temporary region used to set the submitted content before submission. The coolest saving area is also the place where git is different from other tools. After you modify some files, you can easily stage and submit them, at the same time, you do not need to submit other modified files in the working directory or list those files in the submit command. You can also modify only a part of a stage file. This will never happen again: After modifying the two logically unrelated parts of the same file, we can find that they are not submitted separately. Now you can first submit the modifications to be included in the stage, and then submit the modifications to be included in the stage next time. This feature applies to any modifications to the file. Of course, if you don't want to control so much, you can easily ignore these features-simply add '-a' to the submit command ', you can add all modified files to the temporary storage area. SVN perforce distributed
One of the best features of all distributed SCM, including git, is distributed. This means that you are not the latest version of the source code of "checkout", but the whole code library of "clone. This means that even if a centralized central workflow is used, each user has a backup copy of the master server, and each copy can be replaced when the master server is down or damaged. If you use git, there is no single point of failure, unless there is only one point. At the same time, this will not make the operation too slow. On average, SVN checkout is faster than any distributed SCM. Git is the fastest in Distributed scm I have tested.

Git 1 m 59 s Hg 2 M 24 s Bzr 5 M 11 S SVN 1 m 4S

SVN perforce applies to any Workflow
One of the amazing features of git is that it can easily apply any desired workflow due to its inherent distributed features and powerful branch systems. Subversion-based centralized workflow is a common workflow, especially for those who migrate from a centralized system. If someone else has performed the push operation after the last fetch, git will not allow you to push directly; therefore, the centralized model that all developers push to the same server can work well.

Another common workflow is the integration administrator who submits data to the 'blessed 'database. Other developers copy the database and push it to their own database, then the integration administrator pull is requested for their modifications. This is a common development mode in open source projects or GitHub libraries.

For larger projects, you can allow developers to use workflows similar to those developed in Linux kernel. Each sub-system has a dedicated person (sub-Officer) to merge modifications related to the sub-system. Another Consortium (Commander) only uses pull from the consortium, then pushes it to the 'blessed 'database, and all others copy it from the 'blessed' database.

Once again, it is very flexible for the workflow git. You can mix and select any suitable workflow. Hg bzr
SVN perforce GitHub
I work on GitHub myself, so thisPossibleIt seems a bit biased, but I have joined this part because many people say that GitHub has chosen git. GitHub is why many people use git. It is more like a social network than a simple website hosting. People find other developers or projects related to what they are doing, and then easily fork and contribute, this forms an active community centered on git and various projects. There are also many other services for git and other SCM, but few are user-oriented or social-oriented, and none are based on user groups. GitHub's social nature is a killer feature. The above features make git and GitHub the best combination for quick development of open-source projects. Any other SCM does not provide such a community. Perforce easy to learn
Originally, this was not the case-the early git was not a true SCM, but more like a set of tools that allow you to implement version control in a distributed manner. But now the GIT command set and learning curve are similar to other SCM, or even better than others. It is difficult to prove this without any targeted research. Here I will only demonstrate the differences between the default help menu in mercurial and git commands. The same (or similar) commands in the two systems are highlighted. (If you enter 'Hg help' IN Hg, you will get a list of more than 40 commands .)

Mercurial help add add the specified files ...annotate show changeset informati...clone make a copy of an existi...commit commit the specified fil...diff diff repository (or sele...export dump the header and diff...init create a new repository ...log show revision history of...merge merge working directory ...parents show the parents of the ...pull pull changes from the sp...push push changes to the spec...remove remove the specified fil...serve export the repository vi...status show changed files in th...update update working directory

Git help add Add file contents to the indexbisect Find the change that introduce...branch List, create, or delete branchescheckout Checkout a branch or paths to ...clone Clone a repository into a new ...commit Record changes to the repositorydiff Show changes between commits, ...fetch Download objects and refs from...grep Print lines matching a patterninit Create an empty git repositorylog Show commit logsmerge Join two or more development h...mv Move or rename a file, a direc...pull Fetch from and merge with anot...push Update remote refs along with ...rebase Forward-port local commits to ...reset Reset current HEAD to the spec...rm Remove files from the working ...show Show various types of objectsstatus Show the working tree statustag Create, list, delete or verify...

Before git 1.6, all git commands were stored in the executable path, which confused users. Although git can still identify all these commands, only the 'git 'command is stored in the executable path. If you compare mercurial and git, you will find that git's command set and help system are almost the same as mercurial-there is almost no difference in the UI of beginners. It is hard to say that mercurial or bazaar is easier to learn than git.