Is Git ready to be recommended to my boss?

Question

I want to recomment Git to my boss as a new source control system, since we're stuck in the 90s with VSS (ouch), but are the tools and 3rd party support good enough yet?

Specifically I'm talking about GUI front-ends similar to TortoiseSVN, decent visual diff/merge support, as well as stuff like email commit notifications and general support from 3rd parties like IDEs and build systems.

Even though this will be used by programmers, we really need this kind of stuff in our team. I don't want to leave everyone stuck with a new tool, and even a new source control paradigm (distributed), with nothing but a command-line app and some online tutorials. This would be a step backwards.

So what do you think... is Git ready? What decent tools exist for Git and what third party development apps support it?

EDIT: My original question was pretty vague so I'm updating it to specifically ask for a list of available tools and 3rd party support for Git. Maybe we can get a community wiki post with a list of stuff.

I also do not consider 'use subversion' to be an adequate answer. There are other reasons to use a distributed source control system other than offline editing - private and cheap branches being one of them.

Answer 1

Depends on the team. If you're part of a technologically savvy team, then git is wonderful (and often more than wonderful). But if some people arn't comfortable on the command line, there could be some trouble (because tortoisegit is in its infancy and all the other GUIs I've come across, frankly, suck).

If you've got not-so-techie people to deal with (designers, higher-up managers, etc.), I'd go with something like subversion. TortoiseSVN is wonderful (and fairly easy to use), and svn's got maybe 80% of the awesome git has.

Answer 2

We use git at my company, and based on your requirement for visual tools I would say no. tortoisegit is coming, but isn't quite there yet. Tools like GitX and GitNub are great in OS X, but they don't totally cover everything you're describing.

Give it time, though. Git is moving at a pretty quick pace, and thanks to that growth demand for visual tools is increasing.

The biggest issue you'll probably run into is the paradigm shift. It's not the easiest thing to master, and it will be frustrating to some on your team as they get used to working with Git and its more distributed (although I'm not a big fan of calling them distributed SCMs) nature.

With that said, using Git has been awesome and my company, and I'd love to see another company join the mix.

Answer 3

A much easier pitch (and one I've done successfully) is to set up a central Subversion repository, which gives everybody the good tools like TortoiseSVN. Then, developers who want to can use git-svn as a full Git environment as a Subversion client.

This works really well because there is still a central repository where everybody knows that a given change has either been committed, or it hasn't. Then, on the edges people can use the tools they want (Git) to get their jobs done.

Answer 4

The default git GUI for Windows is awful and tends to get stuck in rescan loops. I now use the command line client, which seems fine as long as you can deal with using vi for making your log entries. I just started using github, which is ok but has lousy navigation.

Personally, I use Subversion with Apache for almost everything I do. Subversion works great, is well-documented, is easy to set up and free.

Answer 5

Do most companies of any typical size really need distributed source control?

Git works well for open source projects where people from all over the world are collaborating on a project at vastly different times, where the validity of check-ins is determined by merit and a web of trust.

At a company where, say, a commit requires QA analysis or a configuration manager's approval and/or documentation, or to reconcile a revision number with that in a bug report, I would submit that distributed control such as Git really does not make sense, in the sense that the paradigm shift is not warranted; that it does not yet fit well with existing CM processes (a social problem); that it does not integrate well with existing tools, third-party and otherwise; and that it has poor Windows support.

Not that it's not good; it's that I am quite skeptical to believe that it's the right tool for most corporate environments. I look forward to some of the other responses for insight.

Answer 6

Moving from VSS to Subversion is going to be already a great upgrade. Subversion will give you great features like atomic commits, great GUI, integration with IDEs, great Windows experience, the concept of a changeset, reliable repository, etc. For a typical Windows based company with small/medium teams, I think subversion is a great tool.

If you are interested in a Distributed VCS, then you should be looking at git, hg, bzr. hg and bzr are ahead of git as far as Windows supports. However, there is a ported command line version of git for Windows (msysgit) which merges back changes to main git. Also the git community is growing fast and hence I expect that the Windows experience will improve.

Git supports a hybrid scenario where the server can be CVS / SVN and individual developers can use git-svn to work locally and manage local branches. This kind of setup gives the best of both worlds. However, git-svn is flaky on Windows due to a dependency on Perl SVN libraries. In this scenario, it is not as easy to use nice features of git like developers sharing branches, etc.

Given that your projects are not open source, I think Subversion is likely to provide all the features you need. Once Git is up to the Windows usability bar that you need, then you can import your SVN repos into Git.

Unless your company is heavy on branching and merging, I would go for SVN, otherwise, you will need to consider a DVCS closely.

I have been working on an open source project, the repository was stored in CVS, which then got migrated to SVN, and then to Git. Every step was a major upgrade. The major motivation for SVN to Git move was to make it easier for contributors to maintain their own branches, keep them up to date, push them to developers, and for developers to easily apply them with minimum effort.

Answer 7

When it comes to graphical tools for git, the only useful tool I've used so far is gitk (which visualizes the revision tree for you) and I've been using git for the past half year myself, As someone else here put it, TortoiseGit is still very early and has some kinks to work out.

At work we've been evaluating three different DVCS's (namely git, mercurial (hg) and bazaar) and had a full packed evening presenting them for the rest of the company. Mercurial received most positive response and there is a Tortoise variant of it.

I'd suggest you do the same thing. Find someone who can present some alternative to git (such as mercurial or bazaar) and do a presentation together on DVCS at your company. It is more important to tell your coworkers how awesome DVCS is rather than the boss because in the end they will be using it. So it's more educational if they have been exposed to such tools and get a taste of it for themselves.

When we presented it we also assumed people didn't do version control so we explained quickly basic concepts such as checkin-checkout vs. commit-merge and why people version control. Basically it was like Eric Sink's articles on version control but stripped down to bare essentials.

Since you're going from VSS (and I'm so sorry) you might want to have a look at SVN. However as I see it, the only difference between distributed and the centralized approach is the added complexity of sharing code through a peer-to-peer looking network.

Answer 8

There is a very good pod cast about GIT.

Answer 9

I am a newcomer at GIT, and after using it for a a couple of weeks have to say that its really great, once you get the hang of the command line prompts.

To answer your question "Is Git ready?" => I think it is (except for the command line learning curve.)

I think you and your team/company should ask yourselves "Are you ready for git?." Once you start using it you will clearly have alot of power at your fingertips.

Your first steps to learning git are:

• Reading the git guides at github.
• Head over to Pragmatic Programmers and d/l the "free" Insder to Github
• You can also pick up the Pragmatic Version Control Using Git

Answer 10

Just in follow-up to Spoike's mention of TortoiseHg for Mercurial, the windows standalone download for Bazaar does include TortoiseBzr these days, although it is marked as experimental.

I tried it quite a few versions ago and found it unstable, but it may have improved greatly since then (especially if they are willing to package it with the official Bazaar release).

If you're really after a decentralised version control with a tortoise like interface, I would give both a go and see how they fair.

E.

Answer 11

When I was first exposed to Git, my first reaction was 'I just don't Git it'. I saw many powerful tools, but they weren't very intuitive. As I became used to using Git, I realized that the only feature that I really liked was quick cheap and easy branches.

I tried a few of the graphical front ends, including the GTK one that ships with Git. I found those to be more confusing than command line operations.

If your company is used to Subversion and you need to change to a DVCS, try Mercurial. Subversion users will feel at home very quickly. However, few people can really wrap their head around Mercurial's idea of what a branch should be .. which kind of shoots using a DVCS in the foot in the first place (barring being able to commit locally and push/pull to others prior to pushing to the main repository).

I work daily with Subversion and Mercurial, which suits all of my projects quite well. I think, unless you need Git's power of branching and ability to edit previous revisions ... Subversion or HG is going to be your best bet. I would not recommend Git as anyone's first exposure to a DVCS, but just my opinion and experience with it.

Answer 12

Sure, I think Git is ready. Just make sure that you have time in your project schedule to get people used to it when they switch over...

Answer 13

Is there support for Git within most 3rd party applications (other than Eclipse..) yet? Not for many of the ones I've seen.

Git is probably not going to be replacing SVN completely--they are different enough that each may have their role for some time. Anyway to answer the overall question: no, it's not ready for prime time in the business world. Perhaps it will be some day, in some cases (probably not all cases), but of course it's still too new--many people have not even heard of it yet! Just the fact that you've been advised to do a presentation on it to get buy-in should be a red flag. If you go to devs nowadays and say you want to move to SVN, the only ones who won't immediately understand are the ones living under a rock, and who cares about them?

Besides, newer is not always better. It takes time for this type of paradigm shift to be confirmed as an improvement--look at the backlash on Maven over time. Don't be so fast to jump ship from a proven solution, not when your job and reputation is at stake--if Git doesn't work out, you wouldn't look good recommending it. At least with a product like SVN you have the fact that it's NOT new, it's definitely proven over time, and even if there are problems the recommendation can't be questioned too harshly because it's still the default answer from most devs. It's harder attacking advice to switch to an industry standard than a switch to something new and non-standard.

Not the answer you wanted to hear (it appears you've already made your decision), but ask yourself if the benefits (and branches are something to be avoided, not encouraged) really outweigh the risks.