What makes a Pull Request "rebaseable"

[meenie]

There is an attribute in the Pull Request API request (/repos/<repo>/pulls/<pr_number>) called rebaseable. One of my PRs that needed to be rebased with its base branch had that attribute set to false but doing a simple git pull --rebase origin <base_branch> worked fine locally with no conflicts. What exact conditions make a PR/Branch not rebaseable?

[francisfuzz]

👋 @meenie, welcome to the GitHub Support Community!

Although rebaseable is an available field in our Pull Requests API, how its value is determined isn’t currently documented. I checked internally and see that our documentation team is tracking this (along with documenting other fields, like mergeable_state)––I’ve added your instance there so they can consider it for future iterations. Such information would help other integrators leveraging our Pull Requests API. We’re sorry we can’t share any more context than this until it’s officially documented. 🙇‍♂️

[meenie]

Thanks for the welcome :). And thanks for letting me know! I look forward to reading the documentation once it’s out. Cheers!

[Xavientois]

Once the documentation is updated with information on the rebaseable field, where would we be able to find it?

[svoorakk]

Is the documentation for rebaseable field available now?

[MaheshAravind]

Is the documentation for rebaseable field available now?

[ashishsantikari]

Is there any update on this?

[kmadaminjanova0508]

The rebaseable attribute in the GitHub Pull Request API indicates whether GitHub believes the branch can be cleanly rebased on top of the base branch. The rebaseable attribute being set to false suggests that GitHub's automated systems have determined that a direct rebase might not be possible without conflicts. There may be several issues. For exapmle, there may be conflicts in the code like if there are conflicting changes between the branch you are trying to rebase and the base branch, GitHub will mark the pull request as not rebaseable. Conflicts may arise if changes have been made in both branches to the same lines of code.Changes outside the Git repository or GitHub's rebaseable check only consider changes within the Git repository. If there are external changes, such as changes made directly on the GitHub website or through the GitHub API, that are not reflected in the Git commit history, this can lead to inaccuracies in the rebaseable check.Another issue can be at GitHub Actions or other CI/CD systems I mean If you have automated workflows like GitHub Actions that modify the code during the build or test process, it might introduce changes that are not visible in the Git history. GitHub might not be aware of these changes and may mark the pull request as not rebaseable.Another issue can be at Permissions and Branch Protection Rules for example if there are branch protection rules in place that prevent force pushes, rebasing may be restricted. Also, if the user initiating the rebase doesn't have the necessary permissions, it can affect rebaseability.In your specific case, where you were able to rebase locally without conflicts, it's possible that the conflict resolution occurred seamlessly on your local machine but wasn't accurately reflected in GitHub's automated checks. Additionally, changes in the repository after the GitHub check could have influenced the result.If you're confident that the rebase can be performed without issues, you can proceed with the rebase locally as you did before. Sometimes, the automated checks may not perfectly capture all possible scenarios, and manual intervention might be necessary. Just ensure that you resolve any conflicts appropriately before pushing the changes back to the pull request branch on GitHub. :)