Shulou(Shulou.com)06/02 Report--

This article mainly introduces the relevant knowledge of "what are the relevant knowledge points of Git". The editor shows you the operation process through actual cases, the operation method is simple and fast, and it is practical. I hope this article "what are the relevant knowledge points of Git" can help you solve the problem.

Branch and merge

The advantage of Git over other version control systems lies in its advanced branch model.

Git allows and encourages you to use multiple completely independent branches locally. Almost all of these branches can be created, merged, and deleted in a matter of seconds.

This means that you can easily do the following:

Painless context switching create branches experiment with an idea, submit a few times, switch back to the state of your original branch, apply a change patch, switch back to the state you were experimenting with, and merge the patch you just applied.

Role-based code branch you may have a branch that contains only those that exist only in the production environment, and a separate branch to merge the test environment code, and several smaller branches for day-to-day development work.

The feature-based workflow creates new branches for each new feature, and you can easily and seamlessly switch between these branches, and when these feature changes are complete, you can merge them into the main branch and delete the feature branch.

Any experiment to create a branch dedicated to the experiment, when the test is not ideal, just delete it, give up the previous test content. No one else will be aware of the experiment at this time (even during this time you can push other unrelated branches)

Especially when you push to a remote warehouse, you don't have to push all branches, you can choose to push only a few branches that you want to share, and of course you can push all branches if you want. This tends to exempt developers from publishing their own immature pilot plans when experimenting with many new ideas.

Of course, there are some other systems that can partially achieve the above functions and advantages, but the specific implementation will become difficult and error-prone. Git makes these tasks incredibly easy, changing the way developers work as they learn to use them.

Lightweight and fast

Git is fast. Basically all of Git's operations are performed locally, which is a huge speed advantage for centralized systems that must communicate with the server.

Git was originally designed to manage the source code of Linux Kernel, which means that he has had the efficient advantage of handling large warehouses since he was born. Git is written in C, which reduces the performance loss caused by Runtime, which uses a higher-level programming language. The first two important design goals of Git are performance and speed.

Pressure testing

Let's take a look at the performance test metrics for general operations compared to SVN, a general-purpose centralized storage version control system, much like CVS and Perforce. The indicator here is that the smaller the value, the faster the speed.

For testing, we created two new Large-type computing server instances on the same availability zone of Amazon's AWS. Git and SVN are installed on each computing instance. We copied the Ruby source code repository to the computing server examples of Git and SVN, both of which perform common operations.

In some cases, the command and the actual effect of the two do not exactly correspond. Here, we choose the matching of similar effects in the common operations. For example, for the "submit" test, we also calculate the time of Push in Git. In most cases, however, you may not actually push it to the server immediately after submission, which is an integral operation on SVN.

All the time units in the table below are seconds.

Operation description GitSVN performance multiple submission (A) Add, commit and push 113modified files (2164mm, 2259 -) 0.642.604x submit picture (B) Add, commit and push 1000 1k images1.5324.7016x compared to the current change Diff 187changed files (1664cycles, 4859 -) against last commit0.251.094x compared to the most recent change Diff against 4 commits back (269changed/3609+) 6898 -) 0.253.9916x comparison label Diff two tags against each other (v1.9.1.0/v1.9.3.0) 1.1783.5771x submission history (50) Log of the last 50 commits (19k of output) 0.010.3831x submission history (all) Log of all commits (26056 commits-9.4m of output) 0.52169.20325x submission history (file) Log of the history of a single file (array.c-483revs) 0.6082 .84138x Update Pull of Commit A scenario (113 files changed 2164mm, 2259 -) 0.902.823xBlameLine annotation of a single file (array.c) 1.913.041x

You need to note that this is already a SVN scenario-a server without any load, and the network bandwidth between the client and the server reaches 80MB/s. All the above indicators are affected by network fluctuations, or in a worse network environment, the performance of SVN is even worse, while almost all of the indicators on the Git side are not affected.

It is clear that in the operation of these most commonly used version control tools, even in the ideal environment for SVN, * * Git is significantly ahead in many ways.

One place where Git is slower than SVN is to initialize the clone repository. In this case, Git is downloading the entire warehouse history rather than just the * * version of the code. As the table above shows, the impact of performing an operation only once is not significant.

Operation description Git (Shallow Clone) GitSVNCloneGit Clone and shallow clone (shallow clone) vs SVN checkout21.0107.514.0 size (M) the file size of the client after clone/checkout (in M) 181.0132.0

Another interesting point is that there is little difference in file size between Git and SVN after Clone or Checkout to local, which, for Git, contains the entire project history. This also shows the super efficiency of Git in file compression and storage.

Distributed system

One of the best features of Git is distribution. This means that you want to clone the entire repository instead of just the header version of the checkout branch.

Multiple backup

Git often has multiple backups in daily usage scenarios. This means that even if you are using a centrally stored workflow, each user has a full backup locally on the server. Any version here can be pushed back to the server to save the loss when the server-side data is corrupted or lost. In fact, as long as you have more than one copy,Git in your warehouse, there will be no single point of problem.

Arbitrary workflow

Because Git has distributed features and excellent branch systems, you can easily implement a large number of workflow models on this basis.

Subversion (SVN) style workflow

Centralized storage workflows are common, especially for those who switch from traditional centralized code version management systems to Git. Git can also provide this form of work: every time Push must be updated to the * * version of the remote repository. So it's still okay for people to use centralized storage workflows to Push code on the same server as before.

Integrate manager workflow

Another common Git workflow is the integration workflow. The main warehouse has a single developer maintainer. Several other developers clone from this warehouse and then push it to their own fully independent warehouse, and * request maintainers to Pull their changes in their respective warehouses from the main warehouse. This form tends to collaborate as an open source on GitHub.

Maintainer and leader workflow

For more complex projects, development workflows such as the Linux kernel are also effective. In this model, the person in charge (lieutenants) is responsible for specific subsystems of the entire project, and they merge all changes associated with that subsystem. Another maintainer (dictator, literally: dictator) can only obtain changes from the person in charge of his jurisdiction and push those changes to the main warehouse. Then everyone gets updates from this warehouse.

Data check

Git's data model ensures the consistency of every byte and every bit in the project. A checksum is used to calculate the summary for each file submitted, and this summary value is also used when checked out. There is no possibility that what you get from the warehouse is any different from what you store.

It is not possible to change any document, date, submission description or any other data in the Git warehouse without changing the ID (checksum). This means that if you have a commit ID, not only can you be sure that this version of the code is exactly the same as when it was submitted, but that there is no change in the history of the previous version.

Most centrally stored version control systems do not provide such verification integration by default.

Temporary storage area

Unlike other systems, Git has a concept called "staging area" or "index". This is a temporary area that can be used to format and review changes before committing for execution.

One of the advantages of Git over other systems is that we can quickly temporarily save some changed files, submit only partially changed files in the working directory, or part of the contents of file changes, and list the changed files on the command line at the time of submission.

The temporary storage area allows you to temporarily save only some of the file changes, and the days of making two logically unrelated changes to the file are gone before you realize you forgot to submit one of the files. Now you can only temporarily save the files that you currently submit that need to be changed, and other changes will be temporarily saved the next time you submit them. This feature can be extended to any changes made to the file.

Of course, Git also allows you to ignore the temporary area process, and you can easily add the'- a 'option to the commit command to submit all changes directly. Git will automatically save it to the temporary storage area for you before performing the submission.

This is the end of the content about "what are the relevant knowledge points of Git". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.