“How To Speed Up The Code Review” is a collection of excellent tips and strategies on how to make your Pull Requests easier to review. These work equally well for Open Source projects and for proprietary repositories.
The gist of this article is: don’t make large pull requests, and don’t mix different types of changes within the same pull request. Read the whole thing for suggestions on how to actually do that.
Here are some exciting news from GitHub – an introduction of the Draft Pull Requests. I think this is a very welcome addition to GitHub features.
At work, we’ve been using a work around to solve the problem – a [WIP] prefix in the title of the pull request, which means that this is “Work In Progress” and the PR shouldn’t be merged.
While the prefix does help, it’s not as good as the new Draft Pull Requests. Somebody can still merge a [WIP] pull request by mistake. But with Draft Pull Requests, merging is blocked, until the developer indicates otherwise.
Great stuff!
I have only recently discovered the concept of monorepos. It does sound interesting and I am yet to try it out, or, at least, dig deeper into the subject. But then, there are people who have strong opinions against them, and I the reasoning makes all the sense to me. Here’s a nice one: Monorepos: Please don’t!
If you are spending a lot of time on GitHub, following people, teams, and projects, then checkout DevHub – a TweetDeck-like application for GitHub that works on Android, iOS, and as a web application.
It conveniently brings together your repositories, notifications, and all the other goodies, helping you to significantly cut down the time and mouse clicks.
The evolution goes on. Now that we’ve kind of sorted out most of our infrastructure, development tools, flows and processes, I guess, it’s time to look deeper into the things we’ve had for a while and reiterate over them.
Recently, I’m seeing a lot of blog posts on articles on how to write good commit messages. Sure, we’ve had these for a while. But lately things get a little bit more serious.
Here’s one (in Russian) that I’ve read recently. Here’s another one (in English) that shares some of the concepts and suggestions.
What are they saying? Well, “write better commit messages”, obviously. But there are a couple of specific bits which I found interesting. They are:
For the skeptics among you, I slightly share your feeling. It does seem like a bit too much overhead. But as someone who works with an ever-growing team on a large number of projects, I think there is a place for it. It’ll take a while to integrate, update the process, and enforce the discipline, but I think it’s well worth it. At the very least, it deserves a try.