To use, you simply git pr 51 or whatever the pull request is.
Here’s what it’s doing:
Creating a branch pr_[pull request number]
Pulling down the patch
Piping the patch to apply. The -3 indicates a 3 way merge. If we don’t use this option and we have conflicts, it just sort of fails.
We could optionally do this in our master branch and eliminate the git checkout portion, then it would simply be a matter of a merge commit & a push to finish things up.
Here’s a pretty common git error message if you’ve added a remote origin server manually.
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
specify which branch you want to use on the command line and
try again (e.g. ‘git pull ‘).
See git-pull(1) for details.
Well, fortunately it’s pretty easy to fix. Edit your .git/config, adding the remote and merge lines under your master branch.
[branch "master"] remote = origin merge = refs/heads/master
There’s an overwhelming amount of git tools, and if you’re coming from SVN you might expect that the tools w/ the same names work the same way. You’d be wrong.
Because of Git’s distributed nature, you can (and frequently do) have commits in your repo that you might not have pushed up. You might also have forgotten what they were. Good thing there’s a tool to check that.
Lets assume you’re on your master branch, and you’re comparing against the origin remote repo.
I’ve been using SVN for several years now, so I’ve been partial to it, and reluctant to switch to another form of source control. I’m very comfortable with it, and I’ve got dozens of scripts to augment it and help me deal with it’s shortcomings, as well as a few blog posts.
Easier to create a repository from existing code.
This is the first thing I noticed about git that absolutely crushes subversion. With subversion, you have a repository that you check files out of. With git, you can literally create the repo while you’re in a directory.