17

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.

Improve this question
9
  • possible duplicate of Is reference to bug/issue in commit message considered good practice?
    – gnat
    Mar 31, 2015 at 15:12
  • 10
    I agree with your manager. Looking at a two-year-old commit log to figure out when something changed and seeing commits like "style fixes" is damn annoying. If your manager is not letting you add refactoring tasks into the task management system, that is a whole other issue.
    – Gort the Robot
    Mar 31, 2015 at 15:15
  • 9
    True refactoring is even more important to capture than stylistic changes. At the very least the commit message should say what is being refactored, but really I'd want it tracked so everyone knew what was being refactored, QA knew what to test more carefully, etc.
    – Gort the Robot
    Mar 31, 2015 at 15:23
  • 3
    ^^^ what @StevenBurnap said - this is very good practice. Just being able to refer ticket id instead of polluting commit message with lengthy explanations of what kind style improvements / refactoring is there and why these are desired makes it worth it. And there is more to that, tracking effort, communication with management / QA etc etc. And don't get me started of how it is convenient when bug tracker integrates with VCS / code review tool
    – gnat
    Mar 31, 2015 at 15:28
  • 1
    It completely depends on the situation. Is the manager reacting to a member of the team that is spending 50% of his time on refactoring or to a single commit without ticket reference?
    – winkbrace
    Apr 2, 2015 at 20:55

4 Answers 4

Reset to default
43

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.

Improve this answer
13

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.

Improve this answer
5
  • 1
    Okay but if it's a trivial fix then this is completely stupid.
    – Lightness Races in Orbit
    Apr 1, 2015 at 10:14
  • 2
    Tech debt 99.99% of the time is not trivial change. Which is why I say make a ticket instead of diving into something else that is a large context switch. If it is something trivial and unrelated to what you are working on then you can still check it in under the ticket name you are working on with a separate comment. Or better yet think of a notation such as QFIX for an easy identification later on, so you don't have random trivial changes floating around with no organization.
    – AvetisCodes
    Apr 1, 2015 at 12:51
  • what if the manager is also watching JIRA for new tickets and then questioning those? he doesn't question when tickets are moved from a future sprint to the current one but as soon as someone creates a new ticket related to technical debt, it's questioned.
    – user7433
    Apr 1, 2015 at 14:19
  • The QFIX notation one is something that you would need to talk as a team before implementing. It's all about communication, you don't just jump in and write your own rules. So first talk about it as a team, and then if they don't agree with then go with the other solution which is to check it in along with your main ticket you are working on with a separate comment. Please note though, once again, only if the change is trivial meaning it doesn't contain any logic changes or large refactorings. Innocuous, harmless, trivial changes.
    – AvetisCodes
    Apr 1, 2015 at 15:08
  • @omouse It may well be that your manager is micromanaging, or that he is not properly dealing with technical debt. However, the manager is ultimately responsible for the project as a whole, and responsible for the code itself, and so ideally should be at some level aware of every bit of work that goes on and why.
    – Gort the Robot
    Apr 1, 2015 at 17:06
0

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.

Improve this answer
0

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.

Improve this answer