Our manager is monitoring the Git commits on all of our projects; usually this isn’t a problem, and I love the fact that version control provides a log of all work that’s happening, especially for later auditing and analysis (in case anything goes wrong).
However, the manager has made a few comments asking what people are working on when he sees a commit that reads “style fixes” or any commit message that does not reference a ticket number in our task management system.
Is there a social or technical solution to this?
Further information: this is a maintenance project, so there’s a bunch of “had to do A then B then C and then D and then finally got to implement X” tasks happening.
More information: the particular commit message that raised a flag with the manager was close to “included a better way to X, Y and Z” which is more of a refactoring message rather than a simple stylistic fix.
9
Is there a social or technical solution to this?
I suppose, but this isn’t a problem.
Your manager should know what you guys are doing. They should make sure that you’re not doing a bunch of work that provides no value, or why non-ticket work was prioritized. There is no harm in this. In an ideal world, it will provide benefit, because your manager can set expectations with business so that you can get all of that work done without pressure or interruption.
It only becomes a problem if your manager thinks that only ticket work should be done, and precludes technical cleanup work from being tickets. There is always technical debt to clean up. Always things to tweak because you should, even though they provide no clear, immediate business benefit.
If the stylistic fix is part of the ticket you are working on and it is related then there is nothing wrong with checking it in separately with the same ticket number you were working on for better identification.
If you are just discovering changes that need to be made and they are not related to the ticket that you are currently working on then I would suggest making tech debt related tickets and put them on your backlog for later rehashing.
During your planning you can then go through the tech debt related tickets and attach them to actual maintenance tickets that you are planning on working on this way making it more relatable.
This will help you eliminate those “out of nowhere” fixes and keep everything encapsulated under the category of specific problems/tickets you are working on.
5
This bugs me too (no pun intended :).
Most helpful check-ins contain comments that are unique, and specific to not only what changed, but why. I sometimes end up putting paragraph comments.
I occasionally get into situations where a UI requirement bounces back and forth once development has started, requiring me to essentially bounce the code also (yeah, real world sucks sometimes). In these cases, I see it as even more important that my comments provide clarity as to why the bounce, and more importantly why the code ends up where it does. Then, when management comes back after speaking to the customers and wants to know why, I can show them without having to remember the whole experience turn-by-turn.
Where do you work? I am willing to relocate anywhere in the world to work for that manager!
Version control messages are an important and often overlooked type of documentation even by technical managers. DO write sane commit messages, even if one page long.
Now that I have stopped ranting, let’s look at the question.
The manager requests clarification on what a commit stating only style fixes means? Hooray! Do explain to them. Do make a clearer post-factum commit. Do never write one-sentence (with improper grammar) commit messages in your life ever again. Do cherish that manager.