In agile teams, the routine is rarely linear.

You start developing a relevant feature, you are deeply focused on the problem, and then a production hotfix appears, a quick adjustment requested by the Product Owner, or a critical bug reported by support.

Context switching is a natural part of the job. The difference between a healthy workflow and a chaotic one lies in how this switch is handled without compromising the codebase.

In this article, I present two approaches to deal with this scenario using Git: git stash and git worktree. Both solve the problem, but at different levels of maturity and robustness.


Git Stash and Pop: the basic solution for quick pauses

git stash allows you to temporarily save local uncommitted changes, cleaning your working directory so you can switch branches.

Typical scenario

You are working on:

feature/recurring-payments

There are still unfinished changes. Suddenly, an urgent hotfix is needed on main.

Possible flow:

git stash push -m "WIP: recurring payments"
git checkout main
git pull
git checkout -b hotfix/timeout-fix

After finishing the hotfix:

git checkout feature/recurring-payments
git stash pop

Your changes are restored to their previous state.

Strengths of stash

  • Simple and fast
  • Solves short interruptions
  • Does not require additional structure

Important limitations

git stash is a more basic solution. It works well for short pauses, but it has limitations when used frequently:

  • It may generate conflicts when applied
  • It is not suitable for multiple parallel contexts
  • It can become a disorganized accumulation of saved changes
  • It does not isolate execution environments

In environments where interruptions are constant, there is a more robust approach.


Git Worktree: multiple simultaneous contexts with real isolation

git worktree allows you to create multiple working directories for the same repository, each pointing to a different branch.

Instead of saving changes and switching branches, you work in physically separated contexts that share the same Git history.

Practical example

You are developing:

feature/new-pix-api

An urgent hotfix appears.

Instead of using stash:

git worktree add ../repo-hotfix main
cd ../repo-hotfix
git checkout -b hotfix/calculation-error

Now you have two independent directories:

  • /project with the ongoing feature
  • /repo-hotfix with the hotfix

You can open two IDEs, run different test suites, or even separate containers without any risk of mixing changes.

After finishing:

git worktree remove ../repo-hotfix

Why worktree is more robust

git worktree provides:

  • Real context isolation
  • Elimination of the need for stash in many cases
  • Significant reduction of conflicts
  • Clearer organization of parallel tasks
  • Better alignment with structured CI/CD workflows
  • Cleaner and more predictable history

While stash is a tactical solution, worktree is a structural one.


Recommended strategy in agile environments

Quick, short-lived interruptions
Use git stash.

More structured parallel demands, frequent hotfixes, or multiple development fronts
Use git worktree.

Teams dealing with active production systems, multiple releases, and continuous integration tend to benefit more from worktree, as it reduces operational risk and increases predictability.


Conclusion

In agile development, productivity is not just about writing code quickly. It is about managing context with discipline.

git stash is a useful and basic tool for quick pauses. git worktree, on the other hand, represents a more advanced level of organization, offering isolation, clarity, and robustness for those who frequently switch between multiple work streams.

Mastering this distinction demonstrates engineering maturity and a strong commitment to maintaining a healthy codebase.

If your routine involves constant hotfixes and multiple parallel features, it may be time to evolve from stash to worktree.


That's all folks!
Artus