I would like to configure my github repository such that I can receive security alerts if a vulnerability is detected on any branch, not just the master branch. Does anyone know how and where to make this configuration.
The workflow we use to introduce new changes to our project is the following
Create a feature branch to develop a change
By way of pull request, merge the feature branch changes into a develop branch
Build a test instance of the application from the develop branch
Verify the change in the test instance
Cherry pick the change from the develop branch.
Deploy the production instance from master branch
in a recent change we introduced a security vulnerability and we only received a github alert when the change was cherry-picked to the master branch. Can I configure github to do security scans on all the branches, or perhaps the develop branch along with master?
It looks like my question was previously asked, and there is an answer here: github vulnerable dependencies per branch
GitHub security scans occur on the default branch of a repository.
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.
How can I lock a github develop branch so that no one can merge PR (even if PR approved) until I unlock the branch? This is needed because I want to create a release branch, out of develop and restrict unintended merge until branch out. I went through branch protection rules and it does not serve my purpose i.e. there is no option that says lock/unlock a branch.
Explanation:
I have a develop branch and developers can create feature branches from develop branch and raise PRs, and once PRs get reviewed and get approval, developers can merge their PRs to develop. Now, I want to create a release branch from develop so I want to restrict all the developers to be able to merge their PRs to develop branch even if PRs got approved. It may take a few days to create a release branch because whatever code I have in develop branch, I want to test and by this testing time, I want to lock the develop branch, so that no one can merge their PRs into develop branch. Once testing successfully done, I will create a release branch from develop and I will then unlock the develop branch, so that, from now on developers can merge their PRs to develop branch.
You can create a branch at any time from any commit, there is no reason to lock an active branch and prevent people from working.
git checkout -b <new branch name> <commit hash>, then git push.
This functionality is not available in git itself. This can be handled by whichever server you use to manage the repo. See Managing a branch protection rule # Github. You can set rules by branch name or pattern and require a PR to merge to that branch. You should also be able to set who can merge and other rules related to branch management.
Since Oct. 2022, you actually can lock a branch:
New Branch Protections: Last Pusher and Locked Branch (Oct. 2022)
Push protection enabled.
This allows for branches to be locked, prohibiting changes.
You can lock a branch allowing you to have a maintenance window and prevent changes, or to protect a fork so it only receives changes from its upstream repository.
To use this feature in a branch protection rule, enable Lock branch.
So:
How can I lock a github develop branch so that no one can merge PR (even if PR approved) until I unlock the branch?
The documentation does include:
You can enable this setting to apply the restrictions to admins and roles with the "bypass branch protections" permission, too.
I've got a repository with my develop branch protected and I'm using the GitFlow branching model. There's two branches; develop (containing features currently being developed) and master (latest deployed production code).
My develop branch prevents commits being directly made via GitHub's Protected branches. When you locally finish a hotfix using GitFlow, it automatically merges the hotfix branch into your local master and develop branches. However, pushing changes directly on the develop branch are not permitted as this is a protected branch
How can you overcome this? At the minute everytime I am creating a hotfix I have to:
Manually turn off the branch protection
Push the develop branch
Turn it back on
This is not automated and therefore, not really acceptable.
Are you the owner of the GitHub project and do you have the administrator role setup with your account (or can you grant administrator access to your account)?
In this case I would recommend you not to protect the branch for administrators. This way you can guarantee that other persons are not pushing directly to develop, but all "knowledged devs" with administrator access are able to. They should be aware of what they are doing, though.
You can edit this behaviour under https://github.com/${name}/${repo}/settings/branches/. My settings do look like this (the last checkbox is important):
Note: maybe you could also use the "Restrict who can push to this branch" option.
Enable 'Require pull-requests' on GitHub.
After you merge the hotfix in your local master you can create a hotfix branch from it, to create a pull-request in origin. Your master will be different, but you can reset and stash and pull in the origin/master.
git checkout -b hotfix
git push origin hotfix
# merge
git checkout master
git reset origin/master
git stash
git pull --rebase
Caveat: I am fairly new to both git and GitHub.
So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:
Pull latest from master
Start hotfix
Commit changes
Merge hotfix branch into both master and develop and push both upstream
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
CI hooks to run tests and stuff
a place to put code-specific comments not directly related to the underlying "issue"
avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes
But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.
Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.
As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.
I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.
My recommendation would then be the following:
Create one PR from hotfix to master and have someone review it to validate the fix
Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
If there's no merge conflicts, then have someone review the PR
An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.
The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.
It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.
I have a master and a development branch in Github and the repository is configured to sync changes to AppHarbor. I configured the master branch as specified at the support site.
Is there a way that I can isolate the development branch and only push from the master branch?
AppHarbor will build all branches which is great for Continious Integration purposes. You can specify what branch to deploy off by setting the tracking branch.