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?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

This is a good question, shame it's closed. One of the real cons of git here is that it's harder to use when you need to fetch a very large repository with huge commit history, just in order to see the source or do a simple patch. In svn you are directly getting sources of latest head and you can resume the download if connection fail. In git even with --depth 1 you get a huge overhead of other things and if you are on unstable and slow connection, it may be even impossible to get it
–
PetrJul 30 '14 at 6:24

I like git for the most part, but pros are covered so I'll mention con. Con is that, for a newbie, it's actually very easy to lose changes. When I first started, I frequently got in a detached head state and when I switched to another revision/branch, I lost my commits.
–
ChanceJun 2 at 13:14

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

There's no problem using Git from Windows command prompt, really. I've been using msys Git from Powershell and cmd.exe without issues for a while now. As for the lack of Explorer integration, that's a Pro for me :-))).
–
Milan GardianJan 13 '09 at 14:19

2

Ooh... I didn't realise that git is okay from a normal cmd.exe. Must try that...
–
Jon SkeetJan 13 '09 at 14:25

When using msys Git 1.6.0.2 install, all you need is to have "(git_install_dir)\cmd" in your PATH. I also recommend setting "color.interactive", "color.branch" and "color.status" to "always" (git config) - that way you'll have colour output in "git status" (and others) even when run from cmd.exe.
–
Milan GardianJan 13 '09 at 15:04

2

TortiseGIT seems to work great, if you like Explorer integration.
–
davenpcjJun 13 '09 at 14:00

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

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.

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.

You can not check out a part of repo be cause it's concept of distributed revision control, that you as user have to have a complete repo on your local machine. Keep in mind that only once when you clone project to local machine you pull all stuff. Next pull will give you only changes.
–
Marcin WaśniowskiJan 23 '13 at 23:58

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!

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.

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 ...).

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!

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

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.

That's either not right, or obsolete. Git detects moves, whether you do them with 'git mv' or outside of git and check them in, based on file similarities. It's possible to move AND make enough changes in one commit that it doesn't detect this, but at some point, that makes the fact that you started with a particular file somewhat irrelevant anyway. One workflow when it involves moves is to stash your edits, redo the move and check it in, and then reapply your stashed edits.
–
Bob KernsOct 4 '12 at 20:38