As I prepare for the OSCON workshop, Git for Teams of One or More, I've been collecting resources over on bit.ly. Unfortunately bit.ly doesn't seem to have a way to organize a bundle of links into categories. The resources I added more-or-less fall into the following categories:

• Mega learning resources
• Cheat sheets and quick references
• Workflow - 10,000ft view
• Workflow - applied
• Merge vs. Rebase Workflow
• Team Governance
• Commit Messsages - standards and granularity
• Visualizing Git

Although this is a topic I've been teaching for years, I still take the time to re-evaluate the structure of the material each time I teach the topic. The most recent iteration worked well for managers, but it lacked some of the hands-on examples which developers might have benefited from (the one-hour session didn't give room for both).

As I continue to read how others have presented the information, I continue to see the strengths (and weaknesses) of how we teach workflow and source control. Two of the articles on the size of a commit were especially interesting in thinking about source control from the perspective of "teams of one or more". The first article outlines the importance of a clean history which is easy to inspect and analyze. The second article talks about some of the tools that are used, such as git bisect, when identifying where a problem was introduced.

I think this distinction is interesting because (again, my opinion here) a very tiny team is more likely to identify a bug and move forward to fix the bug; but a larger team, with more senior developers, is more likely to investigate how / why a regression was introduced. (Have I mentioned this is purely speculation on my part?) Is this also the difference between a project which is using tests / test driven development vs. one that is not ("test later" / cowboy coding)? Or perhaps the difference between a team which is motiviated by Lean best practices and is motivated to uncover and fix the root problem by asking the question why.

And so, at the end of all of my reading and thinking today, I'm leaving myself with the question: how do we balance between ease-of-use now and tools to help future me debug a project? It sort of reminds me of a comment made in a devops presentation: if you aren't going to use the logs to improve your efficiencies, why are you bothering to track the information in the first place. Indeed, it's a delicate balance and one where the solution becomes more obvious with experience.