What are your pros and cons of git after having used it? [closed]

Question

I'm using SVN right now, and I've used CVS and VSS in the past. SVN is the current favourite in my books, but I've been hearing a lot about git. Of the people that have used git, what are the pros and cons from your experience?

Answer 1

I don't have a lot of experience with git, but:

Pros:

• It's really quick
• Local commits rock
• Quick to start a new repository (no configuration etc)
• github is easy to use

(I haven't really "needed" the distributed side of things yet, beyond being able to have a local repository and push to a public one.)

Cons:

• Windows support is still lagging behind, I believe - and you can't just use it from a normal command prompt
• Lack of IDE and Explorer integration
• It took me a while to find a good introductory text along the lines of the redbean book.
• The fact that "adding" a changed file only adds the contents at that point of time (so it can show up as staged for commit and still have modifications which require another git add) took a while to grasp

Answer 2

Number of Commands

While svn and other modern VCS like hg or others are nice and useful tools git is a shop full of machine tools. This accounts as pro and a con at the same time. While svn has 30 commands (according to 'svn help') git ships 130 man pages with more or less each of them describing a single command. One reason for this is that git exposes the lower level functions that most users will ever need as command line tools. But even without those lowlevel commands git ships a lot of very powerful tools and are not found in any other VCS I know (see git-bisect, git-filter-branch, git-cherry or git-reset for examples). While it is very helpful to have those tools at hand it makes it quite difficult for beginner to understand what command they need and need to know and which not.

---

Development Model

A similar topic is that git is powerful enough to support very different operation modes. This makes it difficult for beginners as there is not really a "best practice" document as the best practice is not build into git. So you have to decide yourself whether you

• Just use merges to avoid conflicts with you working dir
• Use private branches that get rebased to upstream HEAD
• Use upstream branches
  • that are merged regularly (flying fish)
  • merged when finished
• Use a tree of one project maintainer, tree maintainers, sub system maintainers, driver maintainers and contributors with each level pulling the patches from the level below (linux kernel)

As you have your local repository you can even use a very different operation mode than the project you are working on and just adjust your change sets before pushing/publishing them.

---

Path of the Changes

Another thing that also counts as pro and con depending on your view point is that working with git is more complicated than with any centralized VCS and even more complicated most other distributed VCS.

With centralized VCS you normally just do a commit and the changes you made go to the repository. In git the changes can go through a quite large number of steps before they end up at their final destination. Typical steps are (not so common steps in parenthesis):

• Working dir (editing)
• Index aka staging area (git add)
• Local repository (git commit)
• (Other local branch) (git rebase, git cherry-pick, git merge)
• (sub maintainer's repository) (git push, git pull, mail)
• Upstream repository (git push, git pull, mail)

As you can kind of skip the index there are at least 2 steps involved but typically there are more. This requires a deeper understanding of what you are doing and typing a lot more commands. On the other hand this gives you control over each of these steps. You can

• decide which junks/lines are going into the commit and which are not
• decide which patches you want in which of your local branches
• decide which of your patches are published
• rework, squash, fix, split, reorder your patches before publishing them
• decide yourself which people you trust and accept patches from
• delegate parts of the project to other maintainer you trust.

All this power and decisions make it difficult for beginners to get started with git. Once mastered they give an enormous control over the code.

---

Write Access

One major pro for any distributed VCS is that contributors do not require write access to benefit from the VCS. Everyone with read access can just clone the repository, create branches when necessary and begin stacking put patch sets. Working with cvs without write access is a real pain - with git there is not a big different how get get your patches in. This is not only a technical advantage but also saves complicated discussions whether this noobie should really get write access.