March 2010
8 posts
7 tags
Updating all remotes at once.
Just a quick one.
Say you have a repository with many remotes. Don’t roll your eyes; it’s very likely if you have many collaborators, or if you’re tracking a popular open source project. To pull down all available changes at once try this:
git fetch --all
No surprise about what it does.
Of course, this is a fetch, not a pull, which is a combination of git fetch and git merge, so after this...
6 tags
Branching out
Branching in git is fast and easy. Coupled with fast merging, and rebasing, it is very convenient to always work on a separate branch. Typically, you create a branch, make changes to your project on that branch, merge this working branch with one of the permanent branches and delete the temporary branch.
Let’s take an example. Assume you have a repository with a single branch; master with a few...
6 tags
Simple history
There are times when you just want to have a quick look at the history of what you’ve been working on. You could use git log but that shows you the full history with the details for each commit. Not exactly helpful if you just want a summary or only details for the last few commits. Try:
git log --oneline
This will just show you the short sha for each commit and the subject line of the...
4 tags
Cleaning up your files
The clocks have gone forward in the UK today, so here’s a spring cleaning tip for the files in your project. This is not tidying up the repository itself, that’s different, but the files that Git doesn’t track.
The command that I use:
git clean -dxf
The man file for git-clean is quite small, so have a look at it. -d means directories will be removed, -x removes all untracked and ignored...
5 tags
Break from your origins.
When you clone a repository, the remote is given the name origin by default. But you don’t have to accept this.
Git is a distributed version control system, so in most cases there isn’t a canonical repository. This might be confusing, but with a little thought it makes sense, and I’ll cover it some other day. I consider my repositories to be versioned backups as well as a source control...
6 tags
What’s the difference? Part 1
This is one that used to catch me out when I first started using Git. I’d make some changes, add things to the index and then try and get a diff by calling git diff and nothing would come up.
Of course, git wants to know what I want a diff between. If you remember yesterday’s post about the buckets there are three types of diff that you can get.
If you’re new to git you may be asking...
8 tags
The four buckets — how Git considers content.
A slightly longer post today but it’s important that the basics of git are covered.
My first suggestion is to think of git as tracking content, not files. In the coming days I’ll cover the way that Git stores information and this should become a lot clearer. But it helps to realise that the contents of a file and the name of that file are not kept in the same place. Secondly, Git only tracks...
4 tags
Amending your last commit
A nice simple one to start with, and protects against those idiot moments when you check something in that you didn’t want to.
Say you’ve just made a commit to your repository and you think “oops! I didn’t want to do that”. Well, you can change your last commit quite simply.
Make whatever changes to your code that need to be made, add the changes to your index and then simply type this...
