On Git’ing It
The Ship Show‘s current episode tackles a topic near and dear to my heart: Git and, for our purposes, its (non-open source project) usages.
The seed for this episode’s topic came up when the podcast crew was discussing whether or not release engineers, and by extension ops/tools/automation engineers, should have intricate knowledge of the version control tool they’re supporting in their positions. Because this is more and more commonly Git these days, the seed-question naturally drifted to “Does everyone on your team have to have a more complex knowledge of Git?”
What makes Git different from other version control tools it it puts the power to destroy the repository1 in the hands of every developer. (Some may point out you can disable these on the server side; and they’re right. Unfortunately, Github does not allow you to do this in their hosted product, so in the common case, that doesn’t much matter2.) And, given that, “with great power, comes great responsibility,” so the saying goes… but are all developers equipped3 to handle that responsibility?
Even if you’re not using Git, the question about version control proficiency remains. One of the things I’ve always done at any shop I’ve worked at is work to understand the intricacies of the version control tool’s versioning model and how it understands the world that we put into it.
This is key to being able to make coherent recommendations about code-line policies, merging strategies, and general repository administration, which is a large part of the release engineering functional role.
Despite this, I’ve worked with many release engineers who don’t really understand what’s going on under the covers, and have only a basic understanding of the tool. Because of Git’s complexities and sometimes confusing “porcelain”4, this is a very real problem facing a lot of release and ops engineers.
Is it something we should be concerned with?
Well… listen to the episode… and tell me what you think.
(As an aside: this episode’s musical interstitials turned out to be among my favorite thus far; kudos to everyone who caught what they are. If you don’t like them, don’t blame me!)
_______________
1 Referring to force-pushes, mostly↵
2 I still don’t understand why they don’t allow that; Bitbucket does; is it a feature-differentiation thing? Do they assume that pull requests protect the repository-of-record from this behavior?↵
3 Via proper training, etc.↵
4 The fact that the Git community insists on making the distinction between “porcelain” and “plumbing” is part of the problem, me thinks↵