DevOps is (are?) cool.

The foundation of devops is version control. And the foundation of version control is git.

Learning how to use git and how to utilize a version control server (like GitHub) made me a better developer.

Here's a less than thorough guide on commits, pull requests, and how many of each to write per feature.

~~

Authoring a git commit is as personal an endeavor as deciding the name of your firstborn child.

Other than the most difficult part of actually coming up with a name (knowing what to write for the title and—optional but not so optional—body) you first have to decide if you'll go with a classy, timeless name like Francesca (use cold and corporate "conventional commits") or something modern and cute like Phoenix (use fun and whimsical, borderline chaotic commits)

an example of each of the above mentioned:

Strengths of each: the former has plenty of context (that no one will ever actually read), the later has an emoji.

Here we see a real life example of Conventional Commits being used in a production environment by the developers of the best web framework in the world.. Angular!

Now.. if Angular uses Conventional Commits, maybe you should too..

~~

I won't bother spending any more time discussing commit styles. You've probably latched on to one of them and made it more a part of your identity than your favorite color.

A little bit about my version control workflow..

Most of my programming is done solo. I occasionally work on some automation technologies with a team of 2-4 people at work, but even then, each developer is often the only one working on their specific portion of the codebase.

I oscillate between pretty verbose commits and commits more or less similar to "update".

I have a shell script that enriches my commit process by prompting for a "type" like bug:, test:, refactor:, etc which prefaces my commit titles. It then prompts for the commit body in three sections.

What: is where I describe the changes made (ex. add on-demand revalidation to pages).

Why: details the reason for the change or the problem it solves (ex. incrementally revalidate pages when content changes).

Next: is used to list next steps in the process that aren't included in the commit, like testing, refactoring, resolving newly created dependencies, etc. (I had an idea awhile ago to write a git hook that creates labeled issues from the entries in this section; I'll add an update here if/when I get around to it).

I will typically author a new commit when switching contexts. ie. when moving between features. Some people choose only to commit after they're done with a coding "session", others write one for every few lines they add, and others still will only commit when asked by their fellow engineers where the new code is. Smaller commits are typically preferred, but do whatever is intuitive/conducive to your workflow.

Proper devops pipelines will (typically) be triggered by a new commit. This means every time you push a commit you better be ready for that code to be linted, tested, built, or even deployed.

Up to this point, all commits are usually made on a feature branch. Branching strategies are a whole other pandoras box, but at it's most basic, a "main" branch will hold stable, production ready code and other branches will hold in-progress code that will eventually be merged into main.

The process of merging a branch into main is best done through merge requests (pull requests in GitHub land).

A PR creates a new commit containing all the changes in all previous commits on a branch and pushes that commit to a new branch.

Pull requests should be authored often and closed just as regularly. Massive PRs are not fun for anyone, it's best to keep them small and specific.

So what's the bare minimum needed to open a PR?

Many people will say "a working feature", but I disagree; one because "working" is as ambiguous a term as "perfect"; two because PRs aren't a measure of done-ness but of progress. I say PRs should be authored when you have a testable feature.

The liminal space between opening a PR and merging that PR is an oft overlooked, but important step to your devops-y workflow.

An open PR presents an opportunity for collaboration and discussion. Multiple devs can look over the new code and make suggestions, which can then be updated simply by pushing a new commit to the branch.

Pull requests are more atomic than commits (they represent a more complete feature), but not entirely atomic. The code review process after opening — but before closing a PR — brings the feature from 90% to 100%.

~~

These were some of my thoughts and opinions on version control. Devops is largely subjective and depends on personal preferences. I have no authority on this topic to say what is right or wrong. I'm just a guy who likes to code.

Now go forth and write good commits.