A rule you have to remember will be forgotten sooner or later: on a Friday evening, under time pressure, for “just a small fix”. A rule the tool enforces always applies. In this lesson you let GitHub enforce the Kladde’s most important rules: only what has been opened as a pull request, read by a second person and confirmed by the tests gets onto main. Before that, we deal with what no tool can enforce: pull requests people enjoy reading.

Small, and each one green on its own

From lesson 1.7.4 you know the rule: one pull request, one thing, readable in a quarter of an hour. In K2 the changes get bigger, because a feature reaches through page, API and database. That makes slicing all the more important. Three habits help:

  • Refactor first, then build. If a feature needs a refactoring, say a method in a different place or a new name, the refactoring comes first as a pull request of its own. It changes no behavior, and the tests stay as they are. That’s quick to check. The second pull request then brings only the new part.
  • Every pull request is green on its own. After every merge, main builds, all tests pass, and the Kladde can be started. A half-finished feature may already be in the code, as long as nobody can reach it, for example a page that no menu links to yet.
  • One after the other, not side by side. Two open branches that change the same file end in a conflict (lesson 1.7.5). So the second branch only branches off once the first one is in main.

As a rule of thumb, the quarter of an hour from K1 still applies. In lines that’s rarely more than a few hundred, tests included. If it gets more, it’s worth asking whether the pull request can be split. There are exceptions, such as a file a tool generated. Then the description says which parts to read and which not.