Hacker News Reader

Comment by mmanfrin | Hacker News Reader

My only real git crisis was when I accidentally `git push -f`ed what I thought was my own branch, but actually the `develop` branch. On a monday. After a weekend where about a hundred commits had been cherry picked and merged in to develop by a dev not in the office. None of my coworkers had recent versions of develop.

The thing that ended up saving me was our CI -- we autodeployed passing builds to our staging env; so we were able to ssh in and `git push -f` back from staging to our repo.

View on HN

Git generally doesn't delete commits until a garbage collection is done (and assuming no other references). If you find yourself in this situation again, then try:

git reflog show remotes/origin/develop

This will show the reflog for the branch, then you can find the hash just before your push, check it out, then force push it back.

I've recovered from other developer's accidental force pushes in less than 5 minutes, with no commits lost.

But if the remote has advanced since you pushed, you'll still need to reflog on the remote server, right?

Someone must have pushed the version the remote was at, so the correct commit would be on someone's devbox.

It was a series of PRs merged on github, no one in the office had a current branch of develop.

It looks like you can use the GitHub API to get the events for the specific repo, which would include your force push, and the hash of the previous commit. Some instructions at https://objectpartners.com/2014/02/11/recovering-a-commit-fr...

edit: This should be in reply to jordigh's comment above

If it's just a matter of "merging" couldn't you just merge those branches again? Or do you resolve conflicts on github or some such (something that's never fit my workflow but I can imagine others using it)?

That's really the point. The guy who made the last change should have it locally as well. Even if he git pulls first.

During any push, the remote advertises latest SHA-1. I don't know if we actually use it in 'push -f'. But if we haven't, it's a good idea to save this in local reflog.

My most recent major git crisis wasn't reversable by git.

A little while ago, I accidentally did a `git clean -xdf` on my home directory (wrong tmux tab). I index my home directory: just the most important config files, among other notes and text files. That `git clean` call wiped half my home directory before I realized what was happening and frantically tried to ^C and ^\ it. I had to find other ways to recover my files.

The deleted files weren't essentially important, which is why I didn't back them up frequently or index them, but they were moderately important. That was a bad day.

I realize it's probably better to dump everything in ~/.config and index that instead, while maintaining symlinks in ~/. It was just the way I had it set up.

I suggest to use GNU stow for managing config files and keep your repo in a separate directory.

Places like bitbucket let you mark branches (like master and develop) as non-deletable and non-rebaseable. Basically it prevents errors like yours.

Seriously. I don't understand why github doesn't provide at least the ability to lock the master branch against any action other than a merge from another branch. Merging a branch that causes major damage is unlikely if there's any kind of review process and generating a revert to "undo" that damage is a one button thing in the github-webUI if you do it immediately, or at least before master gets other commits on top of it. But I'd think everyone's workflow would stop because they'd have a ton of conflicts from a screwed up master.

In fact, let me ask HN. Does anyone work in a place where devs commit directly to master? I can't even imagine that workflow. Everything I've seen or heard of is PullRequests, code-review, +1, then merge to master.

> Everything I've seen or heard of is PullRequests, code-review, +1, then merge to master.

That won't help you when you think you're pushing to and from your own branch, but are accidentally on develop and force-pushing to the remote develop branch.

But if your process is only merging PRs, then locking the master against pushes as he proposes would create no further issues, preventing that from happening. If you need to modify the master directly, it would complicate things.

That's where locking down the branches and preventing rebases comes into play. It prevents someone from accidentally doing what you describe.

Most people only know github and I don't think they expose this locking feature in their UI which is a shame.

Yes I do work directly on master because I use the http://martinfowler.com/bliki/FeatureToggle.html pattern as opposed to http://martinfowler.com/bliki/FeatureBranch.html because in my experience branches come with an amount of technical debt that has been unacceptable to me (you just delay merging your code, making it a bigger more dangerous merge).

Branches also encourage a workflow [in my experience] where the devs implement multiple unfinished features on different branches. That's another form of technical debt. If everyone works right on master, it is more natural to finish a feature before moving onto the next.

I've also had to rewrite history on a git repository to remove things like binary files.

In the top level comment for this thread, I'd say the situation could have been avoided if that developer were cherry-picking to the git repo on his computer, then pushing that branch to the server. The history would be present on both that dev's computer as well as the server, so losing the history on the server would not affect the branch on that developer's machine. Not sure if the comment implies the developer had SSH'd to a live server & performed his cherry-pick there, but that's how it sounds.

The only use I've found for [feature] branches in my day to day work is a place for a junior developer or un-trusted OSS contributors to push changes for me to review before I merge them in. If I'm on an experienced team, I find things go smoothest if we all stay on master.

in my experience branches come with an amount of technical debt that has been unacceptable to me (you just delay merging your code, making it a bigger more dangerous merge)

You can solve that by regularly merging or rebasing master onto your feature branch (as described in Fowler's article).

"Does anyone work in a place where devs commit directly to master?"

I think this is probably common in places that have used SVN/Perforce/Whatever since forever and migrated to Git because it's now a "best practice"

It's also quite common on new projects. Many developers see no point in developing on branching when there isn't even a completed prototype yet, so the commits tend to be very wide-ranging instead of focused.

GitLab CEO here, in GitLab we do this too and call it protected branches, your master branch is automatically marked. See https://about.gitlab.com/2014/11/26/keeping-your-code-protec...

I always recommend people to use `git push --force-with-lease`. It's more to type, but it verifies if the remote branch is the same as the remote tracking branch, so you don't accidentally rewrite branches someone else has pushed to.

You can just alias it in your bash profile, if it's too much to type.

alias gitpushf='git push --force-with-lease'

Mercurial Evolve is a safe and distributed alternative to `git push --force`:

https://www.youtube.com/watch?v=4OlDm3akbqg

Maybe that was why I always `git fetch && git push -f`. But luckily since a few months it's not a problem anymore if you configured your git correctly, because now it only force pushes your current branch.

Just make an alias pushf = push --force-with-lease, and it becomes even less to type! :-)

For what it's worth, you could have looked at the reflog of the git repo on the server and it would still have a reference (the hexadecimal hash) to the develop branch before your git push -f.

We had the hash, but no one had it locally and we could not pull it down since I had overwritten the history.

This isn't a criticism. I'm either missing info, and am making a fool of myself, or telling you about something you didn't know was possible:

You either had git configured on the server to git-gc after every push, or were unable to ssh into the server?

If neither one of those is true, then -IIRC- you could have either:

1) Logged in to the server, rewritten the affected repo's branch to point to the pre-disaster commit hash.

2) Pull down the repo's .git directory from the server, rewrite the branch, and force push that.

Would either one of those have been more work than working with your CI system?

He mentions in a different bit that it was actually on github, not their own git server. There is a way to get the reflog and write a new branch to point to the commit using github's API mentioned above.

Ah. Thanks for the info!

What kind of workflow do you use where a git push -f is necessary? Just curious, I'm no git expert.

How is this not undoable with whatever the reverse merge command is?

Second why ever use force merge?

Reply on news.ycombinator.com