GitLab offers to create personal access tokens to authenticate against Git over HTTPS. Using these tokens is a secure alternative to storing your GitLab password on a machine that needs access to your repository. It is also the only way to automate repository access when two-factor authentication is enabled.

However, GitLab does a poor job documenting how you actually use these tokens.

Create an Access Token

Navigate to “User Settings” > “Personal Access Tokens” and enter a name and, optionally, an expiration date:

Read and write access to the repository should be sufficient for many use cases, but you can also pick additional scopes. Create and copy the token and save it at a secure location (ideally, in your password manager).

Using the Token at the CLI

This is the crucial piece of information missing in the documentation at this time: You can use the token as the password for the fictional “oauth2” user in CLI commands.

For example, to clone your repository:

git clone https://oauth2:1AbCDeF_g2HIJKLMNOPqr@gitlab.com/yourusername/project.git project

Configure the Token for an Existing Repository

The authentication method of an existing checked out git project is defined in the .git/config file. If you want to use an access token instead of SSH or HTTPS auth for such an existing project, adapt this file the following way:

...
[remote "origin"]
        url = https://oauth2:1AbCDeF_g2HIJKLMNOPqr@gitlab.com/yourusername/project.git
        fetch = +refs/heads/*:refs/remotes/origin/*
...

In many git workflows, all changes to your code should eventually end up in the master branch. You may also have a develop branch which contains code changes that are not ready for production deployment yet.

For some reason or another, you may end up in a situation where your develop has changed so much that you can no longer easily merge it into master. Most of those reasons suggest bad practices, but such a situation may also arise due to changes introduced into your git workflow or deployment process.

One way out of this dilemma is to completely replace master with the current develop. There are two ways to achieve that.

Merge Strategy ‘Ours’

You can use the following commands to merge develop into master using the ‘ours’ merge strategy:

git checkout develop
git merge -s ours master
git checkout master
git merge develop

The resulting master should now contain the contents of your previous develop and ignore all changes in master.

This method’s advantage is that you get a clean merge commit and other developers using those two branches are less likely to experience problems when merging their feature branches.

The downside is that this merge might fail if your develop and master have diverged to a large degree.

Force Pushing

A more brutal alternative is to force push the develop branch under a different name:

git push -f origin develop:master

Using the -f flag, your previous master is completely overwritten with develop, including its history. Warning: this erases all commits from the master branch that are not also in the develop branch.

This solution may be appropriate in your case if you have a small number of other branches and/or other developers. The downside of this approach is that all developers who already have a local copy of the master branch will need to perform a git reset --hard.

Force pushing to the master branch might fail if you use GitLab’s “Protected Branches” feature. You can either make sure your user has proper permissions or disable the protection for a few seconds until your changes are saved.