1

I have been using the Github UI for awhile to merge PR (pull requests), the UI looks like:

enter image description here

I am trying to understand how these 3 things work more carefully. Here is my best guess as what these three options do:

  1. Create a merge commit
git merge <base> <other>
  1. Squash and merge
git merge --squash <base> <other>
  1. Rebase and merge
git rebase <base> <other>

Is this accurate? Or am I missing something?

Lazar Nikolic
  • 4,261
  • 1
  • 22
  • 46

1 Answers1

1

I have a longer version of this answer in Merge pull request in git causes the upstream branch to go ahead of origin but here is the shorthand equivalent. All assume you're on the base branch to begin with, i.e., git checkout branch. The message below is Merge pull request #number from repository and the hash is automatically computed from the pull request.

  1. Create a merge commit

    git merge --no-ff -m message hash

  2. Squash and merge

    git merge --no-commit --squash hash && git commit -m message

  3. Rebase and merge

    git rebase --force-rebase hash

(Note that the rebase-and-merge won't function if merge conflicts occur. It's not clear to me whether the GitHub system checks for this with --merge or without it, or some other way entirely. The pull request has already checked for merge conflicts with a git merge with or without --squash; refs/pull/head/number always exists, but refs/pull/merge/number only exists if there are no such conflicts, I think. They—GitHub—also keep track of whether the "base branch" used to create the pull request was/is up to date, but it's not quite clear precisely how they do that.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • So before each command, the base branch is checked out, right? –  Sep 12 '18 at 18:57
  • Well, GitHub is using plumbing code to do all the updates, there's no work-tree and no checkouts at all, but more or less, yes. – torek Sep 12 '18 at 19:03
  • well none of these commands would work correctly unless you had the base branch checked out, right? MrCholo dares to know. –  Sep 12 '18 at 22:41
  • in a normal, non-bare repository, yes, you must have the correct branch checked-out to start with. – torek Sep 12 '18 at 22:45
  • i am just curious how it would work in a "bare" repo then? do you know? is there info on this? –  Sep 12 '18 at 22:47
  • 1
    In a bare repository, there aren't any work-tree copies. You cannot run `git merge` or `git rebase` at all (both need a work-tree in case of merge conflicts). However, if there are not only no conflicts at all, but also no *possibility* of conflicts, `git read-tree -m` can do the merge. If this results in potential-merge-conflicts (a conflicted index), it's possible, though nontrivial, to merge individual files. Or, one could modify the Git source to have `git merge` find and handle non-conflicting changes. What, precisely, GitHub and others have done, I can't say. – torek Sep 12 '18 at 23:01