I used RCS, CVS and SVN in the past, so I am not new to version control. GIT is a bit different from them, by the way, and is new to me, so I need to write down things before I learn them by earth. I am publishing my notes in the hope it will be useful to you, as well. Also, feel free to comment if you’d like to suggest better ways to do the same things.
I am writing things as I use them, so beware this post will still change several times in the future. I hope this doesn’t drive your RSS reader nuts…
(Updated: September 15th, 2014: revert last commit, get a branch/tag’s commit ID)
(Updated: September 7th, 2012: make a local branch remote, check out a file from another branch)
Updated: April 3rd, 2012: new repo with gitolite in the middle)
(Updated: March 14th, 2011: git remote prune)
(Updated: January 27th, 2011)
(Updated: many other times…) …
To create a branch remotely and track it locally
…which basically means that you create a remote branch that you can easily synchronize with locally afterwards:
Create the branch remotely:
git push origin origin:refs/heads/sync-fixes
Now you created the branch remotely, but you still don’t see it locally: update your local archive of objects and refs:
git fetch origin
Now create the local branch and put it in sync with the remote one:
git checkout --track -b sync-fixes origin/sync-fixes
Now you have a local branch called sync-fixes that tracks a remote one with the same name. Cool, uh?
To merge changes in the master into a development branch
Switch to the branch:
git checkout testenv-start
git merge --no-commit --no-ff origin
If everything is OK, you can now explicitly commit by hand:
To merge changes from a development branch into the master
Switch to the branch:
git checkout master
git merge --no-commit testenv-start
To be extra sure not to wipe off good stuff, I use to clone the repository in a new directory, and do the merge there. That is: you cd in a new directory and:
git clone your:repo.git
Then, cd into the repo directory: you are in the master branch and it’s the only one you currently see:
$ git branch * master
But if you add a “-a” to the command, you’ll see everything:
$ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/fixes-bronto-20100715 remotes/origin/master
So, all you need before starting the merge is to create the branch locally:
$ git checkout -b fixes remotes/origin/fixes-bronto-20100715 Branch fixes set up to track remote branch fixes-bronto-20100715 from origin. Switched to a new branch 'fixes' $ git branch * fixes master
See the branch was checked out, and switched to it.
To delete a branch once you are done with it
Once you have finished working on a branch and merged it into the master, you can delete the remote branch, both remotely and locally. This will do the trick:
Be sure to switch to the master branch:
git checkout master
Check how the branch is named remotely:
git branch -r
In my specific case, this returned:
bronto@brabham:/puppet$ git branch -r origin/HEAD -> origin/master origin/master origin/sync-fixes
Now delete the remote branch:
git branch -r -d origin/sync-fixes
This returns something like:
bronto@brabham:/puppet$ git branch -r -d origin/sync-fixes Deleted remote branch origin/sync-fixes (was 9e1a241).
Now you can delete the branch locally:
git branch -d sync-fixes
This returns something like:
bronto@brabham:/puppet$ git branch -d sync-fixes Deleted branch sync-fixes (was 9e1a241).
(notice how both the remote and the local branch had the same hash)
Now wipe it away forever from the remote repo:
git push origin :sync-fixes
How to revert changes
It will happen sometimes, you do a few changes, a few commits and a few pushes, and then you find that what you wrote is just crap. How to go back to the last known godd commit?
The first thing is to get the “commit ID” of the good one. You can use
git log on the command line, or retrieve it via a GUI like
gitk. Whatever you choose is OK.
Let’s say you found the ID is
7f25d102340f3d49f086c4fe5d357e7272063915. Now you run:
git reset --hard 7f25d102340f3d49f086c4fe5d357e7272063915
and it will take you back to the situation when you issued that commit. You’ll have a confirmation message back from the command:
HEAD is now at 7f25d10 Small typo, fixed
that is: “HEAD is now at “, plus the first bytes of the ID, and the commit header. You could also issue a
git status and see that you are behind by a number of commits.
Now if you want to push everything back to the central repository, you can’t just use a plain push. If you try, you’ll get an error message, like this:
$ git push To gitolite:puppet.git ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'gitolite:puppet.git'
To make it work, you need to force it:
$ git push --force Total 0 (delta 0), reused 0 (delta 0) To gitolite:puppet.git + 1070ed3...7f25d10 master -> master (forced update)
That’s all. You now reverted your changes on both your local copy and the remote repository.
Cloning and updating a repo via SSH
I tried this one today for the first time. I have a repository in a directory in my workstation in the office. Today I was working from home and I wanted to do some more development. So I tried this for the first time:
git clone ssh://brabham/home/bronto/devel
This cloned the currently checked out branch locally, and set up references to the other ones:
bronto@cooper:~/Lab/devel$ git branch * dev-aggr bronto@cooper:~/Lab/devel$ git branch -a * dev-aggr remotes/origin/HEAD -> origin/dev-aggr remotes/origin/dev remotes/origin/dev-aggr remotes/origin/dev-mmc remotes/origin/master
Now I could start some development locally, but the first time I tried to push I was warned I couldn’t: it is normally not allowed to push stuff when the remote checked out branch is the same that is being pushed. Dah, no problem: went to the office workstation and typed
git checkout master
Now I could… but got a warning message, like this:
warning: You did not specify any refspecs to push, and the current remote warning: has not configured any push refspecs. The default action in this warning: case is to push all matching refspecs, that is, all branches warning: that exist both locally and remotely will be updated. This may warning: not necessarily be what you want to happen. warning: warning: You can specify what action you want to take in this case, and warning: avoid seeing this message again, by configuring 'push.default' to: warning: 'nothing' : Do not push anything warning: 'matching' : Push all matching branches (default) warning: 'tracking' : Push the current branch to whatever it is tracking warning: 'current' : Push the current branch
Again, no problem:
git config push.default current
And that’s basically it. Now I could develop on my laptop and have my stuff synced to the development branch on my office workstation.
Wiping away stale remote branches
branches may be added and removed on a remote repository, but they’re not deleted from your local copy. To get rid of the stale ones you just need a single command:
git remote prune [-n | --dry-run] name, where name is the string that follows remote/ when you do a
git branch -a. E.g., in my case I had:
puppetrepo:/puppet# git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/something remotes/origin/something-more remotes/origin/something-else ...
To get rid of the stale ones it was enough to:
git remote prune origin
It’s all there is to it! If, for any reason, you want to visually check what’s going to happen before actually issuing the command, just add a
Creating a new repository (with gitolite)
When you use gitolite, he takes it upon itself to create a new repository for you: if you mention a new repository in gitolite.conf and commit/push the change, the new empty repository is automatically created. What puzzled me was that I couldn’t add files into the repository and received some weird errors like:
No refs in common and none specified; doing nothing.
It took some time and research to find out that the solution is a simple
git push origin master
for the first push
Make a local branch remote
If you have a local-only branch and you want to make it remote, you’ll have to run something similar to:
git push <remote-name> <branch-name>
git push origin mylocalbranch
Check out a file from another branch
git checkout <branch> -- <file>
git checkout mybranch -- hosts.cf
Works on remote branches, too:
git checkout remotes/origin/mybranch -- hosts.cf
Revert a commit
This case is similar to something you’ve seen above, but you’re lucky enough that you haven’t pushed anything to a remote repository. Say you have committed some code in the wrong branch and you want to… uhm… un-commit the change so that you can re-commit it in the right branch. If you haven’t pushed the changes to a remote repository, then it’s absolutely painless: in the branch you committed the wrong code do:
git reset HEAD~1
At this point a
git status will show that the files are again ready to be uncommitted. It’s enough to checkout the right branch and redo the commit there.
If you have also pushed the code then you are a bit more in trouble, as doing like this and trying to re-push may result in a non-fast-forward change that may be a risky business if you aren’t the only one using the repository. In that case you may try and use
git revert, then check-out the right branch and “hand pick” the files you modified by using
git checkout branchID -- files...
Obtain the commit ID associated to a branch or tag
git rev-parse branch_or_tag_ID