I'm having an issue where GitHub doesn't automatically rebase/merge my pull requests at all, even if commits to master since the PR branch was created don't even touch the same files the PR itself touches, so there aren't any merge conflicts at all.
I know this is possible in GitHub, I've encountered a few repositories myself where PRs don't require a rebase and merge conflicts are automatically resolved.
The repository in question is here.
I've tried going through the project settings but I cannot seem to find a setting that says that this is an issue. Also, if I rebase my PRs manually, it usually happens automatically without me being prompted to resolve any conflics.
This is configured in the required status checks section, found in Settings → Branches → Protected Branches. The relevant setting is "Require branches to be up to date before merging".
If this feature is enabled, and status checking is set to "strict" (it is by default), then
you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
We have a protected feature branch (EPIC) with pull request to master.
That feature branch has conflicts now.
To resolve conflicts we have to open a new pull request with merged master and resolved conflict based on EPIC.
When reviewing the new PR we see all changes from master (which can be really a huge amount of changes) and changes on conflicts.
What we are interested in, is just to review changes on conflicts, not the whole history from master.
Is there a way to hide all changes from master on GitHub and view only resolved conflicts?
Is there any way to replace merge with rebase at GitHub PRs? I looked through protected branches settings but didn't find such option.
GitHub now (Feb. 2022) supports this:
More ways to keep your pull request branch up-to-date
The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch.
This is useful for verifying your changes are compatible with the current version of the base branch before you merge.
Update your pull request branch by rebasing:
When your pull request's branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch.
Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created.
To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch.
Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice.
Note: Because rebasing rewrites the history of the branch, if you are working with the branch locally, you will need to fetch it and do a hard reset to ensure your local branch matches the branch on GitHub.com.
Learn more about keeping your pull request in sync with the base branch.
I doubt github supports this, as you should never rebase a public branch. From the official git docs:
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
The easiest solution would be to simply use a merge. If you don't like that for any reason, you could create a new branch from main, apply the desired changes (e.g. by using git cherry-pick, or git diff in conjunction with patch), and then delete the old branch and create a new PR. If you really want to use rebase, you can do so locally and force-push the branch, but again, that's a really bad idea as it falsifies history and breaks the branch for everybody else.
I am working in my local branch-1 and my colleague works on his local branch branch-2.
He already committed and pushed the branch to his origin/develop and created a Pull request to upstream/develop. So now it is waiting for review and approving the pull request by someone else.
The problem is, in my local branch I need to edit one same file, which my colleague worked on. So my branch and his branch will containe the same file with different code. If his branch would be already in upstream, then I could merge it to my branch and resolve the conflict locally without problems.
However now it is in Pull request status waiting for review and I don't have time to wait, I need to create also my Pull request.
How and when will the conflict be solved, as the file with conflict is in both pull requests now, will git recognize it now or? As those branches are not in upstream yet.
Whichever branch is merged first, the other PR will have a merge conflict that must be resolved. If yours is merged first, theirs will suddenly have to fix a conflict. If their PR is merged, yours will have a conflict.
The PR main page will show the conflict and won't allow it to be merged.
The other answer is the correct one, but I want to add another possible course of action.
If your two separate features need to follow (for whatever business/architecture related reasons) merging order, where branch-1/feature-1 must be before branch-2/feature-2 and also at the same time, you need to create a PR for your feature, then what you need to do is rebase your branch on top of your colleagues branch and create a PR that way.
Once branch-1 is merged, then rebase branch-2 onto the latest upstream/develop. This will force you to resolve conflicts and update the PR accordingly.
It seems to me that you can only see the vulnerable dependencies on the master branch. I fixed those mentioned in the alert on a separate branch and want to check if in fact the vulnerable dependencies are fixed, so what I really need is to be able to check the alert for the specific branch, can this be done?
I had this same issue.
The problem with GitHub's Security Alert feature is that it will always scans the default branch of a repository. This is normally the master branch. Therefore, any changes to resolve security issues made to other branches will not be recognised by GitHub.
The workaround.
You can change the default branch to be any branch in your repository! Including the one you have done the work to resolve the security issues.
On GitHub, navigate to the main page of the repository.
Under your repository name, click Settings.
In the left menu, click Branches.
Choose the new default branch.
Once you have changed the default branch to the branch you have done the resolving work on, GitHub's Security Alert feature will start to scan that branch.
And you should see the security alerts that you have resolved disappear.
Afterwards you can change the default branch back to the master branch and only change it when you are specifically working on resolving security vulnerabilities.
The security alerts for vulnerable dependencies reported by GitHub might be valid only for the default branch (usually master, but you can change it).
If you are not ready to merge your fix to the default branch of your repo, one workaround would be to push that branch to the default (again, usually master) branch of a new dedicated (and temporary) repository, just to check if any new alerts are detected on that new repo.
Update Oct. 2020, 2+ years later: Michael Greisman points out in the comments to this GitHub Community answer and the documentation "About alerts for vulnerable dependencies".
It confirms that the scan is done against the default branch.
"Once the fix... is merged into the default branch... GitHub will schedule a new scan of your project’s dependencies".