How to cleanly add after-the-fact commits from the same feature into git tree

Question

I am one of two developers on a system. I make most of the commits at this time period. My current git workflow is as such:

• there is master branch only (no develop/release)
• I make a new branch when I want to do a feature, do lots of commits, and then when I'm done, I merge that branch back into master, and usually push it to remote.

...except, I am usually not done. I often come back to alter one thing or another and every time I think it is done, but it can be 3-4 commits before I am really done and move onto something else.

Problem

The problem I have now is that .. my feature branch tree is merged and pushed into master and remote master, and then I realize that I am not really done with that feature, as in I have finishing touches I want to add, where finishing touches may be cosmetic only, or may be significant, but they still belong to that one feature I just worked on.

What I do now

Currently, when I have extra after-the-fact commits like this, I solve this problem by rolling back my merge, and re-merging my feature branch into master with my new commits, and I do that so that git tree looks clean. One clean feature branch branched out of master and merged back into it. I then push --force my changes to origin, since my origin doesn't see much traffic at the moment, so I can almost count that things will be safe, or I can even talk to other dev if I have to coordinate. But I know it is not a good way to do this in general, as it rewrites what others may have already pulled, causing potential issues. And it did happen even with my dev, where git had to do an extra weird merge when our trees diverged.

Other ways to solve this which I deem to be not so great

• Next best way is to just make those extra commits to the master branch directly, be it fast-forward merge, or not. It doesn't make the tree look as pretty as in my current way I'm solving this, but then it's not rewriting history.

• Yet another way is to wait. Maybe wait 24 hours and not push things to origin. That way I can rewrite things as I see fit. The con of this approach is time wasted waiting, when people may be waiting for a fix now.

• Yet another way is to make a "new" feature branch every time I realize I need to fix something extra. I may end up with things like feature-branch feature-branch-html-fix, feature-branch-checkbox-fix, and so on, kind of polluting the git tree somewhat.

Is there a way to manage what I am trying to do without the drawbacks I described? I'm going for clean-looking history here, but maybe I need to drop this goal, if technically it is not a possibility.

Sample After-the-Fact Commit Messages

Main commits:  alter module behavior to give user more information

Here I thought I was done, check out, & merge to master, then oops, forgot this (OFT):

OFT:  (enhancement) added better error messages

Okay, now I am done!

Later, user comes back and asks for an enhancement/feature. Turns out a certain input number for an order can have a revision associated with it. So it's really two numbers, not one.

OFT:  (feature-add):  fix up order input to accept revisions

Now I'm done ...

OFT:  (bug-fix) there was a bug with the two-number input method, fix SQL for that

okay now I'm done ...

OFT:  (enhancement) oh wait, improved error messages again, for clarity!

Answer 1

When you merge into master, you are essentially declaring "I'm done". It's like dropping your mail at the post office, or signing a lease. You can't change your mind after merging (of course, in reality you can, thanks to the wonders of technology; it's just bad etiquette when collaborating with others).

If you feel that you need to add more to it, then what you're adding is either:

• A non-essential improvement, which means you can treat it as a new branch and work from there.
• Or an important bug fix, which should happen very rarely – this is why one should always run the tests before merging into master. In this case, be sure to let everyone know that master is broken and resolve the situation quickly.

If you feel that your feature still needs more revising, then don't merge into master!

If for some reason other developers want a sneak peek of what you're doing, you could just push the feature branch instead, or make a dedicated temporary branch with all the caveats of being "temporary".

(Of course, there's nothing sacred about master per se, it's just that by convention most people expect it to be a stable base from which everyone can pull.)

Note that branches do not necessarily correlate with your features. Git is for tracking history and thus commits don't necessarily happen in a logical and neat way sometimes.