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?
- Head on over to github.com
- Create an account.
- Generate a public key.
- Get a copy of the repository:
git clone git@github.com:trak3r/rss2twitter.git
- Move into the new directory:
cd rss2twitter
- You're ready to go!
Business as usual...
- Say you're assigned ticket 222.
- Make sure you have the latest code:
git pull
- Create a branch to work in (named after the ticket number):
git branch 222
- Switch to that branch:
git checkout 222
- Make your changes (and write lots of tests).
- Add the file(s) you've changed:
git add somefile.rb
- Make sure you didn't miss any:
git status
- Commit often (it's cheap):
git commit -m "a clear but brief summary of the changes"
- All done? Make sure all the tests pass!
- Switch back to the "master" branch.
git checkout master
- Merge your branch:
git merge 222
- Publish your changes back to the central repository so everybody else can get them:
git push
- You're done! (...as soon as you deploy to staging and assign the ticket back to the creator for validation.)
5 comments:
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://github.com/trak3r/rss2twitter.git
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?
http://dysinger.net/2007/12/30/installing-git-on-mac-os-x-105-leopard/
http://code.google.com/p/git-osx-installer/
http://www.rubyinside.com/git-and-ruby-git-tutorials-articles-and-links-for-rubyists-860.html
http://git.or.cz/course/svn.html
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
http://jointheconversation.org/railsgit
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).
hi
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)?
Anonymous,
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,
Joerg
Post a Comment