I like to an have overview of my current code changes in unstaged (or staged) files before a commit. But in the end of the day I commit even not working code and send it as a Work In Progress to Gerrit to have a backup of my work.

The other day I would like to "reopen" the commit to continue the work. This means that I would like to have yesterdays state just before commit, but I don't want abandon the commit as it is already sent to Gerrit. I would like to have the same files unstaged and HEAD pointing to the current commit in order to amend the changes when code is working and may be commited.

This code almost works, just I end up with HEAD one commit before:

touch file

git commit -am 'Work in progress commit'

git reset --soft HEAD~1

If I use git commit --amend I would edit different (previous) commit.

If I use git commit -am 'Work in progress commit' I would create different commit from the yesterdays. And yesterdays will be lost (but not in Gerrit).

CodePudding user response：

Commits in git are immutable. This is not a convention that any tool can bypass or work around, it is fundamental to the way git works: a commit is identified by a hash of its contents, so any change in the contents is guaranteed to result in a different identifier.

Branches, on the other hand, are movable pointers to a commit. You can create a branch, create a work in progress commit, and then repoint the same branch to a new commit later. That is in fact what git commit --amend or git reset --soft followed by git commit will do.

To share the new version, you need to use git push --force-with-lease (or the older and slightly less safe git push --force) - be very careful doing this for shared branches, but use it as much as you want for a branch that everyone knows you "own".

Alternatively, you can just keep adding more commits to the working branch. At the end of the task, you might want to use git rebase -i to squash some of them into a "tidier" history; or you might not bother, and just leave the chain of intermediate commits as a record of your thought processes.

CodePudding user response：

When and how to branch and commit is subjective, but objectively if you want to avoid having those "WIP" commits in your log (for instance, when contributing to someone else's project where your final pull request should be clean), here's one strategy you can use:

1. When starting something, create a branch. Let's call it feature/the-thing.
2. When you're about to do a series of things you expect to take a couple of days, branch feature/the-thing to feature/the-thing-wip (Work In Progress).
3. Commit and push early and often to feature/the-thing-wip.
4. When you're ready for a "real" commit to feature/the-thing, merge feature/the-thing-wip into it with --squash (or just merge to the working tree and then commit that) with a useful commit message saying what you did during the WIP. (Optional: Delete the feature/the-thing-wip branch.)
5. Repeat as appropriate until the branch is complete.
6. Either merge feature/the-thing with your main branch or send the pull request using feature/the-thing.

The result is that feature/the-thing only has the "real" commits.

<subjective>In projects you're not coordinating with lots of other people, there's no need for that WIP branch. Just branch, commit early and often, then merge as normal.</subjective>