重新打开上次提交

Question

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).

Answer 1

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.

Answer 2

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 ( W ork I n P rogress).
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>

Answer 3

Well, with the help of TJ. Crowder and IMSoP I found this quite cumbersome solution. But works fine.

git rebase -i HEAD~1 // or more for editing more commits back

In the interactive mode editor choose the commit to edit and replace 'pick' with 'edit', save and exit

git reset --soft HEAD~1

Now, you see the your work in progress as if you never commited it before. Make your changes.

git add *

git status // find a hash in "Last command done:"

git reset --soft <hash>

git rebase --continue

git push origin HEAD:refs/for/master%wip

If you open now web interface of your Gerrit server you find that your commit (and all following) have a new patchset.