In the fable of Hansel and Gretel, we hear the story of two children lost in the woods and the unfortunate circumstances that befouled them. An important part of the story is that they were initially safe as they followed the trail of stones that they left.  Later in the story, the two children used bread and the birds ate the trail of breadcrumbs.  The outcome was grim for the Witch in the gingerbread house but there was a different point that I would like to discuss.  Do you put breadcrumbs in your code?

As many of my stories go, we find our protagonist sitting in his chair with his face firmly planted in his palms.  Tears are streaming down his face and his fingers are cramping.  You may ask why such a dire portrait of a broken developer.  I have been this fellow many times.  Two days ago, I even slipped into my old habit of ‘just one more function and then I will commit’.  I ended up spending almost 4hrs backtracking everything that I had changed because I realized that I kept introducing bugs.  You see, I created an earlier method that was unstable even though it passed my tests.  Refactoring the method was the only option but I had not committed anything all day.

For the past few years, I have started leveraging Git more and more in my projects.  I could have saved a lot of my hair had I leveraged repositories and source-code control.  You must have guessed by now that my youth was full of a ‘run-and-gun’ view on development.  I learned a very hard lesson that ‘I don’t have time to waste on project planning’ isn’t always the right response.  I have lost too many hours over the years chasing down bugs or rewriting code because something happened to my local copy of code.

When it comes to creating your own breadcrumbs, here is what I would suggest:

• Leverage Git or something similar: I am a big fan of Git and use it for all of my projects including the rinky-dinky scripts. There are a plethora of tools available and it is very easy to get started.
• New Feature? New Branch!: This is my golden rule and I thought it was pretty common.  Recently, I have seen too many repositories that contain one branch – Master.  The benefit that I find to feature branches is simple.  I can work on any feature that I want without worrying about breaking the history of my repo.  I also can work on a specific branch and merge with master when it is ready.  Remember, an Agile software release means at the end of a sprint you have a shippable product.
  
• Branch often:  Recently, I have started to create sub-branches in my feature branch.  There are times that I am writing scratch code but need to keep it in more than a git stash.  I even sometimes will split the branch when I realize that what I am about to do in the next series of steps will likely break or wreak havoc on what I have done so far.  A simple way to handle this is to create a new branch named something like _recycle/<feature>_<rev>. Remember our earlier post about styling?  In this case, I know at a glance that any branch with an ‘_’ should never be pushed to origin as it is intended to be a local branch.  Local branches make life so much easier.  Often times, I will leverage git checkout to reset a single file when I goof up something.
  
• Descriptive commit messages will save you time: I do 99% of my git work in iTerm but there is one thing that I use SourceTree to manage – my commits.  I like the fact that I can do a git diff right in the UI and can quickly see the changes.  The fact that I have this information means that I can quickly add it to my commit message in a multi-line format.  Now each commit has all the details about my changes.  The benefit to me and anyone else is that it is easier to see where and when a bug or change might be introduced.
• Git Stash – The emergency save button: I use this one often.  Imagine that you are working on a feature and the boss calls and would like to stop by for a demo.  Since I only commit once my tests pass, I know that my earlier commit is ready to go to that point.  Stash is perfect for those types of things and likely how you have used it.  I leverage it in another way.  Pushing code from one branch to another becomes a breeze with this little trick.

There are many different tips and tricks in using Git.  The point is to start using the tools to make your life easier and to build a solid foundation.  The benefit to you is fewer panicked moments when the laptop crashes and everything dives deep into the bowels of the earth.  Personally, the list that I shared are a few of my current productivity solutions and have greatly helped me.