Git: Apply Changes from Branch as Unstaged Changes

Sometimes I want to quickly save some code changes that I am not ready to commit into a real branch. For example, I might be in the middle of a long refactoring and there is a complete mess that I do not want to show up in version control history:

Git has the “stash” command which removes all uncommitted changes and saves them to a local data structure where they can be retrieve later. However, this comes at the disadvantage that stashed changes only live in your local environment – they cannot be synced to tools like GitHub or GitLab.

This is fine for small changes, but when you really need to make sure to keep your changes, there is a more permanent solution that also does not pollute your version control history.

Save Changes

You save your changes by committing them to a “dirty”, temporary branch (let’s call it temp_refactor:

  • git checkout -b temp_refactor
  • git add .
  • git commit -m "some trash commit"
  • git push

Your changes are now reflected in the temp_refactor branch and can be pushed to a remote repository.

Load Changes

When you are ready to continue, change to the branch you actually want your changes to end up at and do the following:

  • git checkout feature/my_normal_feature_branch
  • git checkout temp_refactor -- .

All your changes are now back as unstaged changes and you can continue your work.

GitLab: Authenticate Using Access Token

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/*
...

 

Git: Overwriting ‘master’ with Another Branch

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.

Improve GitLab Pipeline Performance with DAGs

Directed Acyclic Graph (DAG) style dependencies between individual stages in a continuous deployment pipeline allow for a more flexible workflow and better utilize available computational resources.

Imagine a simple pipeline consisting of three jobs:

  1. A syntax check
  2. A code complexity check
  3. Running all unit tests

You may be tempted to group those in two stages: A) Build (consisting of jobs 1 and 2) and B) Test (consisting of the unit tests):

Traditional Sequences

In plain old GitLab pipelines, you would define that stage A needs to execute before stage B and everyone would be happy.

Except if the syntax check is quite fast (let’s assume 30 seconds) while the code complexity check may be very slow (say 4 minutes). Then, the unit tests need to wait a total of max(30 sec, 4 min) = 4 minutes before they can be executed, resulting in an overall slow pipeline:

Continue reading

How To Publish Your PHP Code as a Composer Package

How To Publish Your PHP Code as a Composer Package

Easily share your code with the PHP community by contributing your library as a composer package: This article will show you how to publish your code on GitLab and as a package on packagist.org.

Writing Your PHP Code

Publishing open source code has never been easier. Using PHP’s package manager composer, thousands of freely available packages are only one composer require away.

Believe it or not, but there exists an npm package named “is-odd” with over 700,000 weekly downloads. Its sole purpose is to “compute” whether a number is even or odd. For this tutorial, we will replicate this essential functionality as a PHP package.

Continue reading

Vue.js on GitLab Pages

This article describes how to setup a continuous integration pipeline in GitLab for your Vue.js app. Learn how to automate your deployment to GitLab pages in a few easy steps.

GitLab pages is a great way to host simple web applications and is easy to integrate into GitLab’s continous integration (CI) pipeline.

Continue reading