Why I was ready to pay for a Git client

Stefan Antal — Tue, 10 Nov 2020 15:31:02 +0000

For years, I've been using Sourcetree as my go-to-tool for all Git related actions and repository management. It did all I could wish for and I couldn't imagine why someone would pay for a Git client. Until I stumbled across GitKraken (https://www.gitkraken.com/)

- Picture taken from GitKraken's website.

My workflow

To understand why I changed my mind, it might be interesting to understand, how I work.

Here's a standard workflow, I usually follow:

At my work, we use GitLab / GitHub for code management and pipelines and often feature branches to structure the way teams work. Pretty standard, no special things here ✌️.

To finish a piece of work, I usually have to work with three tools: Sourcetree, GitLab, and Jira (not shown in this picture).

The context switches between these tools were never something that bothered me. I always thought that this is how it is to code nowadays. In conversations with my colleagues, I've heard that some used a different Git client (like GitTower https://www.git-tower.com/mac) and so I stumbled across GitKraken during a Google search. Due to a recent change in their pricing structure, I was ready to give it a spin, and oh boy, did this tool go to town (with me).

My new workflow

After I learned about some of GitKraken's features, my new (improved) workflow looks like this:

First of all, I can stay in my Git tool to create merge requests. Can we just pause for a second and process this? It doesn't feel like much but go dare and try. It's wild 🔥!

Secondly, I can still stay in my Git tool to see the issues which are assigned to me in Jira, change them, and move them in their workflow.

If that doesn't get you off your seat and have you throwing money at this tool, I'll throw in an epic undo/redo feature which lets you reverse and redo actions (I already see the comments, where you complain that you can't take back a commit after you've pushed it. It doesn't change Git. It supports you). With the undo feature, I don't have to look up reset commands any more or do hard resets because it's sometimes cumbersome to reverse an action (Yeah yeah, it's good to know what's happening under the hood, I got you. I've been under the hood when I started with the terminal for the first couple of years. I'm entitled to have some nice things in life, ok?).

The result

"A whole new wooooorld...". At least it feels like it. I brought my contexts down from three to two and profit from other sweet features like:

Multiple profiles (in sync with your .gitconfig)
Great merge conflict editor (no more "mine" and "theirs" 🤷‍♂️)
Fast, responsive UI
Auto-Stashing at merge conflicts

and many more.

Dear Santa...

Now, if I could just bring my contexts down to 1 (!)... I found out that this context thing really grinds my gears or at least hinders productivity. I've talked with Axosoft (the company behind GitKraken) and they have more GitLab support on their board and +1ed it for me. Always talk with the companies and let them know what you need. Maybe it pays out someday.

And just because it reads like a paid article: it’s not. I’m just hyped 🙈

Happy coding!

Git Configuration Reuse

Stefan Antal — Mon, 12 Oct 2020 20:41:10 +0000

This post has been written from the perspective of a macOS user.

Working for an agency has its perks. Diverse & interesting people, less bullshit & more doing, working for different clients, and so on. Especially the “working for different clients” part can have its challenges, though.

One is that with some clients, we need to use external email addresses provided by them. Not just for communication but also for more technical things like logins and Git commits.
I want to show you a neat trick to manage your different configurations for Git easily and comfortably.

The Situation

Git manages some meta information in the global .gitconfig. Here’s mine:

The global user configuration is under [user] and sets the name and email for Git. This will be applied to all my Git projects if there’s no local configuration, which overrides it.

Let’s imagine that with the fictional company “acme labs”, we would be required to use external accounts provided by the client. If you’re not careful, you will end up with commits like this:

The easy Fix

You probably know that there is a global Git configuration that will be applied to all your projects if not overridden by a local configuration.
It resides under ~/.gitconfig. You can set its values by editing this file or by the git config command with the --global option.
For your user and email, that would be:

git config --global add user.name “Stefan Antal”
git config --global add user.email “Stefan.Antal@sinnerschrader.com”

In this way, you can also set local Git configuration options by removing the --global flag.

Switch to your project folder (for me this would be ~/code/acme-labs) where you have your .git folder and run the commands without the --global flag:

git config add user.name “Stefan Antal (external)”
git config add user.email “Stefan.Antal@external.acme.labs”

This will add your project-specific user and email to .git/config.
All values present in this file will override its global counterpart for this project.

This is all perfectly fine if that’s all you need.
But what if you would like to reuse some values multiple times?

The sophisticated Fix

You can include files from all kinds of places into your Git configuration. I like to gather my different configuration files in a common-place like ~/git-configs/.

Let’s create a file that we call acme-labs (the name doesn’t matter) inside our git-configs folder.
I create a config file for each project which needs to have a separate configuration.

The content of acme-labs will be this:

Now we need to tell Git to use this configuration when we’re working for acme-labs.
To achieve this, we’ll use the includeif option inside our global Git configuration.

Modify your global Git configuration (~/.gitconfig) by adding following content:

[includeIf "gitdir:~/code/acme-labs/"]
        path = ~/git-configs/acme-labs

gitdir shall point to the folder where your local .git folder is.
path shall point to your newly created Git configuration for acme-labs.

The result should look like this:

Git will recognize when you’re working inside ~/code/acme-labs and use the values you defined under ~/git-configs/acme-labs.

In this way, you only have to add a new includeif per project inside your global Git configuration and link it to one of your configuration files.

Your next commit will now look like this:

However, if you also have regular local Git configuration, which you have added with git config add, it will be used instead of your ~/code/acme-labs configuration.

Forem: Stefan Antal