Skip to content

Allow to force push option for protected branches

Problem to solve

While preventing force push is generally best practice, there are certain exceptions that currently cannot be configured. Currently, maintainers can remove branch protections to allow temporary force push, however, all settings for the previously protected branch in question are lost. Finally, users migrating from competing services who made use of this feature have a break in their workflow. Notable use cases for this feature:

  • Production incidents that require pushing an immediate fix, bypassing previously configured rules
  • POC projects where an owner would want to always be able to force push to master
  • Prevent force push for most branches except those matching a pattern, ie wip-*

More use cases on the #use cases section.

We should provide a more convenient way to allow force pushes for specific users/groups on protected branches.

Proposal

Add a new Allow force push toggle on the protected branches section, which will enable force push for any roles/groups/users defined in the Allow to push section.

image

Proposed tooltip text: Allows force push for users with push access.

Important note regarding Protected branches API: When protecting a branch via API and setting the unprotect_access_level to admin (60), only admins should be able to change the new Allow force push setting (like all other branch protection settings).

Previous proposal 2 Allow project maintainers and owners to define which users/groups are allowed to force push to a protected branch. `force push` option is only available for items which already are allowed to push. For example:
  • Step 1, define which roles/groups/users are allowed to push

image

  • Step 2, once roles/groups/users have been defined as allowed to push, "allow force push" option shows next to each item on the list

image

Previous proposal 1

Add a new setting on protected branches called 'Allowed to Force Push' which would enable maintaners/owners to define which user/groups have this elevated privilege.

image

  • Add field Allowed to force push to the Protect a branch form
  • Add field Allowed to force push to the list of protected branches
  • Fields should behave as follows:
    • Field should be defaulted to No one
    • Clicking the field should open a dropdown selection
      • Dropdown should allow the user to select one or more roles (or No one)
      • Dropdown should allow the user to select one or more groups
      • Dropdown should allow the user to select one or more users
      • Dropdown should allow the user to search users
      • Selecting an option should mark the option as selected and update input field
      • Clicking an already selected option should unselect it
      • Selecting No one should remove other role selections
      • If No one is selected, clicking should not remove selection
    • Clicking outside the dropdown should close it
    • Input should display selections
      • If a single role is displayed, display the role
      • If more than 1 role is selected display N roles
      • If one or more groups are selected, display N groups
      • If one or more users are selected, display N users
      • If a combination of roles, groups, and/or user are selected display N users, N groups, N roles
  • Protected branches should allow roles, groups, and users to perform a force push according to the selections made

Customers:

Links

This was originally proposed in gitlab-ce#20550

Use cases

  1. Doing a revert of code on the master branch and the getting develop branch back in sync with master, this is currently done via a force push. Ideally this would be done by automation when the scenario happens and a service account would have this access.
  2. Small teams (ie agencies) where owners want to quickly resolve conflicts themselves and they are the only maintainers on the project.
  3. Situations where a mistake (ie wrong git command) wreaked havoc and cost the teams hours to resolve. During postmortem agreed that force push should have been used to recover and analysis taken place later. Maintaner was not available until after the incident was resolved and the time was lost.
  4. Multiple branches must be synched with master. A lot of these are experimental and have a dedicated owner, currently, owners must unprotected, force push to sync with master, and then re-protect. The setting here would save time.
  5. Training using GitLab pages. Students use a pre-created branch, experiment with changes. When the next class is ready, I'd like to sync other branches with master by force pushing.
  6. Corrupted git repo. There is a missing tree, which can be fixed by force push to the previous commit and trying again. There are other ways to fix this, but this is the fastest an when pressed for time is a good option to consider. Especially helpful when maintainer is not availble to change repo settings but dev leads with "developer" role could do this.
  7. Use of protected master to deploy to production, and we want some members to be able to force push master to point to the head of the staging branch
  8. Org where all branches are protected but all WIP branches (using pattern on branch name WIP-*) allow force push.
Edited by Daniel Gruesso