It’s best practice to prevent force push on Git repos, but exceptional cases may occasionally require it. Then click on 'Unprotect' or 'Developers can push':Īlternative solution, with GitLab 13.11 (April 2021) Force push option for protected branches Project: 'Settings' → 'Protected branches' (if you are at least 'Master' of given project). Go to project: 'Settings' → 'Repository' → scroll down to 'Protected branches'. Similarly to GitLab 9.3, but no need to click 'Expand' - everything is already expanded: Or you can click 'Unprotect' to completely remove protection from branch. Now you can select who is allowed to merge or push into selected branches (for example: you can turn off pushes to master at all, forcing all changes to branch to be made via Merge Requests).

I'm not really sure when this change was introduced, screenshots are from 10.3 version. Go to project: 'Settings' → 'Repository' → 'Expand' on 'Protected branches' With this setting on, protection will be limited to rejecting operations requiring git push -force (rebase etc.) Since GitLab 9.3 On the same settings page you can also allow developers to push into the protected branches. You can turn on and off protection on selected branches in Project Settings (where exactly depends on GitLab version - see instructions below). master branch is protected by default - it forces developers to issue merge requests to be validated by project maintainers before integrating them into main code. By default only Maintainer/Owner users can commit to protected branches (see permissions docs). In GitLab some branches can be protected. ~/github/rentap.js M % git pushĮnter passphrase for key '/home/colin/.ssh/id_ecdsa':įixed it by putting -am where I usually do: ~/github/rentap.There's no problem - everything works as expected. ~/github/rentap.js M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'Įrror: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git. Turns out, it was an error message because I forgot -am. I was working on autopilot with git commit and git push, and hadn't read the output from git commit. If you have no idea why you would have a detached head, then you probably don't. My mistake was different than everything so far mentioned. You have to specify the destination branch, since the source is not a branch, and does not have an upstream target branch. While git push says 'everything up-to-date', you still can technically push a detached HEAD, as noted in the comments by Jonathan Benn git push origin HEAD:main If you did this by mistake, you can ask the reflog for HEAD where you were, e.g. git checkout master), and a later git prune or git gc would garbage-collect them. What this means is that you can discard your temporary commits and merges by switching back to an existing branch (e.g. The state you are in while your HEAD is detached is not recorded by any branch (which is natural - you are not on any branch). You can even create a merge by using git merge $othercommit. You can make changes and create a new commit on top of a detached HEAD. You can use git reset -hard $othercommit to further move around, for example. You can use all git commands while in this state. The most obvious example is to check out the commit at a tagged official release point, like this: $ git checkout v2.6.18Įarlier versions of git did not allow this and asked you to create a temporary branch using the -b option, but starting from version 1.5.0, the above command detaches your HEAD from the current branch and directly points at the commit named by the tag ( v2.6.18 in the example above). It is sometimes useful to be able to checkout a commit that is not at the tip of one of your branches.

# reset your branch head to your previously detached commitĪs mentioned in the git checkout man page (emphasis mine):

Warning: the following does a git reset -hard: make sure to use git stash first if you want to save your currently modified files. Indicating that your latest commit is not a branch head. Are you working with a detached head by any chance?

Sourcetree force push not working