I’ve discovered that my blog is actually a good place to put things I need to remember see, for example, my blog post on running Ubuntu in a VM on Windows 8.
In this spirit here are my notes on using git, the distributed version control system (DVCS). These are things I picked up around the office at ScraperWiki, I wrote something there about the scheme we use for Git. This is more a compendium of useful git commands.
I use Git on both Windows and Ubuntu and I have accounts with both GitHub and Bitbucket. I’ve configured ssh on my Windows and Ubuntu machines and use that for authentication. I Windows I interact with Git using Git Bash.
Installation
On installing Git I do the following setup, obviously using my own name and email:
git config --global user.name "John Doe"
git config --global user.email [email protected]
git config --global core.editor vim
I can list my config settings using:
git config -l
Starting a repo
To start a new repo we do:
git init
These days I feel bereft if I’m not “pushing” my local repository to an online repository like GitHub or BitBucket. To add a remote repository create one using the service of your choice which will probably ask you to do:
git remote add origin [url]
Alternatively you can clone an existing repository into a subdirectory of your current directory with the name of the repo:
git clone [url]
This one clones into current directory, making a mess if that’s not what you intended!
git clone [url] .
A variant, if you are using a repo with submodules in it, :
git clone –recursive [url]
If you forgot to do the above on first cloning then you can do:
git submodule update –init
Adding and committing files
If you’ve started a new repository then need to add some files to track:
git add [filename]
You don’t have to commit all the changes you made since the last commit, you can select them using the -p option
git add –p
And commit them to the repository with a commit command like:
git commit –m [message]
Alternatively you can add the commit message in your favoured editor with the difference from previous commit shown below:
git commit –a –v
I tend to use an remote repository as a backup so I regularly do:
git push origin HEAD
If someone else is working on the same repository as you then things get more complicated but that’s out of the scope of this post.
Undoing things
If you get your commit message wrong you can edit it with:
git commit --amend
If you decide you change your mind about staging a file for commit:
git reset HEAD [filename]
If you change your mind about the modifications you have made to a file since the last commit then you can revert to the last commit using this **destructive** command:
git checkout -- [filename]
You should be careful doing that since it will obliterate any changes you’ve made to a file, even if you saved them from the editor.
Working out where you are
You can list files in the repo with:
git ls-tree --full-tree -r HEAD
The general command for seeing what is going on is:
git status
This tells you if you have made edits which have not been staged, which branch you are on and files which are not being tracked. Whilst you are working you can see the difference from the previous commit using:
git diff
If you’ve already added files to commit then you need to do:
git diff –cached
You can see a list of all your changes using:
git log
This command gives you more information, in a more compact form:
git log --oneline --graph --decorate
is a good way of seeing the status of your branch and the other branches in the repository. I have aliased this log set of options as:
git lg
To do this I added the following to my ~/.gitconfig file:
[alias] lg = log --oneline --graph --decorate
Once you’ve commited a bunch of changes you might want to push them to a remote server. This pushes to the remote called origin, and HEAD ensures you push to your current branch. HEAD is Git’s shorthand for the latest commit on the current branch:
git push origin HEAD
Branches
The proceeding commands are how you’d work using a single master branch, if you were working alone on something simple, for example. If you are working with other people or on something more complicated then you probably want to work on a branch, you can make a new branch by doing:
git checkout –b [branch name]
You can find out what other branches are available by doing:
git branch –v -a
Once you are on a branch you can commit changes, and push them onto your remote server, just as if you were on the master branch.
Merging and rebasing
The excitement comes when you want to merge your changes onto the master branch or you want to get changes on your own branch made by someone else and pushed to the remote reposition. The quick and dirty way to do this is using
git pull
This does a fetch and merge all at the same time. The better way is to fetch the changes and then merge them:
git fetch –prune –all
git merge origin/master
If you are working with someone else then you may prefer to merge changes onto the master branch by making a pull request on GitHub or BitBucket.
Accepting Pull Requests from Forks
If someone makes a Pull Request based on their forked copy of a repo then you can download for testing by doing:
git fetch origin pull/ID/head:BRANCHNAME
