0

I use branches as a backup of my WIP. But coming back to it I want to have my git diff back, so I can have again overview on changes while continuing my work.

So I usually reset my WIP-commit (git reset HEAD^) and start work again. But when I need to commit again (a definitive commit or a WIP-commit) and push it to remote origin I wonder if this new diverging commit could create problems to collaborators pulling the same branch.

I know they will if they will make changes and commit. But what if they just pull the branch but they never touch it, and consequentially they pull the second new diverging WIP-commit?

Is it safe enough to just agree to not touch the branches of the collaborators?

Kamafeather
  • 8,663
  • 14
  • 69
  • 99

1 Answers1

0

If your last commit has not been pushed, then git reset HEAD^ will not mess anything up. But if you have pushed, I would recommend against it, even if other collaborators are not modifying that branch. Let's say you make an initial commit A and push it, then git reset HEAD^ and make commit B. When you try to push it, you will get an error because your B has the same parent as A, and thus git cannot do a fast forward merge on the server. The error message will recommend that you do a git pull in this case. But once you do, you will have a new merge commit that merges A and B.

Now, you could get around this by doing a force push (thus blowing away A), but that will only work if nobody has pulled from the repo since you pushed A. Otherwise, next time they pull they will merge A and B on their local machine, and push that merge back to the server.

So long story short: never rewrite history that has been pushed.

David Deutsch
  • 17,443
  • 4
  • 47
  • 54
  • Nice explanation. Thanks. Do you have any suggestion for a workflow to have remote backup of WIP but without making the history too dirty with middle-stage-messy commits? – Kamafeather Jan 28 '16 at 13:48