CODEWITHSUNDEEP
git
Tim Randall
Tim Randall

Reputation: 4145

How to recover after pushing to master by mistake

I make this mistake quite frequently and I am wondering if there's a better solution, and also whether my current solution is risky.

Here's the workflow

  1. git checkout master
  2. git pull
  3. git submodule update --init --recursive
  4. (edit, debug, test)
  5. git commit -a
  6. git push origin HEAD:refs/for/master
  7. (more edit, test, etc.)
  8. git commit -a
  9. gitk
  10. (swearing)
  11. git rebase -i HEAD~2 # pick and squash my two commits together
  12. git checkout -b task_id
  13. git checkout master
  14. git rebase -i HEAD~2 # pick previous user's commit, delete my own

My mistake is that somewhere around step 5 I should be doing something like step 12 to create a new branch to keep this work separate from every other task, to allow me to easily come back to it or rebase different patches in the desired order or whatever. Instead, I am pushing new code onto the master branch, and around about step 10 I realize that master is no longer pointing at the latest and greatest version of the code that the company has approved, but my own efforts. So after squishing my own commits into one with an interactive rebase, I'm doing another interactive rebase to get master pointed back where it should be -- namely, someone else's work that has been through the review process.

Edit to clarify: When I "push to master" this doesn't publish my changes to everyone else. There's some commit hook magic that creates a Gerrit code review task and only when approval is obtained from that is my commit merged into the remote repository. Apologies for misleading you all. My concern here is only for my local repo.

My question is twofold. How bad is this practice, in terms of risk, and how could it be improved upon? I'm not asking for help in avoiding the initial error. I think I just need to be more careful about which branch I'm pushing to. The question is how best to point master at the previous commit without disturbing/risking/losing anything.

Upvotes: 4

Views: 7148

Answers (2)

Caleb
Caleb

Reputation: 124997

I am pushing new code onto the master branch, and around about step 10 I realize that master is no longer pointing at the latest and greatest version of the code that the company has approved, but my own efforts.

The root of the problem is that you're even allowed to push directly to the master branch on a shared repository. You should be pulling from the shared repo, but pushing to your own fork and making pull requests. Your pull requests should be reviewed by someone else before being merged by somebody other than you. Yes, you could avoid pushing to master by creating your own branch early on, but the real problem is that you (and presumably others) can push directly to master at all.

How bad is this practice, in terms of risk, and how could it be improved upon?

It's pretty bad, mostly because (again) you shouldn't be allowed to do it at all. How do you know that your "fix" is the right one? What do you do if someone else merges their changes (which may or may not have been reviewed) on top of yours before you realize that you screwed up?

The fix is to disallow pushes directly to master.

Update: Given your comment that you're not talking about the master branch in your shared repo but rather the master branch in your own fork, then your solution seems fine. The master branch in your own repo doesn't really mean much, at least for most of the work flows that I've seen. Usually you work in your own branch, then push that branch up to your fork and make a pull request back to the shared repo, at which point there should be a code review and maybe other checks before your code is merged. So your process to fix your own master branch is fine -- save your work off to a new branch, then reset or rebase your master branch to get it back in sync with the remote master.

Upvotes: 1

Code-Apprentice
Code-Apprentice

Reputation: 83527

If you have only pushed a single commit, you can do the following:

git checkout master
git reset --hard HEAD~
git push -f

This will restore master to the previous commit. If you made more commits, you can replace HEAD~ with any other commitish (a SHA1 hash, a branch name, a tag name, etc.).

My mistake is that somewhere around step 5 I should be doing something like step 12

I suggest that at Step 4, before you do any coding at all, that you create a new branch. There should be no ambiguity here. Typical best practice is to create a new feature branch in order to keep on going work separate and only merge it into master once the work is complete. Committing half-complete work on master will make your software unstable and difficult to release.

Upvotes: 7

Related Questions