Skip to content

Instantly share code, notes, and snippets.

@virtualandy
Created September 14, 2012 22:06
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save virtualandy/3725230 to your computer and use it in GitHub Desktop.
Save virtualandy/3725230 to your computer and use it in GitHub Desktop.
Git-ing away from SVN

Switching to GitHub

Many companies ask why they should switch to Git and GitHub. The answer primarily lies in doing less repetitive work, and making your source code control efforts disppear into the background instead of be in the forefront of your workflow. Your focus should be on your creative work and just incidentally have it versioned. As soon as your project is no longer a solo effort, you desire to have it support collaboration. In the space of version control, our users claim that no set of tools does that as well as Git and GitHub.

These goals are explained in a highly creative way by GitHub's CEO in The Git Parable.

Additionally, a growing constituency of open source is hosted at GitHub. In June of 2011, GitHub had more commits than Sourceforge, Google Code, and CodePlex combined.

What are Git and GitHub?

A set of videos on the official Git site offer a basic C-Suite level review of the benefits of Git and GitHub.

Additional, there is an About Git set of pages that explain the same ideas in text and digram form.

Testimonials about switching to Git and GitHub

Companies that use Git and GitHub

As listed on https://github.com/ and https://enterprise.github.com/, the following organizations use GitHub:

  • The White House
  • Rackspace
  • Etsy
  • Simple
  • DRW
  • Blizzard
  • Facebook
  • Twitter
  • Microsoft
  • VMWare
  • RedHat
  • LinkedIn
  • Mozilla

It was reported by the GitHub sales team that 20% of the Fortune 100 uses GitHub.

Where can I find other public resources for learning Git?

We've curated a set of Delicious bookmarks on all things Git and GitHub.


Git-ing away from SVN

If you like using Subversion, that's awesome. If SVN isn't enough and you'd like to migrate to Git, here's an overview of the 'What', 'Why' and 'How'.

Maybe a move to Git started with a few questions at work. Change is hard, even in software, and Git usually causes enough concern that a few concerns arise. We'll try to answer those concerns with answers derived from experience.

Why switch?

Also known as "What's the justification?", the "Why?" question is common in a well established team. You're already using something for version control - maybe it works but gets corrupted every once in a while, or is hard to administer - and introducing Git is feared because the folks in charge are afraid it's only going to get worse. And someone has to appease the folks writing the checks, too.

We've seen this question phrased the following ways (if you have any additional examples, submit a pull request).

Please provide justifications for the [using Git] (e.g. We should use XXX because..., and XXX is better than the others because ...)

Let's ask Git itself:

The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.

Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

In practical terms, Git's branching powers may give your developers more options and freedom in their styles of applying version control. Create a branch, blow it away, merge it into master with the world's greatest feature, or submit a simple bug fix. It can all be done with branches and it's only a few clicks and key presses away. And you don't have to worry about being too far out of sync with the one golden master.

Notably, when you push to a remote repository, you do not have to push all of your branches. You can choose to share just one of your branches, a few of them, or all of them. This tends to free people to try new ideas without worrying about having to plan how and when they are going to merge it in or share it with others.

Git can 'free people' to be more productive, to experiment, to solve more problems. We like the sound of that.

Justifications

  1. Git has a small disk and memory footprint and is very fast.
  2. Distributed version controls gives you many workflow options. It provides naturally created redundant repositories, in case hard drives get lost or corrupted. This happens more frequently than you'd like to believe.
  3. Git is free. Git uses a GPLv2 license allowing for it to be used in any commercial or non-commercial environment. There are free-to-read books such as Pro Git, a popular hosting solution in GitHub, comprehensive resources and documentation and even free tools for graphically working with or hosting Git yourself. Check the References section of this page for other hosting solutions.

Suggested workflows

Git's flexibility is intriguing. But too many choices can also paralyze. If your workflow is pretty standard practice according to the prescriptions of another version control tool (i.e. check out the repository, make a change, commit it, resolve conflicts), here are a few suggestions and references for Git-based workflows.

The GitHub Flow

Scott Chacon's blog post on the 'GitHub Flow' is a great reference for those looking at potential workflows. It boils down to the following:

  • Anything in the master branch should be deployable at any time.
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes).
  • Commit to that branch locally, and regularly push your work to the same named branch on the server.
  • When you need feedback or help, or you think te branch is ready for merging, open a pull request.
  • After someone else has reviewed and signed off on the feature, merge it into master.
  • Once it is merged and pushed to master, you can and should deploy immediately

git-flow

In the aforementioned post on GitHub's choice of workflow, Scott starts off by discussing git-flow - a set of Git extensions created after a series of ideas laid out by Vincent Driessen in his blog post 'A successful git branching model'. Scott specifically points out some of the issues with using git-flow, so read the full post to get all the details. You may also want to avoid git-flow as it could encourage long run feature branches, unless formal releases on a long scale (months) is part of your plan or requirements.

The simplest thing that could work

Git itself is fairly complex to understand, making the workflow that you use with it more complex than necessary is simply adding more mental overhead to everybody’s day. I would always advocate using the simplest possible system that will work for your team and doing so until it doesn’t work anymore and then adding complexity only as absolutely needed. - Scott Chacon

A Google search for 'simple git workflow' returns over 500k results. Have we mentioned that Git's freedom results in lots of good information being shared all over the place? Whether it's a hack && ship or straight out of the git man pages, there's a good starting point for your team out there somewhere. Just take Scott's advice and start with something simple, then level up as needed.

Using Git in the desert

What if you can't setup a Git repository or hosting solution where you deliver your code and can only bring in a copy of your repository, in order to be able to make last minute changes? Let's just say we're going on safari and need to deploy some code in the middle of the desert to our remote controlled robot camera and we may need to make last minute changes while disconnected.

TODO: What is a good answer is on this one. Use case is bringing 'unsafe' code into a 'safe' or offline environment.

Q & A

  • How do I manage multiple projects with Git?

    Use a Git hosting solution, like GitHub or gitorious.

  • Can I manage and use common and third party libraries with Git?

    Probably, but a Maven-compatible artifact repository like Nexus or Artifactory may be a better option (for Java-based projects at least).

  • Can I use Git to store test data?

    If by 'test data' you mean 'large binary files that don't often change', then the answer is 'Yes!'. git-submodules may be just what you need.

  • How do I manage different development environments (Eclipse, Netbeans, Ant, etc) with Git?

    Hopefully you're not checking in your .project files, right? At any rate, different branches may be what you need here.

Git versus the World

Git certainly isn't the only distributed version control tool available. As usual, there's a Wikipedia page with a table outlining the differences between Git and other options (Bazaar, Mercurial, SVN, etc) that may be useful for a quickly spotlighting different options.

If you have additional feedback on the differences between git and other systems, let us know.

I just can't Git you

We get it. Software developers are known to be picky about the tools they use, and rightly so. If we haven't swayed you with this document, let us know what it is about Git that doesn't work for you. Maybe there is an alternative that just fits better, but if Git can be improved, that's good to know.

Steve Bennett's blog post on "10 things I hate about git" is one approach to doing just that. His blog got a lot of attention in early 2012 and part of that included additional tips and tricks to help ease his pain, so take a look to get his perspective as one example of a rare someone who wasn't enamored with Git.

But wait there's more

If you want to stick with SVN, but maybe start to try out Git before you fully commit, there are options.

git-svn is a simple option and comes built in to git itself. There's a simple overview and guide over at Github itself if you're interested. But be aware that there are limitations that you should understand before you go too far down this path.

Thankfully, the idea of using git and SVN together is popular enough to warrant several solutions. SubGit offers "smooth, stress-free Svn to Git migration". And it runs on the server side, so you can avoid client-side tweaks and some of the other major limitations of git-svn. If nothing else, SubGit offers great "let's give it a shot" potential that may be enough to eventually win over those in doubt (note that you'll need to purchase a license if you use it in production).

References

Internal Hosting

We all wish we could use GitHub github. If you're behind a firewall or in a restrictive environment, though, the public Internet site may not work. Thankfully, GitHub github offers an enterprise version that gives you the best of both worlds. @devnulled's GitHub Enterprise overview has lots of good reasons why GitHub Enterprise could benefit your team and organization.

Here's a few other options for hosting Git yourself

  • Gitorious - "The Git hosting software that you can install yourself."
  • Gitlab - a Rails based solution for hosting Git. Fast, secure and stable with releases every month.
  • Gitolite - control everything yourself using gitolite. All it needs is git, perl, openssh and a *nix distro and you're off and running.

Links

GitHub - the best place to share code with friends, co-workers, classmates, and complete strangers.

10 things I hate about git - "10 things I hate about git"

Comparison of Version Control Software - Wikipedia

@matthewmccullough
Copy link

I've made an issue for this at github/teach.github.com#2

@virtualandy
Copy link
Author

The Q&A section is very lite on details (because I'm attempting to answer my own questions :) ). So any help/clarification there is appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment