One of the most powerful features of git is that it gives you the ability to alter the commit history of your repository. This way I can have the best of both worlds by committing often during feature development, but then being able to consolidate all of the commits into a single “unit of work” when the feature is complete. In the case where no new commits have been made to the master branch, the feature branch can be combined into a single commit with:
git checkout master
git merge feature-branch --squash
One of the sessions I attended at That Conference was the “Understanding Git Part-2” talk by Keith Dahlby. I have worked with git and github a lot over the last 5 years, but I learned quite a bit from this talk. In this post, I will highlight some of the most useful takeaways.
Until recently we used Microsoft TFS for all of our source control. It worked well enough for small, simple projects where all that was necessary was basic check in/check out functionality.
As our business grew, we started running into limitations with TFS. We found that our clients for the larger projects would request new features that would take multiple months to complete, but still have smaller spot-changes for the project as those features were being worked on. In a standard source control system, branching allows you to work on a feature while the existing codebase is still available for modifications, but in TFS when those branches needed to be merged back together it usually ended up being a massive headache.