Thursday, September 13, 2012

Experiments in rebase.

Thought I'd post this as a visual for anyone else getting their head around the difference between rebase and merge.

I created an project, and then created a series of commits to that project (by 'touch'ing a text file), across two branches, 'master' and 'branch':

- [master] touch readme1 'first commit to master'
- [master] touch readme2 'second commit to master'
- git checkout -b branch
- [branch] touch readme3 'first commit to rebase'
- [branch] touch readme4 'second commit to rebase'
- git checkout 'master'
- [master] touch readme5 'third commit to master'


At this point I had two diverged branches.

Running $ git log --oneline on [master] i have:

518f971 third commit to master
4a6d74b second commit to master
0f788ce first commit to master


on [branch] I have:

10e8078 second commit to branch
0122b8b first commit to branch
4a6d74b second commit to master
0f788ce first commit to master


I now copied the entire directory so that I have two versions of the project in exactly the same state, one of which I will rebase, the other I will merge.

Rebase

$ git checkout branch
$ git rebase master

7b9e782 second commit to branch
58f65f3 first commit to branch
518f971 third commit to master
4a6d74b second commit to master
0f788ce first commit to master




At this point, master is behind branch, but can be 'fast-forwarded' by merging:

$ git checkout master
$ git merge branch



Merge

$ git checkout master
$ git merge branch

a06b559 Merge branch 'branch' 

518f971 third commit to master 
10e8078 second commit to branch 
0122b8b first commit to branch 
4a6d74b second commit to master 
0f788ce first commit to master

This time you get an extra commit - which is the merge commit itself. This method preserves the exact history - i.e. the fact that development branched, and was then merged back in successfully. If this is important (and I'm definitely not in the 'always rebase' camp, then go with merge. Otherwise, rebase will give you a cleaner history. (NB like a supermodel, the better looking the history, the more deceptive the reality. You may prefer to preserve the history of branching.)



Tuesday, September 11, 2012

GitHub goes down, and everyone just carries on...

GitHub has been on & off all day today, and at first one would imagine that that would cause a gigantic PITA for developers, and that productivity in all places 'silicon' (valley, fen, glen, roundabout, savannah, desert, glacier,...) would plummet.

However, since GitHub uses git, and git is a DVCS, whilst users will have lost all the shiny unicorns that GH provides, they could, if their work really mattered, have simply pushed their repository to another hosted git service - like Codebase, BitBucket, Assembla, ..., and then carried on as normal. A little bit of coordination required to get teammates the new repo URL, and they'd be back online in minutes.

Or simply continued working locally, and committing, until GH gets back online. I've often done the reverse - I have private repos in BitBucket (free!) which I have periodically pushed to GH in order to take advantage of some of the branch visualisations.

Try doing that with TFS or SVN.