Git Weekly 4 - divide and rule

What if git could help us detect code smells? I’m going to share with you a past experience that resurfaced through a tweet.

How can I find the most modified files in git? #

Having regular merge conflicts on the same file is a weak signal that there’s a software design problem.

Indeed, merge conflicts indicate that developers have to modify this file in parallel when implementing their functionality. If this happens too often, perhaps this file has too many responsibilities. It’s time to refactor it and cut it out!

That’s why I’m interested in these files when development teams regularly complain about merge conflicts.

Is it possible to anticipate or at least detect this problem? Yes, by monitoring the number of modifications per file in the git repository. Here’s the git command that displays source file modification statistics:

$ git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head
    581 
     69 src/main.c
     30 src/lib/reader.c
     23 src/lib/client.c
     22 src/lib/decoder.c
     20 src/lib/writer.c
     18 src/lib/storage.c
     16 src/orchestrator.c
     14 src/lib/encoder.c
     13 cfg/mapping.config

In the example above, the src/main.c file has more than 2 times as many modifications as any other source file in the project. Perhaps this file is much older than the others. Nevertheless, at this stage, it’s important to ask the teams if they often have merge conflicts over this file. If so, then it’s time to cut it out!

divide et impera
— Philip II of Macedon

This tip came to mind while reading Arnaud’s tweet about the How did we carve up our legacy? conference^[1]. On a previous project, developers often had conflicts on the same source file. In fact, it was the core engine of the solution and had too many responsibilities. With a little refactoring to divide it up, the number of conflicts decreased. The developers saved time. They were more serene during git merges. Everyone was happy again!

This is an indicator that is not currently found in static code analysis^[2]. However, it’s very practical and I recommend that you follow it. If you can’t, at least listen to the development teams. If there are recurring complaints about merge conflicts on the same file, then it’s time to act and split responsibilities.

Here’s how git can help us detect bad software design practices. Let me know if you are using other quality indicator based on git.

Want to learn more about git? Check out the Git Weekly series!