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

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

Great question, I've been using SVN for quite a while, and feel pretty comfortable with it. But I had to use Git a couple of times to get source code from different open source projects. Still I haven't taken the time to really learn about it. Is it worth it?

I would also ask what are the advantages of using distributed version control over a normal VCS as subversion.

Answer 2

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 3

Skeet has most of them, but:

Pro:

• Branching! It's so much nicer to work on chunks of functionality in separate branches and still be able to version control them than having multiple things going on in one branch. And once you've decided you like branching, you have to love how easy git makes it compared to SVN

Answer 4

Merging is much more simple in git since creating branches is the default, not an extra option. So when you have to merge something, you just commit it and then you merge the two branches (the existing one and the new one which git automatically created for your last checkin).

Also, when using git, you always have the whole repository with you. You can check in while offline and merge later (since merging is much more simple).

The drawback is that GIT it almost unusable on an USB drive on Windows. Windows disables caching for these and GIT works with millions of tiny files. Also, IDE support is still lacking. I'm not sure the latter is really an issue. The UI which comes with GIT is pretty nice.

Also, I'm not 100% happy that you have to "add" existing files all the time [EDIT] and the enormous amount of features. For a beginner, they are overwhelming and it's often unclear why you would want to use a certain option/command. I mean, CVS comes with, say, 20 commands. GIT comes with 73 and each has lots of options (and that's not counting the plumbing commands ...).

Answer 5

The Windows support is appalling so I moved to Mercurial, another DVCS that's as good.

The benefits of DVCS become apparent when you for example have a repository in your server in the office and you're working on site. Being able to commit locally without access to your server office (and this rollback when necessary) is brilliant!

Answer 6

A lot of people would deny this but the choice of source code management tool influences the way you work. I used to work a lot with Subversion—until I discovered Git for me. I mostly avoided branching in Subversion. Whenever I could not avoid it I preferred setting up a local mirror (using svk). While branching is easily done in both Subversion and Git, only Git makes merging (and rebasing!) fun, Subversion has always been a royal pain when it came to merging time.

Second thing that I really like about Git (apart from all the points that have already been mentioned) is the “index”, a staging area that holds your next commit, and the possibility to only add single chunks of a changed file to it.

Answer 7

The latest version of Git can work directly in Window' command prompt, which is how I use it. The process is fairly trivial for me now.

I also have Git installed on an external hard drive and on my jumpdrive. Whenever at a new computer, I run a script that temporarily sets the path to include Git's tools. Then you can continue developing!

Answer 8

Pro:

• Fast - very fast.
• Creating a new repo is very easy compared to SVN
• The full repo is contained in just one .git folder - it will not add a .SVN folder in every folder of your code(not a big deal, but I like it)
• Branching is easier
• GitHub!

Cons:

• Cannot checkout a part of the repository(like just one folder or just one file)
• Does not track empty folders
• Bad Windows support(does not bother me much - I use Linux)
• I still have not found a good GUI tool for Git yet(I use KDESVN for SVN). Not a big issue if you are comfortable with CLI.

Answer 9

Working with git is very different what working with other versioning systems.

Having a local repository is very important. It means that you can use the full power of the versioning system (and this is a lot with git) without disturbing anyone. If there is a controversial issue in your project you can just work on it privately - by creating branches, stacking up patches and polishing them. That way you can come back with an ironed out patch set. But even in "normal operation" it is much better if you can clean up your patches before showing them to the public and in fact debugging is much easier if you have sane patches and not just "end of day" snap shots.

Before I commit a bigger set of patches I typically reorder the patches and squash bugfixes on my new code directly into the patch. So the patches look like I never made any mistake. After that my private branch is rebased on top of HEAD and then pushed. I typically never use a merge as it only clutters the history.

In short: It allows to keep your history clean.

This gives you a very different view on your work. It allows you to see the current state as an addition of single patches that create a history that is not just a log but something that you put there on purpose. Patch sets are the bricks you build your application from - and move to the right place if necessary.

I would never ever voluntarily go back to any other versioning system I used before git or any versioning system that does not support rebase and local branches and commits.

Answer 10

Other considerations:

Pros:

• Flexible: doesn't enforce one, true workflow
• So fast that version control becomes a minor task
• Lightweight branches, easy merging and staging area allow personalized workflows
• More powerful
• Very compact repos

Cons:

• No built-in access controls
• Weak tools for binary files. Doesn't compact changes to binary files in repo and storing binary files prevents auto-handling of line endings in Windows.
• May be harder to learn because it is more flexible and more powerful. Doesn't always follow CVS/SVN semantics and isn't organized around files.

Answer 11

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.

Answer 12

Pros: Why Git is Better Than X