I have a workflow as following: during development, I often commit (locally) regardless whether I have reached any milestone, just for backing up and being able to recover if development goes towards a bad direction, or, for example, all the times at end of the day. But I don't want to see these "technical" commits later on, so I regularly use the amend option. Obviously, sometimes (typically when hitting a milestone) I do git push.
Problem is that I tend to try to amend already pulled commits, that makes conflicts.
Questions:
- Is there something that can protect me amending to an already pushed commit?
- Is this habit bad and I should do something else, like joining 'technical' commits on the server's side?
Checking in things temporary locally, even unfinished, non-working stuff, which is cleaned up later on is not just OK but I would claim that you're doing git wrong if you're not doing that to some degree.
Now I would recommend adapting a naming convention on your commit messages that creates a clear distinction between finished and unfinished commits, for instance pre- and post-fixing commit messages with
====. If you have that in place then managing what to push or not becomes really simple.You can also combine this with a branch naming convention like
my_featurewhich contains the finished commits and then another branch namedwip/my_featureormy_feature.playgroundfor instance which contains the unfinished commits, which you then rebase on top ofmy_feature, and eventually becomes "empty"1 as you convert the unfinished commits into finished commits2.1 Or the branch end up just containing added debug print commits or similar stuff that clearly was just intended to be temporary stuff.
2 Those finished commits are then merged/cherry-picked into
my_featureand "disappears" from the other branch when it is rebased.