About the etiquette of git

(This is a section on how to respect a programmer, but the use of git has given rise to a common lack of respect for programmers, which is now specifically written separately.) ）

Git is now the most popular code versioning tool. In layman's terms, git is a "repository" or "custodian" of code, so that many people change the code to know who changed it. In fact, no matter what tools, whether it is the editor, programming language, or version control tools, compared to the core of the programmer's ideas, are secondary things, are playing an auxiliary role. But the Git tool seems particularly annoying.

Git is not as good as many people boast, and there are obviously crappy designs. With the traditional UNIX same strain, Git does not have a good packaging, the designer of their own internal implementation of the details of the relentless disclosure to the user, so that users need to figure out how the designer inside the end, or many times do not know how to do. Users are forced to remember a lot of wacky commands, and the command line design is not very reasonable, and sometimes you need to add-f parameters, the location of the parameters may not be consistent, but also does not necessarily play the desired effect. All sorts of strange phenomena, such as "head detached", force the user to understand how it is designed internally. As the git version updates, new features and commands continue to grow, and then you finally see that foreach appears in the command line, only to find that its command line is fast becoming a (bad) programming language. If you understand Ydiff design ideas, you will find Git and other text-based version control tools, in fact, belong to ancient things. However, many people make git sacred because it is designed by Linus Torvalds.

The most annoying part of git is not the trouble it uses, but the psychological shadow that its "senior users" have to give you a commanding attitude. Many people think that superior is a professional attitude because they are "proficient in git". As users increase, the initial design of Git is becoming more and more useless, so some of the rules seem more and more and can be written in a book! With Unix's traditional same strain, Git gives you a lot of "mechanics" that you can hold on to, and then you don't know what's wrong. So you often listen to someone say: "Not git allows you to do this, you can do it!" The philosophy of UNIX is not to stop stupid people from doing stupid things ... " If you do not know some of the rules of GIT users when you submit your code, someone will yell: "Rebase again!" "Don't push to master!. "Don't merge!. "" Squash commits! "If you don't use git submodule and stuff like that, someone might despise you and say," You should know that! ”

For example, this kind of shouting to people's feeling is that after you have won the Olympic gold medal, the practice of equipment back to the equipment storage section, the result of the administrator yelled at you: This put this way! Put that over there! You don't know the rules, do you? "Did you see the problem?" The programmer submitted a high-value code (the Olympic gold Medal), and the result was snapped by some of the people who thought git was very familiar (the equipment keeper).

A company culture that respects the programmer, should put the programmer as the athlete, put the programmer's code in the Honorable position. Other tools should be the same as the equipment storage section. We respect these equipment custodians, but if the athletes do not understand the equipment you set up the rules, you should also show respect and understanding, talk should be polite, should not ride on their heads. So, for some of the commands and usages of git, I suggest that when you introduce yourself to newbies, it starts with this: "You shouldn't have known that, but now we don't have any better tools, so we have to do this ..."

About the etiquette of git