8

My personal approach to a git commit is that every commit should include a unit of change, in its completness.

When I develop, I usually focus on such units. But sometimes, my attention strays someplace else and I work for a while on a different unit. This is probably not optimal, but I have learned to commit carefully (git add --interactive is a good friend of mine).

However, it could happen that I forget to selectively stage my changes and instead commit the whole file, believing that all the changes I see in the diff are indeed related to the same unit, even though there might be a change or two completely unrelated.

Then I git push.

Is this dangerous? Should I make effort to amend the commit so that it only includes the intended changes? My primary concern is that whoever else looks at the history will see the change and will probably scratch their heads for several minutes before realising it is most likely a mistake. Worse still, I can imagine that the change will even look related and the programmer might not recognise the error.

The problem is, since I have already pushed, I cannot safely rewrite the server's history, so I would probably have to first revert the commit, split it properly and commit again. Alternatively, I could just amend the commit with a better commit message, but I would have to be really really fast since it also requires rewriting history. As a last resort, I might simply commit the unit I was working on as next, leaving a note that there is a related change in previous commit (but this feels wrong).

I understand that in a multi-developer setups with proper code-review workflow this would likely not happen. I also understand that if I am the sole developer on a project, then rewriting history is the best solution for this.

  • Are you using git flow? (prod, integration, feature branches?) Using git flow I am not to worried about commits to feature branches. Merges into integration are done on feature completion and merges into prod are done on release. – RubberChickenLeader Jun 4 '15 at 15:52
  • argh its so annoying when this happens, but such a pain to roll it back and recommit – Ewan Jun 4 '15 at 16:31
  • I can see how using git flow could mitigate this (cannot work on other unit unless changing/creating branch), but I feel the workflow would, in my current work environment, only slow me down. Perhaps in a bigger project / different work env. – Robert Rossmann Jun 4 '15 at 16:46
9

Commit history is vitally important, but for 3 reasons:

  1. merging to somewhere else. You need to pick the pieces out of a branch and stick them elsewhere, its important to have all the pieces you want in there and nothing you don't want. So if your 'messy' commit contains changes intended for the feature you're working on (and not, say an accidental commit of something else) then you're good.
  2. Auditing what happened sometime afterwards - usually to determine when a particular bug or feature was introduced. In this case, it doesn't matter what is in the commits as long as you can pinpoint the change you're interested in.
  3. Code review. Good peer reviews are committed and then reviewed (don't hold up the dev/commit process by waiting for a reviewer!) and in these cases the reviewer will want to understand what changes were made. However, generally a reviewer will be more interested in the overall changes - trying to review commits that were made, reverted, re-made is an exercise in time-wasting compared to reviewing all 3 commits at once.

So, although unit-of-work commits sound ideal, they're not anything to be insisting on in practical terms. I would attempt to keep commits sensible, and unit-of-work is a good way to keep commits sane, but don't bother trying to fiddle with the commit history just to keep the commits tidy. That's like updating a code file to make all the brackets line up the way you prefer - nice, but useless.

Now, if you have committed a bit of work intended for a different branch, revert it and commit it properly to the right branch. That's important, but if you've updated a bit of server code when you've been working on the GUI.. there's no need to worry about it.

1

When this does happen, it's not a huge deal to simply revert the change in the next commit. Add a proper commit message (Removing the XYZ that I accidentally added in C92A891) will be enough for other developers to understand in code review.

Rather than worrying about fixing any specific incident, try to avoid the situation in the first place.

This is the real issue:

However, it could happen that I forget to selectively stage my changes and instead commit the whole file

You should get into the habit of never committing an entire file (or worst off all your entire workspace!). Always commit line-by-line or by an entire Hunk that you have examined.

When committing this way (which it sounds like you're doing most of the time) inadvertent changes are far less likely to sneak in to your commits.

  • "Always commit line-by-line or by an entire Hunk that you have examined." Why? To me, examining and staging line-by-line is the exception, not the rule. I avoid working on more than one feature/fix at a time (mental context switching is expensive) and even when I have to, I stash work and unstash it as needed. For this reason, most of the time I can confidently commit all changes and entire files (after reviewing the diff, of course) and rarely do I have to tediously stage line-by-line or examine each hunk using an interactive add. – ADTC Apr 13 '18 at 22:37
  • @ADTC I find myself creating diffs around the actual fix I eventually find: logging, debug variables, a failed alternate approach, etc. I think it's easier to leave the mess in place, commit only the single-line fix, then blow away the entire index. – pkamb Apr 13 '18 at 23:05
0

It seems you have one local repository on your computer, and one repository shared with your coworkers on a server. Why do you have only one repository on your local computer? I usually have at least five, so I can work on one thing in one repository, fix a bug in another without touching the first repo, which might be in an incomplete state, and so on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.