Git Workflow: The Case of the Lost Refactor

This has happened to me more than once, so I've been thinking about how to organise my branching and merging to allow for this scenario.

1. I get my ticket to do some new feature on the application I'm working on.
2. I create a feature branch, usually in the format of feature/(ticketNumber)-(title) (Yeah, we follow A successful Git branching model)
3. I think to myself "I've got some time to get this done, I'll take the opportunity to refactor this code so it's nicer, in the process of getting this new feature done" (Insert "Upgrade library/framework" here as well).
4. So I start refactoring, and continue on working on my new feature...
5. Until I get a: "Hey Mark, we have changing priorities/emergency/we have a better idea/never-mind, so backburner/kill/delay/switch to working on this totally new thing over here".
6. So I go off and start a whole new feature, and get that done instead.
7. Later on, I come to do something else in the area I was working in previously, and realise the refactoring work I was doing previously would be super useful. However all of it is tied in with other half finished code in my previous feature branch. That sucks, because it would make what I'm working on a million times easier.

I call it the "Lost Refactor", and it drives me nuts, as you know you could be working on better code, but it's all attached to other code that you would have to manually pull apart.

So what do you do? I have two thoughts on the matter:

1. Separate the refactoring into a separate ticket, and build a separate feature branch for it.
2. Create a refactor/(ticketNumber)-(title) branch, specifically for the refactoring work, and merge that into my feature branch.
3. Make sure my commits are clean enough so that I can cherry pick out which ones are pure refactor, and which ones are the partial implementations of the new feature.

I've yet to try out option #2, but it seems to me that that would be the best approach.

Technically you could claim that the refactoring would be a totally separate ticket - but that seems like more trouble than it's worth from a pragmatic standpoint. However, the refactoring is a separate effort than the ticket, which means it's nice to split off to it's own branch, in case you want to integrate that work separately. Having the refactor/ branch be the same as the feature/ branch name, it also gives you a really good idea of what the original impetus for the refactoring came from.

Option #3 is not a bad one - and probably the easiest from the development workflow (not having to switch branches around), but the idea of cherry picking commits makes me shudder a bit. I guess it depends how often you end up in a "lost refactor" type scenario, that if it was rare enough, doing the occasional cherry pick is not the end of the world.

What does everyone else do? Do you find yourself in this situation often? What approach do you take?

ColdSpring 2 is available on GitHub

This is something I did a while ago, but for whatever reason, totally forgot to announce publicly.

Thanks to the power of distributed version control, there is a copy of the Git repository for ColdSpring 2 on Sourceforge, as well as one on GitHub.

It goes without saying that GitHub really is the best place for Open Source projects to manage and allow for collaboration with other developers, so it makes sense to have a copy of ColdSpring 2 on GitHub as well.

So get your forks ready, and make some pull requests! :)

Fun with Decentralised Version Control

One thing Windows does better than Ubuntu on my Alienware M17x is allow me to use the low power mode on the laptop, which is perfect when flying.

Once I had set up a simple development environment on my Windows partition, I needed a way to be able to work on my Coldfusion code, but not lose any of my source control history. This is where the power of Git became so very useful.

Since each Git local repository is a full Git repository in it's own right, and any Git repository can pull from any Git repository, I did the following:

While in Ubuntu, plugged in my USB key stick

1. Opened up a terminal at my usb stick
2. Cloned my local git repository to the USB Stick
   git clone /home/mark/wwwroot/coldspring ./
3. Rebooted into Windows
4. Opened a Cygwin terminal (Yeah, I use Cygwin in Windows, as I hate the Windows terminal)
5. Cloned the repository on my USB stick to my C: drive
   git clone /cygdrive/g/coldspring ./

I probably could have made this pathway shorter, but I wanted a way to backup to an external device in case something went horribly wrong with the RAID1 hard drives in my laptop.  However, I now had a copy of my Git repository in my Windows partition, ready to use, with my full repository commit history.

Once I had got off the plane, and got back to doing work on my Ubuntu partition again, I needed  to move the commits in the repository in my Windows partition back to my Ubuntu partition.

This is now very easy, again, due to the distributed nature of Git, and the fact that any repository can pull from any repository. To return all my commit history to my Ubuntu partition, where I do my main development, I did the following:

1. Log into my Windows partition
   
2. Go to the repository on my flash drive, and pull from the Git repository on my windows hard drive.
   git pull /cygdrive/c/wwwroot/coldspring
3. Boot back into my Ubuntu partition
4. Open a terminal in my source folder for Coldspring 2, and pull from the Git repository on my Flash Drive (/media/corsair).
   git pull /media/corsair
5. Voila - my commit history is intact, and all the changes I made on my Windows partition are on my Ubuntu partition.
   

That's just how amazingly flexible Git is.  Try and do that on SVN with no Internet connection ;o)