Leverage git worktree to parallelize work with Codex, Claude Code, etc.

Quentin Lerebours — Wed, 18 Feb 2026 11:31:44 +0000

Over the past two weeks, I’ve noticed a huge shift in how developers work.
We’re becoming orchestrators, guiding code assistants like Codex or Claude Code to build features and fix bugs.

If you haven’t seen it yet, it’s even possible to work on several features in parallel,
on their own branches, without cloning the project multiple times.

Behind that workflow is a Git tool that’s often overlooked: git worktree.

I’ll walk through how this feature works so you can efficiently parallelize multiple tasks on the same project.

1. Understanding `git worktree`

The problem

In a traditional Git repository, you have:

the source code in a working directory: /Users/qlerebours/Projects/traveledmap for example.
a checked-out branch: feat/my-main-feature.
the .git folder that contains the project history.

Switching branches changes the files in your current directory, so how do you take advantage of tools like Codex and
Claude Code to work on multiple features in parallel?

One solution we can rule out is cloning the project into a second folder. The reason is simple:
cloning twice means two .git folders (which can be large), and the whole point of git worktree is to replace manual
clones.

What `git worktree` does

git worktree lets you attach multiple working directories to the same Git repository while keeping a single
shared history (.git).

For example, when I want to add missing form validations in parallel:

git worktree add ../traveledmap-fix-wording fix/add-form-validations

Here’s the state of the folders after running that command:

/Users/qlerebours/Projects/traveledmap/              (branch feat/my-main-feature)
/Users/qlerebours/Projects/traveledmap-fix-add-form-validations/      (branch fix/add-form-validations)

and the repository state:

A single .git folder in /Users/qlerebours/Projects/traveledmap/
Shared history
Each folder uses its own branch
Independent files
Commits visible instantly across all worktrees

This setup lets your code assistant work on two features in parallel.

How to use it: a concrete use case

Scenario

I’m working on my main feature on branch feat/my-main-feature
I want to fix a missing-validation issue reported by Product Owners
Codex is used to update the wording and its translations (same workflow with Claude Code and others)

Make the changes

In Codex, I start a new conversation in my project and choose Worktree and from develop
- Worktree: to work in parallel
- from develop: the base for my new branch
When I send my prompt, Codex announces it’s creating the worktree, which I can confirm with
git worktree list
When I go into the worktree folder (/Users/qlerebours/.codex/worktrees/c6a5/traveledmap),
I see the changes are done and ready to test

Test the changes

Here are the steps if you want to test the changes without pulling them locally. Otherwise, you can go straight to
"Take back control".

Make sure you’re in the worktree folder
Since this folder starts from the develop branch, I need to set up what’s required, for example:
- cp .env.example .env
- pnpm i
Then I just run the project with pnpm run dev to test and validate the changes
If new changes are needed, Codex will add them to the existing ones so you can test again

Take back control

If you want to take back control and make the changes yourself, you have several options:

Open the worktree folder in your preferred code editor and make the desired changes.
Use the "Hand off to local" button at the top right of the Codex conversation, which commits the changes to a
branch you can pull locally.
Use the new "Create a branch" button, which also creates a branch and pushes it if you want to open a PR directly.
Either way, options 2 and 3 are effectively the same: they push changes to a branch you can pull locally or access on
Github / Gitlab.

The full documentation for this part is available here for Codex.

Conclusion

Understanding git worktree now means understanding how to work efficiently with AI development assistants.

I hope this article is useful. Writing it helped me clarify things I didn’t fully grasp myself.
If you have any questions, feel free to reach out by email or on LinkedIn.

Upgrade your JHipster project to Java 17

Quentin Lerebours — Thu, 14 Apr 2022 14:39:24 +0000

Run and deploy a JHipster project with Java 17

Created: April 5, 2022 9:38 AM
Tags: java, jhipster, spring

In this short article, I’ll explain how to run and deploy a JHipster project using another version than the standard version which is used by JHipster (Java 11 currently).

Step 1: Make it run on the targeted Java version

Use the right Java version locally

Firstly, you need to have the targeted Java version on your local environment. If you are using SDK man you can run:

sdk list java
Once you have found the target version inside, install it with sdk install java 17.0.2-open (for instance)
Finally, run sdk use java 17.0.2-open to use it in your current terminal

💡 SDK man is a great tool to manage multiple Java versions on your environment. It allows to easily install versions and switch between versions

Set the right Java version for the project

Once you are using the right Java version locally, you just have to change the target release in the project. If you’re using Maven, you just need to change <java.version>17</java.version> in the pom.xml

🎉 You are now ready to go, you can try to run the project with ./mvnw

💡 If you see an error saying “Invalid target release 11”, it’s probably that your local and project version are out of sync. They have to be the same (17 in my use case)

Step 2: Fix the CI

If you are using a CI and your CI is using the jhipster/jhipser:latest Docker image to run the project and the tests, it won’t work anymore because this Docker image is based on eclipse-temurin:11-jre-focal which is using Java 11.

It means that you will have to recreate your own Docker image based on Java 17, but don’t worry, it’s not complicated:

Clone the generator-jhipster project on Github
Open the Dockerfile which is at the project’s root
Edit the base image to eclipse-temurin:17-jre-focal
Create a repository on the docker hub. Let’s assume it’s called myOrganization/jhipster-java-17
Build the new image with docker build . -t myOrganization/jhipster-java-17:latest
Push the brand new image to the hub with docker push myOrganization/jhipster-java-17:latest
Finally, change the docker image used in your CI to myOrganization/jhipster-java-17:latest and when your CI reruns, it will succeed.

Step 3: Edit your Cloud environment

At BearStudio, we are using CleverCloud which allows to edit the target Java version very easily thanks the CC_JAVA_VERSION environment variable, which set up to 17 before saving your changes.

You’re done, your JHipster project should now run on Java 17 🎉

If you don’t use JHipster yet, you can learn how to generate your first project with JHipster with this article (which is in French).

Forem: Quentin Lerebours