1

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?
Gyula Sámuel Karli
  • 3,118
  • 2
  • 15
  • 18
  • 1
    if you don't need the local commits while pushing it to remote, you can merge all your local changes into a single commit using soft reset instead of amend ? – Pavan Kumar Polavarapu Apr 06 '23 at 05:07
  • 1
    If you amend a commit that was already pushed, you generally need to force push the new result `git push --force-with-lease` – LeGEC Apr 06 '23 at 06:00
  • 1
    You could use a `post-rewrite` hook to validate the changes, and abort if the old object name is already present on the remote. – William Pursell Apr 06 '23 at 07:18
  • `post-rewrite` won't prevent you from making the commit, but you could just have it emit verbose warnings. – William Pursell Apr 06 '23 at 07:38
  • 1
    Why do you not want to have "intermediate", possible non-working commits? It is not a problem to commit often, as long as the server side (at least the main/master branch) always has a working version on HEAD. You could consider working on a feature branch, where it is just you working on it, you can commit and push whatever you want (without amending too often). When you then merge your feature branch(es) into main/master again, you can `git merge --squash` to just make the new feature set a single commit. – Torge Rosendahl Apr 06 '23 at 14:55
  • Torge Rosendahl: It's a good idea but I happen to forget to a feature branch many times. – Gyula Sámuel Karli Apr 09 '23 at 21:34
  • @WilliamPursell: not a bad idea, though sometimes the problem is that I push something and then just realize that I have left something out and it would be ideal to commit the forgotten stuff and "re-push" the thing – Gyula Sámuel Karli Apr 23 '23 at 07:29

2 Answers2

1

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.

jthill
  • 55,082
  • 5
  • 77
  • 137
0

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.

hlovdal
  • 26,565
  • 10
  • 94
  • 165
  • So what You essentially say is not to amend previous commits but have them until push and when pushing removing them in an automated way. If the script handles the messages in the commits to be deleted well (they bear info still) it's kind of a working solution. Just to note there is another problem, namely I regularly tend to realize right after push that I have forgotten something so I want to amend the already pushed stuff, this is kind of unsolvable this way. (Note: this is the original question :-) ) – Gyula Sámuel Karli Apr 12 '23 at 03:36