DEV Community: James Abreu Mieses

Improving Your Productivity With Git Worktrees

James Abreu Mieses — Sat, 11 Jan 2025 18:46:19 +0000

Working on applications and services with many moving parts is hard and time consuming: you might be responsible for long running test suits. You might be responsible of peer reviewing multiple Merge Requests at a time or even, you might be responsible of fixing a critical bug found in production that can't wait. These are all scenarios we have faced before and have used git-switch to help move between branches. However, this is very limiting since you can only work on one branch at the time and your dev environment will have to change across branches. There is a better way.

What is Worktree

git-worktree is a way to work on multiple branches at a time in a non-blocking pattern. We can checkout multiple branches and we can open each on it's on Integrated Development Environment (IDE) or Code Editor.

# Checkout a new branch based on the current branch
git worktree add /path/to/new-branch

# Way to create a new branch where branch and dir name are different
git worktree add /path/to/branch -b my-new-branch

# To work on an exisiting branch
git worktree add /path/to/branch existing-branch

# Deliting a worktree
git worktree remove /path/to/branch

Git worktrees are synced to the main repo (where the checkout) happened which means we can manage them from there. Further, object references (refs) are also shared across the main worktree (repo where the checkout happened) and other worktrees.

Important

Git manages the worktrees for us. This means that it maintains metadata to remove and cleanout stale worktrees. To avoid this, we have to use the lock feature of worktree and/or configure the git-gc (Garbage Collection) utility.

git worktree add /path/to/new-branch --lock

# Or

git worktree lock --reason "I am not done with you" /path/to/new-branch

So, now that we know how to create a new worktree, how can worktree help us where switch can't?

Switch VS Worktree

Checkout Process

git-switch

# git-checkout
git add .
git commit -m "Committing before moving to another branch"
# git push -u origin current-branch

# Checkout a new branch based on main
git switch -c hotfix/broken-link main

# Or
git add .
git stash
git switch -c hotfix/broken-link main

git-worktree

# By default, worktrees checkout the new branch from the main branch unless specifid otherwise.
git worktree add ../urgent-fix --reason "To fix a broken link in our UI" --checkout hotfix/broken-link

We can reduce the amount of time we take to get started on the new branch as we don't have to stage or commit anything.

Non-Blocked Workflows.

Because you can only checkout one branch at a time with git-switch, if you are running for example, a deployment , you can't make changes to the source code without risking introducing syntax errors that the deployment command line interface (CLI) will pick up and crash the deployment.

git worktree add ../deployment-test --reason "To test my deployment for failure" --checkout my-working-branch

make -f ../deployment-test/Makefile

Using worktrees allows us to delegate the deployment testing to another worktree with our working branch checked out while we can continue to work on the current copy we are on in the main worktree.

Quick Experimentation

Using git-switch to set an experimentation branch can be time consuming and expensive as mentioned before. Additionally, if we are experimenting with new packages and configurations, these are things that are not usually tracked and are added to the .gitignore file to avoid accidental commits. To avoid these issues, we can leverage git-worktree.

# Checkout a throw-away branch for a quick experiment
git worktree add ../my-experiment --checkout working-branch --detach

# Remove the branch when done 
git worktree remove ../my-experiment

Conclusion

As developers, we are always moving fast and living dangerously. It is always a positive when we can find ways to help us continue to do so with reduced risks. Git worktrees is a great way to speed up your workflow and experiment in a non-blocking, non-destructive manner.

Hope you found this guide useful and as awesome as I did.

References

Using git Conditionals to Manage Your Git Identities

James Abreu Mieses — Thu, 09 Jan 2025 03:58:26 +0000

As developers, we have to maintain multiple credentials to authenticate and sign our code changes before pushing to remote. This is used to be simple: just use the https endpoint offered by the remote git repository provider, authenticate with our email and password and call it a day. However, now a-day, git remote providers are moving to enforcing SSH authentication which provides a host of benefits out of the scope of discussion for this blog. On this one, we are focusing on how can we leverage git conditionals and ssh to manage our credentials.

The Old

Image you have created your public and private key pair and configured the ~/.ssh/config file to map your private key to the ssh host of your git provider.


Host ssh.gitlab.env-1

  PreferredAuthentications publickey
  IdentityFile ~/.ssh/internal-gitlab
  AddKeysToAgent yes
  UseKeychain yes

We then move to configuring our ~/gitconfig file to tell git to use SSH as the signing key and authentication key for our repo.


[gpg]
  format = ssh
  
[user]

  name = James S. Abreu Mieses
  email = email@email.com
  signingkey = /Users/abreuj/.ssh/internal-gitlab.pub

[core]

  editor = neovim
  excludesfile = /Users/abreuj/.gitignore_global

[commit]

  gpgsign = true
  template = /Users/abreuj/.stCommitMsg

...

It looks great if we are simply pushing to a single repository and nothing else. With this configuration we will be able to both authenticate and sign our commits.

But, what if we have a second repo to push to? Or maybe a third? How would we manage this? We would have to repeat the steps of generating our key pairs and add the private key and ssh domain to the ~/.ssh/config file.


Host ssh.gitlab.env-1

  PreferredAuthentications publickey
  IdentityFile ~/.ssh/internal-gitlab
  AddKeysToAgent yes
  UseKeychain yes



Host ssh.github.com

  PreferredAuthentications publickey
  IdentityFile ~/.ssh/personal-github
  AddKeysToAgent yes
  UseKeychain yes

Easy. Now, You will be able to push to the new repo under the ssh.github.com host. Which is great for authentication. For commit signatures on the other hand, this will not work because we have already configured our git identity to use internal-gitlab.pub for commit signatures. So the commits pushed to the github repo will end up being unverified which means the signature is not trusted.

The initial option here is to again configure the ~/.gitconfig file to use the personal-github.pub private key for signatures. This will work, but when we go back to pushing changes to the gitlab repo, we will go back to having the commit signature not be verified by the provider. So now what?

Use Git Conditional

To solve this issue of having to manually configure our git identity to use the correct public key to sign our commits, we can use git' includeIf to load an identity based on some condition. Here is an example using our initial config:

[gpg]
  format = ssh
  
[user]

  name = James S. Abreu Mieses
  email = email@email.com
  signingkey = /Users/abreuj/.ssh/internal-gitlab.pub

[core]

  editor = neovim
  excludesfile = /Users/abreuj/.gitignore_global

[commit]

  gpgsign = true
  template = /Users/abreuj/.stCommitMsg

[includeIf "hasconfig:remote.*.url:git@github.com:*/**"]
    path=~/path/to/github-iden

On the new config, we are including the git includeIf telling git to load the github-iden config if the repository we are in has a remote url under the ssh.github.com host. If this is not the case, continue using the default identity.

[user]

    name=James S. Abreu Mieses
    email=another@another-email.com
    signingkey=/Users/abreuj/.ssh/personal-gitlab.pub

For here on, we will be able to authenticate and sign our commits using the correct credentials for the repository we are trying to deploy.

Conclusion

Git conditionals are a game changer when it comes to automating identity selection for a give repository. Hopefully you find this article and git conditions as awesome as I did.