CODEWITHSUNDEEP
github
Sam Hanes
Sam Hanes

Reputation: 303

Why does the "rebase and merge" option in Github create new commit SHAs? Is there an alternative?

I like using the "rebase and merge" option for merging PRs in Github to avoid cluttering the commit history with merge commits.

But I've noticed the following behavior: (from Github's docs)

The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

This seems strange to me since it's not how rebase works from the git CLI. Does anyone know why it behaves this way?

Ideally, I'd like to both a) avoid introducing merge commits and b) preserve the commit SHAs and tags from the feature branch. Is there a way to do this from the UI?

Upvotes: 27

Views: 4233

Answers (2)

DWilches
DWilches

Reputation: 23016

Your appreciation is correct, that's not how rebase works in git. The reason is in GitHub some options are poorly named:

  • Squash and Merge: Is similar to a squash and a rebase
  • Rebase and Merge: Is similar to a rebase with the --no-ff option (and even when the commit is up to date, a new commit will be introduced instead)

And if you are using the "GitHub Desktop" application you should have seen other unfamiliar names like "Sync" instead of "Pull"+"Merge"+"Push".

Upvotes: 9

VonC
VonC

Reputation: 1323075

I'd like to both

a) avoid introducing merge commits

You won't have any merge commit created, since the doc mentions:

all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit.
Pull requests with rebased commits are merged using the fast-forward option.

And:

b) preserve the commit SHAs and tags from the feature branch.

Any rebase (locally or remotely on GitHub) would change the SHA1 anyway (since a rebase, by definition, changes the base parent commit).
As Mondkin helpfully comments, a rebase made on top of an ancestor commit leaves the commits alone.
If GitHub still does change the SHA1, that means some other metadata (date, or comment) is changed for GitHub to reflect/record that operation, and make sure it is visible (as opposed to a local repo, where a rebase on top of a local ancestor is a no-op: nothing happens).

Upvotes: -2

Related Questions