I hate Git for 10 reasons

Git is a source code version control system and is rapidly becoming the standard for open-source projects. It has a powerful distributed model that allows advanced users to use branches to handle various thorny problems and rewrite history records. However, learning Git requires more effort and unpleasant command line... information & nbs

Git is a source code version control system and is rapidly becoming the standard for open-source projects. It has a powerful distributed model that allows advanced users to use branches to handle various thorny problems and rewrite history records. However, to learn about Git, you need to make more efforts. the unpleasant command line interface and Git are so neglected by its users.

The following are 10 reasons why I hate Git so much:

1. complex information model

Git's information model is very complex, and you must understand them very well. In this regard, you can look at the Subversion: there are files, working directories, resource libraries, versions, branches, and labels. You need to understand these things. In fact, you already know about branches, labels, and files. but if you use Git, you need to know more about the concepts: file, work Tree, index, local resource library, remote resource library, remote, submit, treeishes, branch, and stash. You need to know more knowledge points than Subversion.

2. crazy command line syntax

The command line syntax of Git is completely random and inconsistent. for example, git pull is basically the same as git merge and git fetch. the merge of git branch and git checkout becomes git checkout-B, the different parameters of the git reset command do different things. after the file name is specified, the syntax of the command is completely different.

The most spectacular is the git am command. as far as I know, this is because Linus used different patch syntaxes to solve the problem of reading patches by email one night, especially on the Mail title.

3. poor and confusing documents

Speaking of the Git document, the only thing I want to talk about is "operation ". They are writing documents for computer scientists, not for users. Here is an example:

Git-push-Update remote refs along with associated objects

For users, it should be described:

Git-push-Upload changes from your local repository into a remote repository

Another example:

Git-rebase-Forward-port local commits to the updated upstream head

Translation: git-rebase-Sequentially regenerate a series of commits so they can be applied directly to the head node

4. information model diffusion

The Git information model I mentioned at the first point is very complex, and it is still spreading like cancer cells. of course, Git is always used, new concepts such as refs, tags, the reflog, fast-forward commits, detached head state (!), Remote branches, tracking, and namespaces.

5. full-blown abstraction

Git contains too many non-abstract abstractions, and there is often no difference between defining user interfaces and implementations. this is understandable. for an advanced user, he needs to understand the specific implementation of some functions, to understand the nuances of each command. However, a large number of internal details are a nightmare for beginners. There is a saying that for plumbing equipment and porcelain, you must be a plumber to know how the equipment is installed on porcelain.

Many people have responded to my complaint: you don't need to use all the commands. you can use Git like Subversion. This is a sophistry, just like telling a grandmother that the highway is not terrible. she can crawl 20 kilometers per hour in the fast lane on the left. Git does not provide any useful subsets. Each command is associated with requirements for other commands. simple actions often require complex actions to be undone or improved.

Below are some good suggestions from a Github project maintainer:

1. search for the merged benchmark on the branch and master: 'Git merge-base master yourbranch'

2. assume that you have submitted a change record, from rebenchmarking your submission to merging accuracy, and then creating a new branch

3. git rebase- HEAD ~ 1 HEAD

4. git checkout-B my-new-branch

5. Check out your ruggedisation branch and then remove the commit: 'Git reset-hard HEAD ~ 1 ′

6. merge new branches to ruggedisation: 'Git merge my-new-branch'

7. check out the master ('Git checkout master'), merge the new branch ('Git merge my-new-branch'), and then check the merged status, then remove the merge ('Git reset-hard HEAD ~ 1 ′).

8. submit a new branch ('Git push origin my-new-branch') and record the pull request

Grandma, it's easy to drive on the highway. Loosen the clutch, let the speed exceed 6000 turn to make the wheel slide, then enter the first bend and go to the highway, look at the road signs to the exit, use the handbrake to shift to the exit.

6. easy maintenance, but difficult to submit

A powerful aspect of Git is the maintenance of the Code Reference Library. you must merge the submissions from a large number of different sources, which is very suitable for large-scale parallel development. However, these are not designed for most Git users. they only need to write code and may be on the same branch for several months, for them, Git is a dual-pot coffee machine with four handles, but users just want to have coffee right away.

Interestingly, I don't think this is a balance between Git's design. It completely ignores real user needs, obfuscation architectures, and interfaces. If you are an architect, Git is great. But it is terrible for users. many people are writing some simplified interfaces for Git, such as easygit.

7. insecure version control

As a version control system, it must promise that once the code is submitted to the system, I will ensure code security and you can retrieve any changes you make. Git, however, has many ways to completely crash the entire database and make it unrecoverable:

1. git add ./... /Git push-f origin master

2. git push origin + master

3. git rebase-I /Git push

8. assign the owner of the version control database to the contributor.

In traditional open-source projects, the maintainer only needs one person to handle branch and merge complex operations. Others only need simple update submission, update submission, and constant update submission. Now, Git makes every user need to understand the various operations that need to be known as maintainers, which is annoying. But what about maintainers? they have nothing to do. they have to raise their legs and drink coffee.

9. Git's history is a bunch of lies

The main output of development work is the source code. a well-maintained code history is very important to a product. There are a lot of arguments about rebenchmarking, most of them rely on aesthetic judgment on messy and unreadable days. Rebenchmarking provides developers with a "clean and tidy" but useless historical record. In fact, the correct solution is to better output logs and filter unwanted merging.

10. simple tasks require many commands.

If you are developing an open-source project, you have made some changes and want to share it with others, you only need:

1. modify the code

2. run svn commit.

If you add some new files:

1. add a file

2. svn add

3. svn commit

If your project is hosted on a Github website, you need:

1. Make some changes

2. git add [not to be confused with svn add]

3. git commit

4. git push

5. so far, your changes are only half done. next you need to log on to Github, find your submission, and then release a "pull request" so that other people can get your changes.

In reality, the Github maintainers want your changes to be functional branches and they will require you to perform the following operations:

1. git checkout master [to make sure each new feature starts from the baseline]

2. git checkout-B newfeature

3. Make some changes

4. git add [not to be confused with svn add]

5. git commit

6. git push

7. log on to Github, switch to your new feature branch, and release the "pull request"

To move your changes from your local directory to the actual project resource library, you need to: add, commit, push, "click pull request", pull, merge, and push.

The following is a flowchart to show you what a typical developer is doing on Subversion:

"Bread and butter" is a command and concept used to operate on remote SVN databases.

Then let's take a look at what will happen if your project is hosted on Github:

If Git is powerful in branch and merge, its weakness is to make simple tasks very complex.

Source: 10 things I hate about Git