Specify who can force push to a repository

Instead of allowing all or no users to force push, admins can now be selective about who can force push to a repository.

The image below shows how in the past, admins could use a branch protection rule to allow force pushes for everyone or no one, including admins:

Branch protection rule to allow everyone or no one to force push

This all-or-nothing approach didn't support limiting force pushes to select users or teams of an admin's choosing. For example, you might have wanted to allow only a few people to force push, or you had an automated process that solely needed to force push.

Now, you can be specific about the people and teams who are allowed to force push. As shown in the image below, select Allow force pushes and Specify who can force push. Then, search for and select the people and teams who should be allowed to force push.

Branch protection rule to allow everyone, no one, or select users or teams to force push

For more information, visit Managing a branch protection rule.

GitHub Actions: Improvements to GitHub Actions starter experience

Getting started with GitHub Actions just got easier! Now, when you want to create an Actions workflow in the Actions tab of your repository, the workflow recommendations will be based on repository analysis that detects elements, such as programming language, build tools, frameworks, and package managers.

For example, if a repository contains a Node.js application that has been containerized, then the repository analysis will prioritize showing you container and Node related workflows.

We have also extended recommendations to the deployment category.
and added search and filters to help you find the right workflow that matches your unique requirements.

Learn more about this GitHub Actions improvement.

See more

GitHub Pages: using GitHub Actions for builds and deployments for public repositories

Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories. This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository. As the name suggests, it builds and deploys your pages site. The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users. However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.

You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages. For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.

Learn more about GitHub Pages

See more
View all changes