Why do I prefer Git?

Why do I prefer Git?

Previously, I wrote an article titled why SVN is better than Git, mainly from a very simple and realistic point of view, from a perspective of selecting a full team, I analyzed why SVN is better than Git. But it is distinct between public and private. For me, I think I prefer Git.

Distributed Design

Distributed Computing is the trend and trend of this era. Why shouldn't version control be distributed? What are the advantages of distributed architecture? Many books are written, and each copy is an image of the entire version Library (is this an advantage ?), Disaster recovery is relatively easy (because everyone's image users are all versions of the database, and the number of individual clones is equivalent to the number of backups, of course, disaster recovery is easy, but what does this have to do with me? That's O & M.) decentralization? Isn't democracy necessary to write code ?), The benefits brought by these distributed systems all seem a bit itchy.

So what are the benefits I have gained from fully distributed design? I prefer to create a version library and save all the code. Any time you use Git to work, you are holding the entire version library and creating a project from 0, no exception. When you execute Git init, that is, a version library is actually available. The process is easy and impressive. If SVN is used, it will not be so pleasant at all, because it is a CS architecture, and you always have to select a Server, even if it is a local scenario, you have to install some SVN Server software, create a version library, connect to the network, and checkout. Even if everything is local, this process is not fast. Once the version library is built locally, it may be painful to migrate it in the future, because SVN itself does not provide this migration mechanism. Git is completely different. Once you need to transmit a project to a version library, you can use remote commands to easily complete the process.

This design of Git will inspire me to change all the Code Directories into version libraries, and there is no cost at all. It can ensure that the Code is not lost and the version can be recorded. Why?

Another beauty of distributed design is full offline operations, which are local operations for code submission, branch creation, branch switching, branch merging, and almost everything. Therefore, as long as a computer is in the hands, anywhere, and in any environment, I can write code happily. In the past, I thought this was not a real requirement, however, the times have evolved to the present, and I often run around with my computer, and I am more accustomed to taking my computer out of the door. Today, this is already a very frequent demand.

More powerful functions

In the past, many things were restricted under SVN. Although it reduces the probability of errors, it is fun, no control, and very rigid. After using Git, I feel a lot of powerful things, which makes me easy to understand.

One of the capabilities is the ease of branch creation and switching. In the past, SVN branches were first created as a server behavior. You had to send commands to the server for a long wait. Second, switching branches was also very painful. You had to download the differences from the server, even if a new branch is created, it takes a long time to execute the switch. Secondly, SVN provides the merge tracking technology. If a branch performs multiple merge operations, I am afraid it will not give such a gratifying result, and it will become very unintelligent, you even need to manually enter the exact version number to merge the data correctly. Therefore, after you use a branch to return to the trunk, you can delete the branch and restart it next time, however, it is really time-consuming to open a branch, especially when the version library is large, so programmers are often lazy and often directly change bugs in trunk, which is actually at risk.

The second is the ability to change the submission record. In SVN, everything is committed once, creating a branch, submitting, deleting a branch, submitting, merging a branch, submitting, changing code, submitting, revoking a change, and then submitting. There will be a lot of submission records. In order not to let one of my changes spread across too many commit records (the submission history is not good-looking), I often reduce the frequency of submission, which is even more risky. When Git is used, it is completely different. I can submit it at will or even run the script to submit it automatically. When I really want to archive it, I can use interactive rebase, combine the previous submissions into one. You can select some continuous commits and combine them into one by dividing them by function. This will produce a very clear and meaningful submission history, it does not cause code loss. Great.

Git rebase is another feature I like. Because the commit itself is no longer a natural number of orders, people cannot perceive how to adjust the order of commit. They can only distinguish the order by timestamps, in this case, the commit sequence is adjusted. If the submission history is clearer, rebase is doing this. I often develop a branch independently, which is too long to be separated from the trunk, at this time, I only need to rebase the trunk. The next time my code returns to the trunk, it will look like a natural append to the last few commits of the trunk, which is completely linear and clear, after careful merging, we can produce very beautiful results.

Powerful and democratic community

Git's decentralized design naturally adapts to the open-source community, because programmers in the open-source world work independently and do not interfere with each other, and must cooperate to contribute open-source software. Git solves this problem well, A popular Github community has been created. In this community, you can select various projects you like, fork, research, contribution, and apply for pull request, this is completely a friendly programmer-style communication method. If you like my project, please fork me. If you want to do something, please pull request me, if I agree with your efforts, I will accept. This collaborative atmosphere is completely asynchronous and does not require too much communication and courtesy. I like the community like Github too much. It has given birth to countless creativity and liberated productivity.

Conclusion

I think, for more reasons, it is difficult to come up with resonable, but from the very beginning it was difficult to use Git, to the joy of being forced to learn and learned, then, daily development can no longer be separated from Git. I was excited by my transformation. I even thought that I had already integrated into the open-source community, at least I tried to contribute code and was accepted by the original author, great!

GitHub Tutorials:

GitHub tutorials

Git tag management details

Git branch management

Git remote repository details

Git local Repository (Repository) Details

Git server setup and Client installation

Git Overview

Share practical GitHub tutorials

How to Build and use Git servers in Ubuntu

Git details: click here
Git: click here

This article permanently updates the link address: