When you first started with git, you quickly got up to speed with committing, pushing, pulling, merging, and the like. But then you noticed a gaping hole in your knowledge - how do you find stuff in Git? Can you revert to a version of a file as it stood three weeks ago, or find out when a bug was introduced? Who was the last person to edit this file?
They always tell you that the great thing about Git is that you [almost] never lose any history. So how do you access and utilize that history?
Sometimes new developers ask me, “So, what’s the best laptop for a programmer?” It’s an important question. As a “software crafts(wo)?man”, your computer isn’t just your tool belt - it’s your pickup truck, miter saw, lathe, awl, bulldozer - all rolled into one. You need a reliable and performant machine that empowers you while staying out of your way as much as possible. It’s an important question, but the answer no doubt reminds you of a certain brand of adult diaper - It depends...
You’re a programmer, software craftsman, full-stack developer, software engineer. But regardless of the titles dangling from your Twitter bio, if you want to greatly improve the quality of your code and indeed the quality of your life, there’s one more title you should consider tacking on there: “Runner”…
These days it’s hard to tell whether the computer saves us more time than it wastes. However recently I had an experience programming in Ruby that demonstrated to me that the computer can be our modern time-saving friend, especially when wielding a language like Ruby, delicately designed to just “get out of your way” and let you program. The story involves number crunching, eyebrow scrunching, and in the end, an unabashed brute-force beauty.
OpenCover analyzes your .NET codebase and generates an XML report rich with detail about the extent and quality of your code coverage. You think you’ve covered your testing bases, but how do you know? What if there’s actually a sneaky runner leading off second base? If so, OpenCover will blow his cover wide open. In this post I will show you how to retrofit your automated build with OpenCover. Then we’ll make the output more human-readable with Report Generator.
If you read my article about Psake, you’ll recall that I started the open source project Resfit in order to experiment with Acceptance Test Driven Development. I started the project with NCrunch and though the 30 day trial ran out, my appreciation for NCrunch’s coverage metrics did not. I found OpenCover, which generates some amazing code coverage metrics. Only trouble is, they’re all in XML - Better suited to be read by a build server than a lowly Developer like myself. That’s where ReportGenerator comes in, which “converts XML reports generated by OpenCover, PartCover, Visual Studio or NCover into human readable reports in various formats”.
It was early one weekend morning and I was trying to integrate AppVeyor with my GitHub project. But there was one problem: my build was failing miserably on AppVeyor. Strangely, it built just fine on my machine; but on AppVeyor the test
ToStringShouldReturnResourceKey was failing a string comparison.
Investigating the failure
Fortunately I was using Shouldly, which produces very readable test output when your tests fail. See what you notice in the snippet below.
What are Git hooks? Can you do anything useful with them? Also, since Git hooks come from Linux, is there anything special you need to do to get them working on Windows?
What are Git hooks?
Git hooks allow you to run custom scripts whenever certain important events occur in the Git life-cycle, such as committing, merging, and pushing. Git ships with a number of sample hook scripts in the
repo\.git\hooks directory, but they are disabled by default. For instance, if you open that folder you’ll find a file called
pre-commit.sample. To enable it, just rename it to
pre-commit by removing the
.sample extension and make the script executable (
chmod +x pre-commit if you’re on Linux, or just check your NTFS execute rights if you’re on Windows). When you attempt to commit using
git commit, the script is found and executed. If your pre-commit script exits with a 0 (zero), you commit successfully, otherwise the commit fails.
If you take a look at the default sample pre-commit script, it does a few helpful things by default, like disallowing non-ascii filenames since they cause issues on some platforms, and checking for whitespace errors. This means that if you enable this script and have “whitespace errors”, like lines that end in spaces or tabs, you’ll fail to commit and have to remove the whitespace before you can commit.
What cool stuff can I do with Git hooks?
Since you’re working with scripts, you can do pretty much anything with Git hooks. That being said, just because you can do something… Yeah, you know. Git hooks can make the behavior of common Git tasks like committing, pushing and pulling nonstandard, which can annoy people, especially if they’re just trying to get used to the glories of Git. But here are a few examples of what you might accomplish with Git hooks.