Update: So, over a year later and I’ve had some feedback from a colleague (thanks Ben!). Nothing here is drastically wrong, but some clarifications should help!
When I started out with git …
… who am I kidding, I’m still a git n00b. Today, I tweeted about git. I wanted to know what the differene between pull, fetch and clone is. After discovering that, really, 140 characters isn’t enough to answer the questions, I had a play around.
From what I understand, git pull will pull down from a remote whatever you ask (so, whatever trunk you’re asking for) and instantly merge it into the branch you’re in when you make the request. Pull is a high-level request that runs ‘fetch’ then a ‘merge’ by default, or a rebase with ‘—rebase’. You could do without it, it’s just a convenience.
[sourcecode language=“bash”] %> git checkout localBranch %> git pull origin master %> git branch master * localBranch [/sourcecode]
The above will merge the remote “master” branch into the local “localBranch”.
Fetch is similar to pull, except it won’t do any merging.
[sourcecode language=“bash”] %> git checkout localBranch %> git fetch origin remoteBranch %> git branch master * localBranch remoteBranch [/sourcecode]
So, the fetch will have pulled down the remoteBranch and
put it into a local branch called “remoteBranch”. creates a local copy of a remote branch which you shouldn’t manipulate directly; instead create a proper local branch and work on that. ‘git checkout’ has a confusing feature though. If you ‘checkout’ a local copy of a remote branch, it creates a local copy and sets up a merge to it by default.
Git clone will clone a repo int a newly created directory. It’s useful for when you’re setting up your local doodah
[sourcecode language=“bash”] %> cd newfolder %> git clone firstname.lastname@example.org:whatever/something.git %> git branch * master remoteBranch [/sourcecode]
Git clone additionally creates a remote called ‘origin’ for the repo cloned from, sets up a local branch based on the remote’s active branch (generally master), and creates remote-tracking branches for all the branches in the repo
Finally, git rebase is pretty cool. Anything you’ve changed by committing to your current branch but are no in the upstream are saved to a temporary area, so your branch is the same as it was before you started your changes, IE, clean.
It then grabs the latest version of the branch from the remote If you do ‘git pull —rebase’, git will pull down the remote changes, rewind your local branch, then replays all your changes over the top of your current branch one by one, until you’re all up to date. Awesome huh?
If you get stuck, run ‘git branch -a’ and it will show you exactly what’s going on with your branches. You can see which are remotes and which are local. This is a good headsup before you start to break things! It’s worth remembering that git branches are basically just a pointer, so to be able to work with those commits you need a local branch which points to somewhere from which those commits are reachable.
Thanks to Ben for the extra stuff, clarifications and calling me an idiot when I get git wrong, because I am, as it’s really pretty simple, except for the simple.