Why Git instead of SVN

Why corporate choose Git instead of SVN.

The learning curve of GIT is quite longer than SVN. I think it make the team productivity low.

Comments

[David Cantrell]

My experience is that the learning curve at least to start with isn't any different, because day-to-day git use for a developer is practically the same as day-to-day svn use, just the commands are spelled differently. There are only two major differences. First, you need to remember to git push. Second, branching and merging is much easier and you won't have to jump through so many hoops for it to work reliably.

[Daniel Selinger]

On the other hand the UI looks a little busy on this tool. But hey whatever gets the job done. I'm currently using git-cola most of the time these days...

[rhymes]

It GitHub was called MercurialHub we would all be using Mercurial right now.

[michelemauro]

Mercurial is far easier of GIT, it makes harder to make mistakes, and has a more consistent interface. It's a shame that is not in wider use.

SVN has been far surpassed by distributed VCS, both in features and in ease of use and support. Sometimes it happens.

[Botond Balázs]

I think cheap feature branches are the killer feature of git compared to centralized SCM systems. And those are useful for any team with at least 2 people. Git is also super fast!

[Erebos Manannán]

"Then there are special cases (e.g. games etc.) where something like Plastic SCM is better."

...

[K]

Somehow I leaped over SVN.

Until 2014 I worked in a company that uses CVS. They talked for years about "switching to SVN".

Then I changed company and they were using Git.

[Erebos Manannán]

Even just a single person benefits from using a good DVCS system over SVN/similar. SVN etc. are painfully slow, can't deal with branching or even just properly tracking changes, and are in so many other ways obsolete.

However, just picking Git because everyone picks Git is stupid, as is the case with most tools. Mercurial definitely is better for most uses. Then there are special cases (e.g. games etc.) where something like Plastic SCM is better.

The only workable GUI I know for Git is GitKraken, and that's a fairly recent thing. SourceTree supports both, but isn't great on either. TortoiseHG is what I typically use with Mercurial.

The worst thing about Git is that it was written by a kernel programmer, a person who has literally no idea of how human beings function and think, and really didn't care. Most commands in Git are much more confusing than they need to be, whereas Mercurial is trying to work in a predictable and understandable manner.

Just the amount of people who "proudly" present how many aliases they've set up on their machine to make dealing with git more reasonable is a good sign of this. I've never found a need to make a single shell alias to work with Mercurial.

It really terrifies me how many people think using Git from the CLI makes you cool or something, and then because they can't figure out how it works they just do a blind git add -A && git commit -m '...' && git push -f .. and people seriously just use push -f instead of trying to understand what is wrong when they've got 5 heads on a branch that should be merged, or they've not pulled other people's changes.

With a GUI you tend to see exactly what changes have been made, you can view the per-file side-by-side diffs easily to confirm it's what you think it is, commit what you wanted, and then see the different heads easily.

[Victor Carvalho]

"It really terrifies me how many people think using Git from the CLI makes you cool or something[...]"

Perfect point

[Ben Sinclair]

I don't think it's necessarily "cool" but I genuinely have trouble using GUIs for these sort of things.

[Daniel Selinger]

The only workable GUI I know for Git is GitKraken, and that's a fairly recent thing. SourceTree supports both, but isn't great on either. TortoiseHG is what I typically use with Mercurial.

There's also Git-Tower (git-tower.com). But it's Mac/Win only :-(

[Markus Sitzmann]

The learning curve of GIT is only longer if you are deep in SVN mindset. If you learn a version control software for the first time, GIT is probably even easier than SVN.

[edA‑qa mort‑ora‑y]

SVN is really antiquated when it comes to modern development flow. That said, git may not be the answer. It has a lot of features, but they're wrapped up in a garbage command-line interface.

A tool like bzr supports the same modern branching and process but offers a much cleaner command-line. There's less chance to mess up. There's of course fewer features, but as others have said, most teams don't really need git's full feature set.

I also believe that when people say git they often mean GitHub as well. It's that layer of tools on top that make it powerful.