

Introducing the Revert Button - _pius
https://github.com/blog/1857-introducing-the-revert-button

======
benatkin
I think it would be neat if GitHub detected and archived branches that are
deleted or overwritten with force --push. I don't know how feasible this is
but it would make it more true that _when code is pushed to GitHub, it 's
safe_.

Edit: what I have in mind is something like a Recycle Bin or Trash for deleted
branches where you can restore a branch (with a different name, if needed) or
delete it permanently. Not some esoteric git feature. I'd like if it were
added to git (as an optional feature enabled in .git/config), but I'd want it
to work more like stash than a feature for searching for things that were left
behind.

~~~
mvermaat
In a way that's already true, since the commits are still there (and included
when you clone). They're just not discoverable.

It would be neat though if GitHub added some UI magic to recover dangling
commits, possibly using the knowledge of which branches previously pointed to
them and/or push -f operations.

~~~
benatkin
Aren't these part of what gets cleaned up by git gc?

~~~
4mnt
Yes they are. But only after they get dropped from the reflog, after 30 days
by default.

------
cpeterso
I'd like to see a "Squash pull request" button to avoid merge commits, clean
up messy pull requests with WIP commits and changes to address review
feedback, and keep master bisectable at every commit.

~~~
Chris911
That would be awesome. The interface should be just like when you rebase and
you get to select which commit you want to squash or keep.

------
tildedave
This will be a huge help for teams of larger developers who use Github.

It's really easy for a branch to "look okay" at the unit level (generally
covered by the commit status API) and then completely fail at the integration
level.

Enabling quick reverts of bad code encourages people to make the "right fix"
rather than trying to hotfix issues in an integration environment (which
blocks the rest of the team and prevents other features from going out).

------
artursapek
Kind of ironic how Github continues to make it less necessary for developers
to actually learn git.

~~~
toomuchtodo
Why would it not be their goal to abstract away the pain? Sure, you still have
the power of git available to you, but not everyone who uses Github may want
to learn git. They may simply be looking for versioning of their assets
(images, geojson, etc).

------
alistairjcbrown
This is an awesome feature - not one you'll use every day, but one that's very
convenient when you've made an oops.

------
jonny_eh
This is great! But why is it only for PRs? Why not any arbitrary commit?

~~~
derefr
A developer can revert their own commits on their own branches well-enough by
using `git revert`.

This is more for Github's "Enterprise-y" (or "distributed FOSS project-y")
workflow, where you have

• a _project maintainer_ , who never touches git, and works entirely through
Github, interacting mostly with the issue tracker and only modifying the
codebase by accepting/rejecting pull-requests; and

• a set of _developers_ , who actually use git, and generate pull-requests to
submit to the maintainer.

Until now, if the non-git-using maintainer accepted a pull-request they
shouldn't have, they would have to get one of the developers to create a
reverting commit, create a PR for that commit, and then accept the PR. Now
they can just revert the PR itself.

