Can I decide in Git that the last commit is pushed?

84 views Asked by At

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?
2

There are 2 answers

1
hlovdal On

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_feature which contains the finished commits and then another branch named wip/my_feature or my_feature.playground for instance which contains the unfinished commits, which you then rebase on top of my_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_feature and "disappears" from the other branch when it is rebased.

0
jthill On

You're already doing first-draft work locally, now for the next step: learning to use Git to revise your drafts for publication.

Don't amend. Just commit in series to start, any time you want you can squash and push:

hack
git commit
hack some more
git commit
hackity hack
git commit
hack
git commit
# . . .

When it's time to push:

git reset --soft @{u}
git commit    # this will be the only commit you push

and you're done. Or git reset @{u} and do a series of git add -p / git commits to present the work in series, as digestible chunks, or use git rebase --interactive when it's time to get more industrial with your editing.