Skip to main content

Simple code: Version control commits

Currently the most popular version control system is git and I'll be writing this based on git and it's functionalities and capabilities.

Git is often seen as a way to enable distributed programming i.e. multiple programmers can work on the same code repository quite easily without disturbing each others work (much). In addition to that just like other VCS's it's also a log of work but to my experience that part is often unfortunately neglected. What I will be focusing this time is the log part because I think it deserves more attention.

Why to create a meaningful log?

The git log should consist from small meaningful changesets where each commit addresses a single problem. By dividing the log to small commits it enables resilient way of working. Being resilient enables simple and fast procedures to rollbacks, reviews, tags, branching etc.

Lets say that a developer is implementing a REST API. The API needs a web layer that receives the HTTP requests, it probably has some sort of logic layer to do data transformations and validations and maybe some calculations and finally it has a data storage where the data is persisted. There are options how to record this work to the log. One option would be to implement the API and record a single commit or squash the commits before pushing the changes to remote so it would become a single commit. Another option would be to record commits every now and then while developing and finally push those commits as is to the remote repository. Yet another way would be to carefully pick what is recorded per commit in order to have a set of meaningful commits that each address a single issue.

Example of the first approach would be something like this:

* Add API for movie ratings

The second approach might look something like this:

* Add DAOs
* WIP
* Fix
* Add REST API
* Fix
* Refactor
* ...

The third approach could be like this:

* Add DAO implementation to list movie ratings
* Add REST API endpoint for listing movie ratings
* Add validation of REST API's parameters to movie ratings listing
* Add transformation logic from movie rating DAO to REST API JSON
* Change movie rating listing to sort ratings ascending by the review date
* ...

If something was wrong with code e.g. in the validation logic it would be easy to see what commit introduced changes to there from the third and first example but from the second one not so much. With the first example we know it contains the unwanted behaviour but it also contains a lot of other changes too so we have to go through it all to see what has changed whereas on the third example it's quite obvious to see what changes introduced the validation logic and it's easy to isolate on what has changed at that point.

Another point for keeping a meaningful log is readability. It's much nicer to read a consistent log of small changes than a set of random commits or commits that introduce a whole lot of changes.

What a meaningful log should say

Ideally the log could be read so that you can read what's been done without actually looking at the changes, the code, at least on high level without going to the details.

The commit should explicitly say whether something was added, removed, fixed, refactored, rewritten etc. It should also say what was changed, not per file but per feature or use case. Finally the commit should say why it was done unless it's obvious, adding a HTTP endpoint doesn't need a separate reason but fixing a validation error would benefit from a short description.

How to create a meaningful log

TLDR; Piece by piece.

In perfect circumstances programmer would write a few lines of code and commit the changes but quite often it's hard to write code in that way. Some practices that help with this are TDD, test-driven development, and TCR, test and commit or revert. In addition to these two git itself provides a great set of tools to help split the work to smaller chunks. Some features that I use on daily basis are amend, rebase, interactive rebase, interactive add and stashing. With these features and healthy amount of self control I can produce quite good log that consists of small commits that each address a single issue and they're descriptive.

Next part

In the next part I'll be writing of a really important topic, naming.

Popular posts from this blog

Sharing to help myself

It's been a while since my last post but I have a good excuse. I've been in a new customer project (well new for me) for two months now and have absorbed a lot of new information on the technology stack and the project itself. This time I'll be sharing a short post about sharing code and how it can help the one who's sharing the code. I'll be giving a real life example of how it happened to me. My story Back when I was implementing first version of my simple-todo REST-service I used Scala and Play framework for the service and specs2 for testing the implementation. Since then I've done a few other implementations of the service but I've continued to use specs2 as a testing framework. I wrote about my implementation and shared the post through various services and as a result someone forked my work and gave me some pointers on how I could improve my tests. That someone was Eric Torreborre  the man behind specs2 framework. I didn't take his ref

Simple code: Immutability

Immutability is a special thing that in my mind deserves a short explanation and praise. If you're familiar with functional programming you surely recognice the concept of immutability because it's a key ingredient of the paradigm. In the world of object oriented programming it's not as used and as easy to use approach but there are ways to incorporate immutability to parts of the code and I strongly suggest you to do so. Quick intro to immutablity The basic idea of immutability is unchangeable data.  Lets take a example. We have a need to modify a object's property but because the object is immutable we can't just change value but instead we make a copy of the object and while making the copy we provide the new value for the copy. In code it looks something like this. val pencil = Product(name = "Pencil", category = "Office supply") val blackMarker = pencil.copy(name = "Black marker") The same idea can be applied in functions and metho

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does