What are Git Worktrees?​

Git worktrees are a feature that allows you to have multiple working directories from the same repository, each potentially on different branches. Think of it as having multiple "copies" of your project that all share the same Git history but can work on different branches simultaneously.

When you initialize a Git repository, you get your main worktree (the directory where you ran git init or git clone). From there, you can create additional worktrees that are linked to the same repository but exist in separate directories.

Here are the essential commands you'll need:

# Create a new worktree for a specific branch
git worktree add ../my-feature

# List all worktrees
git worktree list

# Remove a worktree when you're done with it
git worktree remove ../my-feature

The relationship is simple: your original repository remains the "main" worktree, and any additional worktrees are linked to it. They all share the same .git directory, which means commits, branches, and history are synchronized across all worktrees.

How is it different from regular branches?​

With regular Git branches, you're confined to working in a single directory. When you want to switch between branches, you need to git checkout or git switch, which means saving or stashing your current work, switching the entire working directory to the new branch, and then resuming work. This context switching can be disruptive, especially when you're juggling multiple tasks or need to quickly reference code from another branch.

Git worktrees eliminate this friction by giving each branch its own physical directory. You can have your main branch running in one terminal tab, a feature branch in another, and a hotfix branch in a third - all simultaneously.

Each directory maintains its own state: uncommitted changes, running processes, and even different dependency installations if needed. This separation makes multitasking not just possible, but actually pleasant.

Why now (a decade after release)?​

Until a few weeks ago, I wasn't aware this command even existed in Git. I had stumbled upon my own "hack" - cloning the same repository multiple times with different branches to work on several tasks simultaneously. When I shared this approach with a colleague, he said, "Oh, you should check out worktrees. It might be a better fit for this use case."

That's when I discovered that Git has had this feature since 2015, but it somehow flew under my (and most developers) radar. Intrigued, I decided to spend a week experimenting with worktrees to see if they could replace my cloning approach.

During this trial period, I set up three different worktrees for my current project: one for a major feature I was developing, another for urgent bug fixes that kept coming up, and a third for some technical debt cleanup that I'd been putting off. The setup was surprisingly smooth, and I found myself naturally gravitating toward using different terminal windows for different worktrees.

What struck me most during this experiment was how the mental model changed. Instead of thinking "I need to switch branches," I started thinking "I need to switch contexts" - and each context had its own physical space. This subtle shift made multitasking feel less chaotic and more intentional.

The timing of my discovery wasn't coincidental though. The rise of AI coding assistants like Claude Code (Anthropic's AI-powered development environment) and Cursor (an AI-first code editor) has fundamentally changed how we approach development work. These tools have made worktrees not just convenient, but genuinely effective.

Here's where it gets interesting: AI agents (autonomous AI systems that can write, modify, and test code independently) excel at handling isolated, well-defined tasks. When you point Claude Code at a specific worktree with a clear objective, it can work autonomously without the mental overhead of context switching that plagues human developers. This combination of physical isolation (separate directories) and logical isolation (focused tasks) creates an ideal environment for AI-assisted development.

Through experimentation, I've identified three main use cases where worktrees truly shine:

Long-running Side Tasks​

Perfect for dependency updates, documentation improvements, or refactoring tasks that you want to chip away at over time without disrupting your main development flow. I keep a dedicated worktree for these maintenance tasks, allowing me to make progress on them during natural breaks in feature development.

Environment Experimentation​

Need to test with a different Node version? Want to try a new dependency without breaking your current setup and having to reinstall node_modules? Worktrees let you maintain completely isolated environments while keeping everything in the same repository. This is particularly valuable when you need to compare performance or behavior across different configurations.

AI Agent Parallel Work​

This is where worktrees truly excel in 2025. Each AI agent gets its own sandbox to work in, reducing the cognitive overhead of task switching and making it easier to review and integrate changes systematically. I found myself setting up different worktrees for different types of tasks:

• One worktree for the main feature branch where I need more focus and precision
• Another for some bugfix that needed to be done quickly
• A third for refactoring legacy code

Current Limitations and Future Potential​

While experimenting with this approach, I initially thought I'd discovered an unbeatable hack - multiple unrelated tasks running simultaneously, with me just orchestrating from above. My backlog would be cleaned out in a day!

However, after about a week of testing, I discovered some realistic limitations. For production code, the real bottleneck often becomes code review capacity. Every line entering your codebase still needs to be understood and validated, and AI-generated code sometimes requires even more careful review than human-written code.

You can spin up as many worktrees as you want and assign AI agents to each one, but eventually all their work flows through your review process. This mirrors the same scaling challenge we've always had with teams: adding more developers doesn't automatically increase output if review capacity doesn't scale with it.

Context switching between worktrees also remains a challenge. While the technical barriers are removed, the mental overhead of juggling multiple tasks simultaneously is still very real.

That said, even with these limitations, I've found worktrees provide a meaningful productivity boost for certain types of work. The key is understanding when and how to use them effectively, rather than expecting them to be a silver bullet.

Despite these realistic constraints, my experience over the past few weeks has convinced me that worktrees represent something significant for modern development workflows.

Conclusion​

Git worktrees have become an essential part of my development workflow, not because they're revolutionary, but because they solve a very specific modern problem: how to manage multiple concurrent development streams in the age of AI assistance.

The beauty of git worktrees isn't in their technical complexity - they're actually quite simple. It's in their timing. They've been quietly waiting for a decade for the right use case to make them indispensable. With AI coding assistants becoming our collaborative partners rather than just tools, worktrees have found their moment.

Sometimes the best features are the ones that have been there all along, just waiting for the right context to make them essential. While git worktrees won't make you deliver 10 times faster, they might make you 2-3 times more efficient, and that's a meaningful boost that would have been hard to imagine just a few years back.

Resources​

• Git Worktrees - Git Documentation
• thePrimagen discovers Git Worktrees
• Frontend Masters - Git Course (needs signup)

Prerequisites​

Before diving into TDD with React, you should be familiar with:

• Basic React concepts (components, state, props)
• JavaScript/TypeScript fundamentals
• Command line basics
• Basic understanding of testing concepts

What is Test-driven development?​

Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.

From wikipedia

So what does it actually mean? Instead of writing the code first and then adding tests to validate the added behavior, we first write the test and only then implement the new behavior.

Basically it should look something like this:

TDD Diagram​

Why not just do it the other way around?​

TDD requires the developer to change the way they approach the problem. When starting to practice it, it might seem unintuitive and the concept might take some time to grasp. When implementation comes first, we're biased - TDD avoids this by starting with a failing test. When starting with a failing test we know for sure that it's not yet operational, only when the test switches to green do we know we've reached our goal.

How?​

In theory it sounds pretty nice and simple, let's see how we can actually do it. We'll use React.js for the examples but the concepts are transferable to all other frameworks and libraries. Our test runner will be Vitest and the rendering will be done by Testing Library I chose Vite for this demo because it's fast, modern, and integrates smoothly with Vitest.

Installation & Setup​

First of all let's get started with this command

npm create vite@latest my-app -- --template react-ts
cd my-app
npm install

Once it's finished we need to set up our testing environment. Let's install the necessary testing dependencies:

npm install --save-dev vitest @testing-library/react @testing-library/dom @types/react @types/react-dom jsdom

Add a vitest.config.ts file to the root of the project with the following content:

import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
  test: {
    environment: 'jsdom',
  },
})

Add test scripts to your package.json:

{
  "scripts": {
    "test": "vitest"
  }
}

Create Our First Spec File​

For now let's just create a simple spec file to make sure everything is working as expected.

import { describe, expect, it } from 'vitest'

describe('AppComponent', () => {
  it('should return true', () => {
    expect(true).toBe(true);
  });  
});

Run the Tests​

Let's run the test command npm run test. Vitest runs in watch mode by default, so each file change in the src directory will trigger a re-run of the test command.

You should see something like this:

Awesome, everything is working as expected! We are ready to start our TDD journey. 🥳

New Task Requirement​

Let's assume that we were assigned to develop a simple counter display, with "Increment", "Decrement" and "Reset" functionality. We even got a prototype video of the feature:

Let's break that down into smaller blocks of logic:

• Increment
  • Button with "Increment" label should be displayed
  • Clicking the button should increment the count by one
• Decrement
  • Button with "Decrement" label should be displayed
  • Clicking the button should decrement the count by one
• Reset
  • Button with "Reset" label should be displayed
  • Clicking the button should set the count to 0
• Counter
  • Should be initialized with 0 as value

Basically we can use this as a reference to our TDD cycles. If we take increment click functionality and cast it on the diagram we saw before it should look something like this:

1st Test - Increment Button Should Exist​

First of all let's clear the existing App.tsx file so it will return an empty div element:

import React from 'react';
import './App.css';

function App() {
  return (
    <div />
  );
}

export default App;

The first test should check if the button is rendered in the document, using Vitest's global describe, test and expect functions, Testing Library's render function that renders the elements in the DOM (well, not an actual DOM, but that's a topic for another article), and [screen] object which represents the document object in which the render function rendered. For a deeper understanding of this, I would suggest reading the official docs of Vitest and Testing Library.

import { describe, expect, test } from 'vitest'
import App from './App'
import { render, screen } from '@testing-library/react';

describe('when app is rendered', () => {
  test('should display "increment" button', () => {
    render(<App />);

    expect(screen.getByText('Increment')).toBeDefined()
  });
});

This will be the output for the test:

Let's go over what happened here. Since the button element wasn't implemented yet, getByText function couldn't find it in the DOM.

Since we didn't implement the button in the code, the test is failing. Now let's add the button:

import React from 'react';
import logo from './logo.svg';
import './App.css';

function App() {
  return (
    <div>
        <button>
            Increment
        </button>
    </div>
  );
}

export default App;

Now the test would pass, as the target element is found

2nd Test - Click on Button Should Increment Counter​

The next step in our test flow should be "when user clicks on increment, counter should be incremented by one", but before we do that, we should test that the default count value is 0.

So let's add the following test:

import { describe, expect, test, beforeEach } from 'vitest'
import App from './App'
import { cleanup, render, screen } from '@testing-library/react';

describe('when app is rendered', () => {
  beforeEach(() => {
    cleanup();
  });

  test('should display "increment" button', () => {
    render(<App />);

    expect(screen.getByText('Increment')).toBeDefined()
  });

  test('should initiate counter with 0', () => {
    render(<App />);
    expect(screen.getByText('Count is 0')).toBeDefined();
  });
});

After this second test fails, we can add this logic:

import React from 'react';
import './App.css';

function App() {
  const [count] = React.useState(0);

  return (
    <div>
      <button>Increment</button>
      <p>Count is {count}</p>
    </div>
  );
}

export default App;

Now the test should pass.

3rd Test - Click on Increment Button Should Increment Counter​

Now let's test the actual increment functionality. We need to test that when the user clicks the increment button, the counter value increases by 1, We'll use user-event library to simulate user interactions.

import { describe, expect, test, beforeEach } from 'vitest'
import App from './App'
import { cleanup, render, screen } from '@testing-library/react';
import { userEvent  } from '@testing-library/user-event';

describe('when app is rendered', () => {
  beforeEach(() => {
    cleanup();
  });

  test('should display "increment" button', () => {
    render(<App />);

    expect(screen.getByText('Increment')).toBeDefined()
  });

  test('should initiate counter with 0', () => {
    render(<App />);
    expect(screen.getByText('Count is 0')).toBeDefined();
  });

  test('should increment counter when increment button is clicked', async () => {
    render(<App />);
    
    await userEvent.click(screen.getByText('Increment'));
    expect(screen.getByText('Count is 1')).toBeDefined();
  });
});

This test will fail because we haven't implemented the click handler yet. Let's add the functionality:

import { useState } from 'react'
import './App.css'

function App() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <button onClick={() => setCount((count) => count + 1)}>Increment</button>
      <p>Count is {count}</p>
    </div>
  )
}

export default App

Now all tests should pass! We've successfully implemented the increment functionality using TDD. Now you can follow the same pattern to implement the Decrement and Reset functionalities, but remember to always start with a failing test first, and then make it pass.

Benefits of TDD in Practice​

Through this example, we can see several key benefits of TDD:

• Avoiding Uncovered Cases: By writing tests first, we ensure that all edge cases are considered and tested, when we write the code first we might miss some edge cases.
• Avoiding False Positives: By writing the test first, we avoid the risk of writing code that appears to work but doesn't actually meet the requirements

FAQ​

Q: What's the difference between unit tests and integration tests in the context of TDD?
A: Unit tests focus on individual components or functions in isolation, while integration tests verify that multiple components work together correctly. TDD typically starts with unit tests and progresses to integration tests.

Q: Is TDD slower than traditional development?
A: Initially, TDD might feel slower, but it often saves time in the long run by catching bugs early, reducing debugging time, and making refactoring safer.

Q: Can I use TDD with existing codebases?
A: Yes! You can start applying TDD to new features or when refactoring existing code. You don't need to rewrite everything to benefit from TDD principles.

Q: What about testing UI components? Isn't that brittle?
A: When testing UI components, focus on user behavior rather than implementation details. Use semantic queries (like getByRole, getByLabelText) instead of brittle selectors, and test what the user would actually do.

Q: When is TDD not the most efficient approach?
A: TDD works best for well-defined, stable requirements. It may not be ideal for rapid prototyping, exploratory programming, or when requirements are constantly changing. In these cases, you might start with a prototype first, then add tests as the feature stabilizes. TDD also requires more upfront investment, so for very small scripts or one-off utilities, the overhead might not be worth it.

Conclusion​

Test-Driven Development is more than just a testing strategy - it's a design methodology that helps you build more reliable, maintainable software. By writing tests first, you're forced to think about your API design, error cases, and user requirements before diving into implementation.

The counter example we built demonstrates the core TDD cycle: Red (write a failing test), Green (make it pass with minimal code), and Refactor (improve the code while keeping tests green - we didn't focus on it as much). This approach ensures that every line of code you write has a clear purpose and is thoroughly tested.

While TDD may feel slower initially, the benefits compound over time. Once a good infrastructure is in place, you'll spend less time debugging, have more confidence when refactoring, and create better-designed code. The tests serve as both specification and safety net, making your codebase more robust and maintainable.

Start small with TDD—pick one new feature or bug fix and apply the Red-Green-Refactor cycle. As you become more comfortable with the process, you'll find that TDD becomes a natural part of your development workflow.

Ready to Start TDD?​

Try implementing the decrement and reset functionality using the same TDD approach we covered. Remember: Red → Green → Refactor!

The key to mastering TDD is practice. Start with small features and gradually work your way up to more complex functionality. The investment in writing tests first pays off with more reliable, maintainable code.

References​

• Test-driven development - Wikipedia
• Vite - Getting Started
• Vitest Documentation
• React Testing Library Documentation

tl;dr: Bookmarklets are bookmarks charged with the power of JavaScript. They let you execute JavaScript code by clicking on a bookmark.​

Ever found yourself repeatedly copying a particular text, navigating to a specific webpage, or performing some other routine task while browsing? Bookmarklets are a neat trick that can help you automate these mundane tasks. Instead of using a URL, these supercharged bookmarks leverage JavaScript to perform complex tasks at the click of a button.

How do Bookmarklets work?​

Creating a bookmarklet is similar to creating a bookmark. The difference is that instead of inserting a URL, you add JavaScript code. Whenever you click on the bookmarklet, this JavaScript code is executed. It's a powerful feature that can automate a plethora of tasks that you perform in your browser. Any JavaScript code that you can run in the browser console, you can run in a bookmarklet.

Copy a frequently used string to the clipboard​

javascript:navigator.clipboard.writeText('ce34839b-5eca-4ab5-86ac-02cc8ba76c8e');

Fetch data from an api​

we can also use this to fetch data from an api, and display it in the console.

javascript:fetch('https://jsonplaceholder.typicode.com/todos/1').then((response) => response.json()).then((json) => console.log(json));

Expanding Your Bookmarklet Library​

The power of bookmarklets is limited only by your imagination. You can automate numerous tasks that you frequently perform on your browser. For more ideas and inspiration, check out these repositories:

https://github.com/Krazete/bookmarklets

https://github.com/marcobiedermann/awesome-bookmarklets

Conclusion​

Bookmarklets offer a way to harness the power of JavaScript to automate your browser tasks and enhance your productivity. They're easy to create and can be as simple or complex as you need them to be. But, like all powerful tools, they need to be used with caution. So, remember to use or create bookmarklets from trusted sources to keep your browsing safe.

Recursion is a computer science practice where a function calls itself until it reaches an exit condition. Sound pretty simple, right?

I Used to struggle with recursive code; it was hard to grasp the notion of something calling (invoking) itself, and it felt too abstract. Usually, recursion is demonstrated with the Fibonacci sequence, binary search tree, or some other theoretical example, which could be tough to wrap your head around. I wondered where such practice would be helpful UI-wise. For example, a comment section where each comment can have a sub-comment which will have a sub-comment of its own, which will have a sub-comment of its own, well, you got the idea.

const Comment = ({ author, content }) => {
  return (
    <div>
      <span>{author}: </span>
      <span>{content}</span>
    </div>
  );
};

const Comment = ({ author, content, subComment }) => {
  return (
    <div className='comment'>
      <span>{author}: </span>
      <span>{content}</span>
      <Comment {...subComment} />
    </div>
  );
};

What is wrong with the code above? It's not working! We get an error that says "Cannot read property 'author' of null". We need the exit condition for this component. When do we want this component to stop rendering itself? If the comment object doesn't have a sub-comment would be the specific case.

We could do this in two ways:

const Comment = ({ author, content, subComment }) => {
  if (!author || !content) return null;
  return (
    <div className='comment'>
      <span>{author}: </span>
      <span>{content}</span>
      <Comment {...subComment} />
    </div>
  );
};

const Comment = ({ author, content, subComment }) => {
  return (
    <div className='comment'>
      <span>{author}: </span>
      <span>{content}</span>
      {subComment && <Comment {...subComment} />}
    </div>
  );
};

In the first solution, we call the Comment function (component). When the condition is not met, we exit it, and in the second solution, we check for the condition before calling the function.

You can play with the code here: https://codesandbox.io/s/simple-react-recursion-ycrtbb

Thanks for reading!

Learn​

Bundlers: webpack,rollup,parcal,snowpack.​

Why: when using options like create-react-app, you might not need that at all, but when you want the ability to custom and modify the build process, I find it necessary to understand these tools better. Most of the time, I had to tweak something, I just copy-pasted it without really understanding the full implications of what I was doing. Since webpack is the most popular one, this is the one I'm going to focus mostly on. After mastering one of these tools, the others will become more approachable and easy to get on board.

How: Reading the official docs, possibly watch a tutorial and dive deep into using it, try to avoid preconfigured builders like create-react-app, and try to write the webpack config from scratch. And most importantly, for any future project that I will start, I can try and configure the webpack by myself.

Testing: jest,mocha,react-testing-library, puppeteer and cypress​

Why: I have a confession. I have never written a test in my life, not even a simple unit test. While I understand the upside of writing tests, I never really needed to learn this paradigm. As I'm maturing as a developer and understanding those processes better, I see the value of using tests in any project. Even on my small and relatively simple projects, I stumble on regressions and errors I know could have been prevented if I had some test implemented.

How: For starters, understand the difference between test types (unit test, e2e, etc.). What kind of tools to use for each, and finally start integrating tests in my existing projects, and obviously in new future projects.

TypeScript​

Why: Quite frankly, I want to learn TypeScript to read and understand the source code of external packages. It's that simple. The best documentation is the source code itself.

Also, the fact that TS is gaining popularity is significant, from a nice to have ability to an almost necessity in the last few years.

How: You guessed it, implementing TS in my existing projects. No reason to get fancy here.

NodeJS​

Why: When I need to write code that doesn't "live" in the browser, the obvious choice for a web developer is node.js. For developing backend servers, writing cloud functions, web scraping, and even IoT devices, Node.js is a powerful tool to have in your toolbelt.

How: To be honest, with node.js, I'm cheating because I already started learning and using it, but I want to expand on using it. For a JavaScript developer, the transition is pretty smooth, even though you still have to understand a few key concepts and get used to not having the 'window' object.

git​

Why: Well, I know git, but I can't say I have in-depth knowledge, pull, push, checkout, really the basics. I want to master it to the point where I don't have to use the GUI, just the commands and the complicated ones.

How: I plan to take the Frontend Masters Git In-Depth course and make the switch to use the terminal more heavily than the GUI.

Goals:​

Codewars: Codewars is a website where you can practice coding problem skills and algorithms for those who don't know. Over the last year or so, I laid aside my progress. I'm currently kyu(level) 6. I believe I can reach level 4 by the end of the year.

yakov.dev: (my blog) I started this blog a few months ago. I want to keep it active, so at least one post per month will be a sufficient pace, although I hope to write even more.

YDKJS (You Don't Know JS): I started this great series by Kyle Simpson a few months ago. I do plan to finish it sometime soon. When reading these books, I have encountered many complex concepts that make my understanding of the language much better. I recommend any web developer to read this series, I've learned a lot from it, and I only read the first two books out of 6.

Mobile Development: I found myself in need of some functionality on my android phone that doesn't exist. After searching for an app, I decided to develop it myself. It should be refreshing to try something new like Flutter for a small project and outside the JS ecosystem.

Chrome & Visual Studio Code extensions: I use Chrome and VS Code extensions daily, and it caught my interest in how those extensions developed and work under the hood. I'll start with one for each app.

Continue Develop my Side Projects I have a few ongoing projects that I try to expand and add features all the time. Although I don't have a defined road map for them, I don't want to neglect them while focusing on the other goals I have set for this year.

To conclude, think about where you would like to be in a year, what skills you would like to have, and set goals for yourself. I believe that in our profession, you can't rest on your laurels, always thrive on getting better, and expand your knowledge.

See you next time! 🏆

Welcome to my new blog and my first post ever!

My Name is Yakov, a Frontend web developer from Haifa, Israel.

As a self-taught developer, I’ve stumbled across many topics, concepts, and disciplines that looked very intimidating and complicated at first. Still, after time and time again, they started to make sense. Subsequently, my confidence has grown, and step by step, I felt more comfortable learning new things.

One of the primary resources of information that helped me through were articles and blog posts, A lot of documentations are long and tedious, especially for a beginner developer, and sometimes a short blog post can simplify and explain some topics much better.

My main goal in starting this blog is to help others the same way others helped me. In this blog, I will write about software development ( mostly web-oriented ), career advice, insights, random tech stuff, and shawarma reviews.

Just kidding about the shawarma…or not…I haven’t decided yet. Wish me luck and see you soon! 👋