As a monorepo grows in size, the performance often degrades. It’s the nature of Git. Thankfully, Git has some settings that you can use to improve the performance of your monorepo. This post covers some of the key settings and best practices for working with large monorepos.

Whether you’re dealing with bad credentials or connectivity issues, there are a few tricks with Git that can make it easier to understand what’s happening. This post will dive into features of Git that you can use for understanding the credential flow and troubleshooting problems.

I like having my SSH commit signing automatically configured. In a previous article, I discussed how you can do this using your dotfiles repository. If you want to add support for reading the SSH keys from 1Password, then there are just a few more things you need to know.

With automation you can simplify many things as a developer. This includes automating the process of configuring commit signing with dotfiles.

It’s not unusual for teams to want to merge the same branch into multiple branches. If they create multiple pull requests from that branch to each of the other branches, they suddenly find that their Checks behave differently than expected and the branches start to share results. Understanding why this happens makes it easy to get Checks to behave as expected.

Monorepos are often seen as the simple solution to complex collaboration and code management problems. Companies like Google and Facebook frequently mention their use of the pattern for their most important codebases, so clearly they have found ways to make these solutions scale to support large teams. What is their secret to being able to successfully use a monorepo, and how do they make it work where so many others fail? More importantly, should you be considering the approach?

Git’s safe directory configuration helps to protect users, but it can create challenges. This is especially true when using Hugo with Azure Static Web Sites. In that case, you’re dealing with an Action that bind-mounts the source code into a container. This requires some special handling.

Git has some interesting behaviors built into it. For example, it makes it easy to squash a set of commits into a single commit. This creates a very simple history. But what happens if that history that you’re eliminating has a tag applied to it? Does that tag get eliminated? Does it point to the newly squashed commit? Today’s article explores what to expect in that situation … and why.

You’re working in a development container. You need access to a port on the host for a proxy SSH connection to a Git server. Sounds tough, right? Turns out it’s simple.

If you need to connect to multiple Git hosts or environments (like EMU and GHEC) with minimal effort, then SSH may provide the options you need to make it painless.