Support semi-linear history (rebase && merge --no-ff)

[at-ng]

Support the concept of semi-linear history as discussed here isaacs/github#1017 (hopefully with an option for enforcement as well).

Example

[rnestler]

If we require pull requests to be up to date an enable only merge commits we get this behavior, right?

[at-ng]

I can't even enable "Require branches to be up to date before merging" because for some reason it requires a "status check" that my repo does not have. I have setup pull requests with only the merge commit button enabled though (after they made it possible to have pull requests without approvals). So if you have status checks then maybe you can enforce this but it shouldn't be required. Also maybe someone would also like to be able to do it without pull requests (not sure if that's feasible or wanted)?

[bbc2]

I agree, so if you have status checks you should be good with the following sort of configuration:

• In the repository general settings:

• In the protection rules for your main/master branch:

But as you say, if you don't have those status checks, I'm not sure this works. Having a real semi-linear option would be great.

[bbc2]

I forgot to say that you also need to ensure you choose the right "pull request update" action before merging your PR (otherwise you'll end up with a non-linear history):

Since that's easy to get wrong, this is another argument in favor of the semi-linear history feature.

[adamshapiro0]

Yes, sort of. Now that they added the "update branch" button with the option to rebase (https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/), you can use that button + merging the pull request via a standard merge to get the desired effect. There are still a few missing pieces though:

1. The "Require branches to be up to date before merging" option @bbc2 mentioned only works if you have at least one status check enabled (not really clear why). If you do not use github actions on your repo, the option is ignored
2. There is still no way to enforce the linear history -- someone can still do a merge into their branch locally and push that up, making the branch up to date but not linear
   • There is technically a branch protection option to require linear history, but it is only supported for squash merges or the existing rebase merge feature that does not create merge commits
3. There are currently no settings for the "update branch" button, so you can't disable the "update with merge commit" option, or at least make rebasing the default behavior
4. You now have to manually do 2 steps instead of 1

Would really love to see this feature. We exclusively use this merge flow, that way we can enforce a linear history -- easier for bisecting when looking for where an issue was reintroduced, easier to read and follow -- but include merge commits with a summary of all of the changes and important details contained in the branch.

[vhenzl]

Yes, please! This would be super useful. Personally more interested in the ability to enforce it and require PRs to be up to date than in a new button to "rebase and merge" in one click.

[Frederick888]

This would be a really nice middle ground between 'Squash and merge' and 'Rebase and merge'.

IMHO

• Squash and merge: retains no commits of a single PR locally, making main history less bisect-able
• Rebase and merge: makes it harder to figure out which PR a commit is from locally, since we don't have merge commits with PR numbers any more

[sandstrom]

There is a related discussion here, but focused on getting the merge queue to support semi-linear history.

[sandstrom]

An update from a member of the Github team:

[…] We have an internal issue tracking [semi-linear merge now]. I think it's a good suggestion, and maybe something we can bundle with some other merge-related improvements we want to make.
https://github.com/orgs/community/discussions/46757#discussioncomment-4959008

[dpwatrous]

Azure DevOps has a fantastic UI for this in my opinion, which includes animated visualizations for the different merge strategies.

[sandstrom]

They do, it's called "Semi-linear merge" and it's quite popular.

https://devblogs.microsoft.com/devops/pull-requests-with-rebase/#semi-linear-merge

---

This is also in Gitlab, illustrated as follows:

https://docs.gitlab.com/ee/user/project/merge_requests/methods/#merge-commit-with-semi-linear-history

[rnestler]

When I tried that feature it did a rebase even if it wasn't necessary, since the branch was already up to date. This lead to confusing behavior, especially if one refers to commit hashes, since they all get rewritten.

[sandstrom]

Rebase when branch is up-to-date should be a no-op, no?

[Frederick888]

Not necessarily. For example you can git rebase --reset-author-date <base>.

I've never used Azure DevOps so I don't know how it works though.

[rnestler]

When I tried that feature it did a rebase even if it wasn't necessary, since the branch was already up to date.

It seems fixed now in Azure DevOps when I last tried.

[ADTC]

If I set these options, perhaps I can update the pull request by rebasing, before I do a normal merge (creating merge commit), right?

• ON: Allow merge commits
• OFF: Allow rebase merging
• ON: Always suggest updating pull request branches

[ADTC]

If anyone wants to re-create a semi-linear history for a bunch of PRs that were already rebased in linear history, you can do it without changing any of the commits already present.

First checkout a new branch pointing to the commit immediately before the first PR, and then do this on bash for each of the tip commits of the PRs in the correct order (earliest first):

⚠️ The following is a single line (one long line) and shouldn't be copied as multiple lines. ⚠️
SHA=----A---- GIT_AUTHOR_DATE=$(git show --no-patch --no-notes --pretty='%ad' --date=unix $SHA) GIT_COMMITTER_DATE=$(git show --no-patch --no-notes --pretty='%cd' --date=unix $SHA) bash -c 'git merge --no-ff $SHA -m "Merge pull request #----B----"'

• where ----A---- is the commit SHA and ----B---- is the PR number.
• ⚠️ Note: macOS Terminal users need to replace bash with zsh.

Finally, merge your main branch into the new branch with -m "Merge pull requests history" and then checkout your main branch and fast-forward merge the new branch into the main branch. Once you do that for all the PRs, you'll get something like this:

Push the updated main branch.

[at-ng]

If I set these options, perhaps I can update the pull request by rebasing, before I do a normal merge (creating merge commit), right?

You will get a button but by default it will be set to update with merge commit rather than rebase and I don't think there is an option to switch default or disable the merge commit option. Also this is just an option not something that is enforced before completing the pull request.

[julianskartor]

Sorry if this is not the appropriate place to ask, but am I right that this is still not supported by GitHub?

[sandstrom]

Yes, still not supported unfortunately. It's supported by Gitlab and Azure Code Pipelines.

If you'd like it, you can upvote this issue (but you probably already have).

[julianskartor]

Thanks for the reply!

[alchatti]

We have been utilizing this strategy on Azure Repos' free plan and are now transitioning to GitHub Enterprise as part of a team consolidation effort. A key aspect of our workflow involves using an atomic commit strategy, where a single file might go through multiple commits based on its refactoring or the issue it addresses. This allows granular tracking of changes and ensures clarity in the development lifecycle.

In Visual Studio Code, the Git Graph extension offers an elegant way to manage this workflow by allowing us to view merge commits as parents and present history in a linear fashion. When further details are needed, we can expand individual commits from the parent to reveal all associated changes.

Benefits of this Approach

• Clean linear history: Maintains the appearance of a rebased branch without the overhead of rebasing.

• Preserved commit verification: Ensures that commits remain verified even when multiple contributors work within a pull request.

• Streamlined collaboration: Allows multiple developers to contribute to a single pull request efficiently.

• Flexible deployment workflows: Supports more sophisticated enterprise deployment cycles, avoiding the need to squash merge unless required (e.g., for single-commit pull requests).

Our Workflow Rules

Main branch only moves forward, If we need to revert, we open a new pull request to handle the changes.

Git has the capability to traverse through semi-linear merges allows for detailed investigation or selective reverts as necessary. From experience.

Experienced Outcomes of this merge strategy

• Cleaner and more understandable history, even when multiple contributors work on the same pull request. Preserve authorship no squashing or guitar hero history.

• Retains detailed commit history without forcing rebase workflows, causes verified commits to become unverified after pull request merged.

This feature would greatly enhance our experience on GitHub, bringing parity with other tools that already have this feature. Would greatly appreciate it if this becomes a priority. 😁

This is also similar to https://github.com/orgs/community/discussions/4618

[janderssonse]

@alchatti Regarding the issue you refer to. I can't understand the GitHub does just stops creating social videos, cancel all friday hacks, planned other things and just fixes this thing. It is such an core issue, and I would say it is not just an annoyances, it is also a security issue for GitHub. By recreating commits in an unexpected way on rebase, signed commits are.... poff gone.