Why compare GIT-GIT with other SCM tools

Document directory

• Subversion Workflow
• Integrate Management Staff Workflow
• Workflow of the Commander and Deputy
• Mercurial help
• Git help

Why git is better than X (Hg bzr SVN perforce) Original address: http://zh-tw.whygitisbetterthanx.com/

I will do this website because I have spent a lot of time preparing for gitsters, for fanboyism and badwagonism) koolaid-thirst is also available. The reason for this is why everyone should convert from X to git, and why you should do the same. Click here for any reason. Git is derived from all other SCM, and is most characteristic of git. I am afraid it is not the Branch Model of git. It is totally different from other models I have compared here. Most of the best branching methods they have pushed are just getting the repository into a new category. Git does not do this. Git allows you to have multiple local branches, which may be completely independent, in addition, the establishment, combination, and division of these developed branches only need to wait several seconds. This means you can do this:

• Create a branch to create a new sub-node, commit (COMMIT) a few times, and then switch back to your original branch, add a patch and then switch it back to the Branch used in the production environment to merge it.
• One branch is only used to release the version to be released, and the other is used to combine the development part for release. The other branch is used for daily development.
• Create new branches for each new feature that you are actually working on, and then you can switch between them horizontally, finally, remove the branch of each new function that has been merged back to the master node.
• Create a new branch for implementation. As a result, the Branch will be deleted if it does not work, no one even knows it already exists (at the same time, you can take out other branches)

The most important thing is that when you are about to publish the data to a client, youNoRelease all your branches. You can share only one of your branches, not all. This allows you to write new ideas without worrying about how, when, or sharing with others. You are on another SystemYesFind the method to do the same thing, but it will be more difficult and easy to quit. Git makes this process very simple, and when developers start learning, it often changes the way they work. SVN perforce is basically the same for all distributed SCM, but in my experience git is better at developing this feature. In addition to 'fetch', 'pull ', and 'push',

In addition, there is almost no other command that requires anything other than the hard disk.

This not only makes most of the operations much faster than you may have been doing, but also allows you to continue working. It seems that there may not be any such thing, but I always think about how often I work. When you are on a plane or on a train, you can also establish a history of branch, joint operation, and submission of work cases. How productive is this. Even if mercurial is used, some common commands such as 'incoming' and 'outgoing' also need to be used on the slave server, with git, you can access all the resources on the 'fetch' Server prior to zookeeper, and then compare, merge, and view zookeeper, these resources are not in your current branch on the server. This means that you can easily have copies of not only your own branches, other branches of people who work with you can exist in your git repository without hitting your original stuff. Git is fast. Everyone said so, even those loyal supporters of other systems will give git this example. With git, all the operations run much faster on the local side than SVN and perforce. Both of them require a network to complete most of the operations. However, git is much faster than other local DSCM operations. Part of the reason may be that it is built for use on the Linux core, which means that it must be efficient at the beginning of the day. In addition, because git uses a C-producer, it is less likely to use other high-definition scripts during the runtime. Another reason why git is so fast is that its main developers set this item as the goal. Below are some data records I have written. I used Django's original collections to compile three different SCM: git, mercurial, and bazaar. I also used SVN to prepare some similar targets, but believe me, it is more slow-basically the bazaar data plus the extension of the network... The final result of zookeeper is all operations, except for the new case, git is the fastest. (There are also a large number of commit operations, Hg is basically as fast, but the amount of commit for my zookeeper is so large, you are unlikely to have the same amount-normal commit operations are much faster in git .)

	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

The number of cold and hot branches is my first and second branch, one branch-the number of the second branch used disk cache. Note that 'add' operations are much slower, but they are newly added in a large number of cases-over 2000. For most people, new operations on any system only take one second. Other operations (except a large number of submissions...) should be similar to the operations you use on a daily basis. These numbers won't repeat, as long as you clone a piece of Django plan using different systems and then compile these commands.

• 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

Git really knows how to save disk space. Your git project will only (generally speaking) be a little bigger than a SVN checkout-some situations are even smaller. many things can be removed from the svn project ). The following data points are obtained by using the same historical checkpoints in different systems.

	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 bzr number is obtained after I click "bzr pack". I originally thought it would make it smaller, but the result would make it much larger ....Hg bzr SVN perforce is different from other systems. Git has something that identifies it as "staging area" or "Index. This is a middleware that allows you to set what you want to submit before submission. Staging Area is the coolest place, so that git can easily start other tools, that is, you can easily end up with a piece of work and stage some of your cases, then, you do not need to submit all the modified records, or you must list all the records you want to submit in the Command column. This allows you to only part of the modified stages. Imagine that one day you made two irrelevant changes to a case, and then you forgot to submit one. Now you can only stage the part you want to submit now, and then change the rest of the stage to the next commit. This function can greatly adapt to any changes you make to the case. Of course, git can also simplify these features. If you don't want to control so much-you just need to add '-a' to your commit command, you can commit all the modifications to the staging area at a time. SVN perforce any distributed SCM, of course including git, one of the coolest features is that it is distributed. This indicates that you are not only "checkout" the latest version of the original shard, but "clone" the entire shard. This means that even if you use a centralized workflow, each user has a copy of the master server, each copy can be pushed up to replace the master server on the master server or during the hour. Basically, using git won't cause the loss of a single point, unless it is the only point. In addition, this will not make the operation too slow. On average, one SVN checkout is only a little faster than other DSCM. Of course, git is the fastest in my recent DSCM.

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

One of the most impressive git tasks of SVN perforce is because of its distributed design and hypervisor branch systems, you can easily implement any workflow you want. A Subversion workflow is a common Git workflow, which is used by people who have accessed the centralized management system, is a centralized management workflow. If someone posts a change after your last fetch, git won't allow you to follow the change, so use this centralized model, all developers can also work well if they are distributed to the same server.

Another common Git workflow is an integrated Manager-a person who submits a batch of jobs to 'blessed, then, other developers will release the changes from this website to their own website, and then ask the integrator pull to modify them. This is a common development model in the open source community or on the GitHub website.

The work flow of the Commander and Deputy Director for some more complex cases, you can let your developers use the development process similar to the Linux core, different sub-systems (deputies) in their respective attack cases were developed, and then all changes related to the sub-systems were merged. Another Consortium (the commander) can only change from the pull on his deputy hand, and then publish it to 'blessed 'to allow everyone to roll back.

Once, git is completely intrusive, so you can mix and use it to merge your workflow. Hg bzr SVN perforce. Let me say this.PossibleA little biased, because I work for GitHub, but I still have to submit this part because many people say they chose git for GitHub. GitHub is one of the reasons why many people use git, because it is more like a social network and is a simple hosting server. People find other developers or case studies, which are similar to what they want to do, so they can easily branch the case and try again later, build a very active community centered on git and various cases. There are other similar services on the Internet, and git and other SCM services, but few are directed by users or social networks, no other service has similar use groups. This GitHub social networking site is used by its experts, combined with the above features, git and GitHub can be used to quickly develop and release the original release case. This community is not owned by other SCM. Perforce is not true-Git was not a real SCM in the early days, and it is like a group of tools that allow you to use distributed endpoints to build version-controlled protocol systems. But now, git's command set and learning curve have become similar to other SCM, or even better. The difference between mercurial and git's parameter settings 'help' is shown here. I highlighted the commands with the same (or similar) system. (If you add 'Hg help' to Hg, you will get a ticket containing 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 put under the same path on the slave line, which is often confusing to some people. Git still recognizes these commands, but there is only one 'git 'For the commands that are running the same path. If you find that you are better than mongomercurial and git, git and mercurial have almost the same instruction set and description system-from the perspective of the beginner's UI, there is almost no difference between them. Now it has been said that mercurial or bzr is easier to learn than git.