Category Archives: Source Control

by

Become a Git contortionist with Stash

Annie the ContortionistOne of the great aspects of the Git source control system is its flexibility. Almost any sticky situation you may encounter as a developer working with source control can be  solved with Git.

Take this scenario, you’re halfway through writing a class for a new feature when you get a call.. the client has found a show stopping bug in the application and it needs to be fixed right away. To be able to fix the bug you will need to switch onto the live code branch but you can’t go switching branches with a load of uncommitted changes. Now you don’t want to commit your code as its half done and won’t even compile right now, but you don’t want to lose the changes either… git stash to the rescue!

When you issue the git stash command all your changes will be committed to a stack. Leaving you with no changes on your current working branch and free to branch where ever you want. So now you can switch to the live branch and do your bug fixing work. Once that is done you can simply move back to the feature branch and apply the stashed changes. Hey presto, you are back where you started with your uncommitted half complete work!

If you really get into lots of parallel work you can stash multiple times, just be sure to remember that it is a stack and your last changes you have stashed will come back off stack first.

by

The beauty of cherry pick

I’m loving the cherry pick command in git right now, this is the scenario that it really helps me out for.

I’ve fixed a bug on the live branch, however before it can be published to the live website it needs to be tested. So I can first publish it to our UAT (user acceptance testing) site so the client can test the changes. However the UAT site already has a bunch of other unreleased features on it. If I merge my bug fix branch into the UAT branch it will overwrite some of the other feature changes.

The solution here is to ‘cherry pick’ just my changes from my bug fix branch and commit those to the UAT branch. In this way git doesn’t merge all the other differences between the live and UAT branch.

by

Branching the Project

I have used an SVN repository for the project, hosted on unfuddle, enabling versioned source control on all files in the project. I can use the trusty TortoiseSVN Windows application to send and receive files to the remote repository directly from Windows Explorer. After each work session I commit the changes to source control. Apart from the obvious advantages of maintaining backups, if at any stage I realise that I have made a mistake, then the changes can be rolled back to the previous commit.
The source control recently came in useful when I needed to upgrade the version of Sharp Architecture used on the project. I won’t go into detail about the reasons for me upgrading, suffice to say most of the technology stack in Sharp Architecture had benefitted from version updates and I was limiting myself by using a pre version 1.0 release.
These are the steps I took to upgrade the Sharp Architecture version of the project:

  1. Use TortoiseSVN to Branch the code in source control from /trunk to /branches/recipebookV1
  2. Rename the working folder (ie. the local folder in Windows Explorer) to recipebookV1 and switch it to the branch.
  3. Update the Sharp Architecture project to fetch v1.0 from source control and copy the new project template into the Visual Studio templates folder.
  4. Generate a new Visual Studio project, named recipebook, from the v1.0 Sharp Architecture templates.
  5. Use Beyond Compare to copy all the files that I have manually added / changed in the recipebookV1 project to the new recipebook project
  6. Add the files to the recipebook project in Visual Studio, cross fingers, compile and run!
  7. Use the TortoiseSVN repo browser to delete all files from the Trunk… yes, I really deleted them all!
  8. Import the new recipebook folder back into the trunk

After completing the upgrade I realised that there may be an easier way to upgrade, without the scary and somewhat bad practice of deleting all the old files from the trunk, only to upload most of them again. I will list them below so I can try them out later:

  1. Use TortoiseSVN to Branch the code in source control from /trunk to /branches/recipebookV1
  2. Rename the working folder (ie. the local folder in Windows Explorer) to recipebookN. This enables a new visual studio project of the same name to be created, with namespaces which are the same as the working project.
  3. Update the Sharp Architecture project to fetch v1.0 from source control and copy the new project template into the Visual Studio templates folder.
  4. Generate a new Visual Studio project named recipebook from the V1.0 Sharp Architecture templates.
  5. Use Beyond Compare to copy all updated Sharp Architecture files from the new recipebook project to the working recipebookn folder
  6. Add any extra files to the working recipebook project in Visual Studio, cross fingers, compile and run!
  7. Commit the changes to the trunk, remove the new recipebook project and rename the existing recipebook project folder to recipebook.