I recently read this post from my colleague Marnix on using Dev Containers to isolate your service logins for a project . This is especially useful for Azure and GitHub accounts, as they are configured per system in the ~/.azure and ~/.config/gh folders.
As a consultant, I’m often hopping between multiple customers. Even someone working solely for one company might have side projects in different environments. This system configuration is often suboptimal and requires you to think about where you’re logged in and switch around. Marnix has done a great job describing why Dev Containers are a great solution to this problem, so I won’t repeat that here.

One annoying aspect is working with worktrees. Currently, coding agents default to Git worktrees, so you can work on multiple things at the same time without conflicts. This is great, but they create a copy of the repository in a random folder. This also creates a new Dev Container for you to use, which means you have to log in again. Having to log in to every Dev Container is quite cumbersome, and I don’t like that.
What I want is a shared login for my repositories that works for all the worktrees I have.
After playing around with this feature, I found out that this is quite possible!

I have been a long time user of Tailscale , a very easy to use VPN mesh system, to connect to my home network when I’m not at home. There are other solutions, like NordVPN Meshnet , but I learned about Tailscale first. It’s especially useful when using your local DNS (PiHole) and taking advantage of the sites blocked by it.

Currently, I’m in the process of self-hosting services a bit more. Relying in (free) cloud services that might be turned on/off at a moment notice or removing features I use is something I’ve seen happen a bit too much lately.
Because of this, I’m running a container of Linkwarden to act as a ‘Read it later’ or bookmarking service. I was using Omnivore for this, but that service got shut down at some point.

Some of the links I store in Linkwarden might also be interesting for others who might have missed them. I wanted to get a list of these links and share them on my site, which is why there’s now a Weekly Links Archive . These pages contain all links I find interesting enough to share over here.
Because I’m a firm believer in automation, these pages are created via a GitHub Action workflow.

It so happens a lot of people are mixing their work- and personal development machines, especially when doing side projects in their spare time which are somewhat work-related.
At least, this is the case for me as I’m using GitHub both for work & personal stuff nowadays.

On my personal machine, I’ve set up Git to work with my personal e-mail address & SSH keys.
On my work machine, I’ve set it up to run with my work account.
Because of this, whenever I commit a change this configured account will be used and I don’t want my corporate account to show up in my side projects, and vice-versa.

Lucky for me, there are a couple of people on Stack Overflow who have similar setups and were also wondering how to fix this. I’m quite happy with the answers posted to Kevin Whitaker’s question .

There are answers on how to do this with SSH keys , which is probably the best option.

However, most repositories on my machine are set up with HTTPS, so the answer from Greg Leszek is the best for my scenario.

He mentions that you first have to change the origin URL to have your username in the URI if this isn’t the case already.
Afterward, you can set the user details you need to use for this repository.