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
masterbranch 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.
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
masterbranch 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-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!