Thursday, April 17

Git for Idiots (and Java developers)

Uploaded with plasq's Skitch!
Sorry, I couldn't resist the little jab. This is actually a quick reference cheat sheet for a team of Rails developers (myself included) about to make the leap from Subversion to Git...

Your first time?

  1. Head on over to
  2. Create an account.
  3. Generate a public key.
  4. Get a copy of the repository:
  5. git clone
  6. Move into the new directory:
  7. cd rss2twitter
  8. You're ready to go!

Business as usual...

  1. Say you're assigned ticket 222.
  2. Make sure you have the latest code:
  3. git pull
  4. Create a branch to work in (named after the ticket number):
  5. git branch 222
  6. Switch to that branch:
  7. git checkout 222
  8. Make your changes (and write lots of tests).
  9. Add the file(s) you've changed:
  10. git add somefile.rb
  11. Make sure you didn't miss any:
  12. git status
  13. Commit often (it's cheap):
  14. git commit -m "a clear but brief summary of the changes"
  15. All done? Make sure all the tests pass!
  16. Switch back to the "master" branch.
  17. git checkout master
  18. Merge your branch:
  19. git merge 222
  20. Publish your changes back to the central repository so everybody else can get them:
  21. git push
  22. You're done! ( soon as you deploy to staging and assign the ticket back to the creator for validation.)


Jack Danger Canty said...

I love it! This is pretty much all it would take to start using Git for everything. Anything else is just a google away.

One note: I think your rss2twitter clone url is the private version. The public one is git://

dysinger said...

Fellow Rubyist here:

That is kind of a conceded jab since your tutorial is soooooo bone-headedly basic. You aren't publishing anything here other than "Java sucks".

How about some real meat?

Dave said...

git-commit -a commits anything known to Git, but uncommitted, so you don't need to explicitly add changed files with git-add unless you want to create a commit that is a subset of your current uncommitted changes (which you may want to do).

Anonymous said...

chances are, that this isn't a very smart question, but wouldn't it be better to run the tests right after the changes been made (step 6) and not after the git commit (step 9)?

Joerg said...

if you just want to play nice with other committers, it suffices to do it before step 12 (=push to master repo), i.e. before others can see your changes -
if you want to be a more efficient developer, however, you do it as described in the post, i.e. before checkout+merge with master repo (wasted time, if tests do not pass yet!) -
the benefit of doing it after step 8 (=commit into your local clone) is, that you keep a nice track record (in your local repo clone) of how your code was fixed/refactored until the tests finally pass.

;-) Regards,