For my latest project, I decided to bite bullet and go with git and GitHub.
The Getting started with git and github article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
It's a little disconcerting as I'm really comfortable with SVN but a good move nonetheless since that sort of comfort is rarely a good thing (there are many things I wish SVN did differently but I use it because I know it and it's not CVS!)
Setting up your project on GitHub couldn't be easier. It took me a few moments. I'd already installed git via MacPorts for something else (can't remember what) so I didn't have to do anything else.
Initially, everything went as planned.
Then, on my second clone of a remote repository, when I tried to git pull, I got the following error message:
You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me either. Please name which branch you want to merge on the command line and try again (e.g. 'git pull
If you often merge with the same branch, you may want to configure the following variables in your configuration file:
branch.master.remote =
branch.master.merge =
remote.
remote.
See git-config(1) for details.
Umm, yeah, sure, sounds fab, really it does, I'll do just that...
So I looked at the .git/config file in my initial clone and saw that it had a line that the new one didn't have in it (in boldface, below).
[remote "github"] url = <my github url> fetch = +refs/heads/*:refs/remotes/github/* push = refs/heads/master:refs/heads/master [branch "master"] remote = github merge = refs/heads/master
Adding the push = to the .git/config file for the other clone did the trick.
Not sure what it does or why it's necessary so if anyone can enlighten me, please do! :)
The Getting started with git and github article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Thanks for this, I’ve been eager to get started with git but too lazy to get over this hurdle.
On a different topic, you might want to change your pre tags overflow: auto; so you don’t get the unseemly scroll gutter when you’re not using it.
Hey Dylan,
Cool, glad to hear it was useful! And thanks for the pre tag style suggestion, I just implemented it. Looks much nicer indeed. :)
Hey Aral, I’ve just friended you on GitHub. When you’ve got a list of friends on there, it ends like a very dorky version of Facebook or Twitter.
Other things you should do when you start with Git: learn how to use .gitignore, learn how to tell Git what text editor you use (it’ll probably use Vim as a default, but you’ll probably want to switch it to TextMate). One thing I often do is to use a rake task for committing that runs my RSpec tests. You can also use pre-commit hooks to make sure your test suite is run before you can commit, or use something like a Rake, Make or Ant task (or a shell script) to make sure the tests run and pass before you can push. Also, learn about rebase. It’s very powerful and useful.
Also, be aware that some things will not be aware of your ‘.git’ folder while they are aware of .svn or CVS folders. I’ve had a lot of irritation with Hoe, the Ruby gem utility, which keeps deciding to delete my .git folder when I try and publish my gem.
Hey Tom, cool; just friended you back. The social aspect of GitHub looks very interesting.
Have to say, so far, I’m loving Git! T’was pretty painless to get started with it and now, with submodules, etc., I’ve actually got a better workflow than I did with SVN (never warmed to externs).
I hear you on .gitignore, had to start using it almost immediately. I actually don’t mind Vim as the default editor for commit messages (prefer it to the context change from Terminal to TextMate). After all, all I do is i for insert, type message, Esc, :wq :)
Will look into rebase and thanks for the heads up on non-git aware apps.
Thanks, this info really helped me, was stuck…