9

Let's say I have a commit history with 5 commits. I know that I can rebase my commits locally when making a pull request which will then have them rebased into a single commit.

A common use case for this is:

  • Make local commits, working on feature
  • Squash commits
  • Make Pull Request
  • Receive review comments
  • Update PR appropriately

I can do this locally on my machine and then push my change again (using -f since the rebase makes it out of sync with the remote). This is kind of annoying.

However, this requires that I do a rebase every time I address review comments - is there any way I can do this from the web interface?

Or maybe my workflow is wrong, should I be amending each of my "review comments" commits directly onto the main PR commit?

enderland
  • 13,825
  • 17
  • 98
  • 152

1 Answers1

10

You don't have to do any rebase/squashing locally anymore: just push your commit to your PR branch.

The owner of the original repo, if he/she chose to, will squash those commits for you (since March 2016):

https://help.github.com/assets/images/help/pull_requests/squash-and-merge.png

See "Squash your commits" and the documentation: it does allow for a new workflow, both for you the contributor, and the maintainer of the original repo.

As I comment below: it will be implemented like the merge of a PR is implemented:

  • If it works without conflict, the merge (or here, the merge --squash: see "In git, what is the difference between merge --squash and rebase?") will be created automatically.
  • If there is any conflict, the merge is not created, and the maintainer has the option to reject for now the PR, asking the contributor to do the work of squashing the commits and amending the PR.

This is really like what exists now, except GitHub has added the --squash to their merge command. Nothing more.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • We were talking about this at work yesterday - it must not be an April Fools prank? :) I'm curious how it will work, because if it is basically rebasing then it will require all your intermediate commits to successfully rebase automatically (and not require manual merging). If it just takes "final state" vs "initial state" and does a diff? That's be good. – enderland Apr 02 '16 at 19:14
  • @enderland It is not an april fool indeed! GitHub must be listening after the https://github.com/dear-github/dear-github episode. – VonC Apr 02 '16 at 19:15
  • Yeah. I'm just concerned it will not work well in practice if it is doing a rebase/squash operation... – enderland Apr 02 '16 at 19:17
  • @enderland it will work well in practice, as it will produce only one commit added to the main branch. – VonC Apr 02 '16 at 19:18
  • I know that's the end result. But how will it be implemented? Is it doing an automatic `git rebase --squash master`? Or is it doing a more complex patch or diff process? Some of those will work better than others. Will it result in a "cannot squash, merge conflicts" situation if it doesn't work automatically? – enderland Apr 02 '16 at 19:20
  • @enderland it will be implemented like the merge of a PR is implemented. If it works without conflict, the merge (or here, the `merge --squash`: http://stackoverflow.com/a/2427520/6309) will be created automatically. If there is any conflict, the merge is not created, and the maintainer has the option to reject for now the PR, asking the contributor to do the work of squashing the commits and amending the PR. This is really like what exists now, except GitHub has added the `--squash` to their merge command. Nothing more. – VonC Apr 02 '16 at 19:23
  • Ah, neat! I didn't realize the intricacies of those differences in your other question - thanks for linking that too. – enderland Apr 02 '16 at 19:27
  • @enderland No problem. I have included that comment in the answer for more visibility. – VonC Apr 02 '16 at 19:29