4

For my current one-man project I'm doing PRs on GitHub directly (rather than Bitbucket or Azure DevOps). I want my two branches to show they are the same after merging, but I've not found a merge option that will do that.

Merge commits and squash commits aren't in the feature branch so GitHub informs me the destination branch has "recent changes" and encourages me to make a PR to bring those into my source branch (which is where they came from).

I just switched over to the rebase option and merged a PR with four commits, but that has issues too since the commits have different SHAs. GitHub still says the destination branch has recent changes and that it's four commits ahead and four behind, and those commits cause conflicts for future PRs.

I'm curious if this is unavoidable with GitHub merging or if there's a setting or other option I'm missing.

Jeremy Schultz
  • 579
  • 1
  • 6
  • 26
  • Are the 2 branches both long-lived branches? If you have a `main` branch and then short-lived feature/topic branches that branch off of and merge back into `main`, you can just delete the temporary branches after the merge is done. If they are both persistent branches, what is the purpose of the second branch? – TTT Aug 11 '21 at 21:46
  • @TTT, one is a version branch with my main work and features and the other is an integration branch that GCP builds off of when it detects changes. – Jeremy Schultz Aug 11 '21 at 22:04
  • Do you commit to both, or do you only commit to `features` and then PR it into `integration`? If you sometimes commit to `integration` also, then this statement isn't always possible with a single PR: "I want my two branches to show they are the same after merging". You'd have to turn around and merge back the other way too. – TTT Aug 11 '21 at 22:11
  • I commit only to `v1` and then merge to `test` or `deploy` branches for test or prod environments. So there won't be two-way merging like you described. – Jeremy Schultz Aug 11 '21 at 22:26
  • Sorry- I think since your last comment didn't tag me, I didn't see it until today. I took a stab at answering your question. – TTT Feb 21 '22 at 18:38

1 Answers1

3

tl;dr: You (currently) can't do this on GitHub, at least not directly using the web interface. See option #3 below for the workaround.

The reason is there is no option (yet?) for a fast-forward merge on its own. GitHub does have an option for "rebase and fast-forward", this strategy always does the rebase even when it wouldn't be necessary. (Note this would be like issuing the command git rebase --no-ff.)

So what can you do? Here are some options that might make sense for you:

  1. You can use the regular merge strategy which creates a merge commit, and change your definition of "the same" in the context of "I want my two branches to show they are the same after merging" to mean there is no diff instead of the commits being the same. For example, git diff A B is empty when the branches are "the same".
  2. You could use "rebase and fast-forward", and then delete (or reset) the source branch! You can still diff what the source branch's tip commit was with the target branch's new commit after the merge, to make sure it's the same, but perhaps you don't actually need the old commits on that source branch anymore. Either delete it and re-create it with the same name if you like that branch name, or just reset it to the new commit and force push it next time.
  3. Apparently, on GitHub, you can do a fast-forward merge from the command line and push it out, and still bypass branch protection if a PR for that same merge exists, and if all the PR status checks have passed. More info here.
TTT
  • 22,611
  • 8
  • 63
  • 69