In this issue, you'll look at a new way to work on multiple branches in Git simultaneously by using the git worktree command. But first, I'm going to challenge the popular belief that everyone learns things in different ways.

Everyone Doesn't Actually "Learn Differently"

In Issue 10, I wrote about the myth of learning styles and how there's no scientific evidence that learning styles impact a person's ability to learn. That myth, sadly, won't go away.

Lately, I've seen people using a variant of the myth: "Everyone learns differently."

I usually hear it when people justify delivering content in one format over another. The logic goes that since everyone learns differently, we should offer multiple formats because that is how different brains work. The problem is that the statement "everyone learns differently" confuses how people like to consume information with _how people learn and ends up just reviving the learning styles myth.

But, more importantly, it confuses exposure to a topic with learning the topic.

People absolutely approach learning with different backgrounds, experiences, access, and levels of comfort with different types of content. These preferences and differences matter for motivation, confidence, and entry points into a topic. They also matter for accessibility and equity. But exposure to information is the starting line, not the finish line; a series of videos on a YouTube channel isn't a course, and people consuming it aren't learning.

The process of successfully learning something is the same for everyone: people learn by trying something, seeing what happens, getting feedback, questioning assumptions, connecting and comparing ideas, and adjusting as they synthesize new information. As my teaching mentor kept telling me every chance he got: "Learning happens through practice and feedback."

Modern research keeps confirming the importance of practice and feedback:

• The 2025 article A Review of Feedback Models and Theories: Descriptions, Definitions, and Conclusions states that "feedback is essential for improved performance and can contribute to enhanced achievement on the task."
• The 2024 article The more, the better? Learning with feedback and instruction reports that the most important purpose of formative feedback is to guide the student to regulate and improve the further learning process.
• The 2023 article The Practice Gap states that "Expert performance results from active engagement in deliberate practice with teachers or coaches monitoring the structured, organized practice."
• The 2015 Science of Learning report from Deans for Impact indicates that retrieval practice and active doing strengthen knowledge far more effectively than review or rereading.

But you know this already. You don't learn Git by watching a two-hour course about Git on Udemy. You learn Git when you try to rebase, break something, feel a little panic, and then work through the fix. You do not learn to cook by watching cooking shows. You learn when you put something in a pan, taste it, and adjust. You practice, get feedback, and improve.

Even when you are learning something that's more "information-based," like history, the learning does not happen when your eyes move across the text or when you finish the documentary. It happens when you connect events, argue interpretations, test your recall, explain a cause, or apply a concept in a new context. Consumption gives you raw material. Learning happens when you do something with it.

Your content format choices can help someone feel ready to try. They help learners build familiarity, reduce fear, and help a concept click enough for the learner to take action. Your choices can also hold people back; using written content when teaching a visual medium like video editing might not be the right approach, while a video where someone watches you code can prevent someone from easily copying the code you're showing. Either way, content alone is not a learning path or a learning strategy; it's just one component.

Learning truly begins when action begins. That part is not personal preference. It is how human cognition works. The medium might change. But everyone "learns" the same way: we build skill by engaging, practicing, making mistakes, getting feedback, and trying again. So don't focus on the content type.

To start moving your content towards a more holistic learning experience, start by reviewing Issue 28 of this newsletter, which shows you how you can introduce formative assessments into your work.

Things To Explore

• rundl is a high-performance Markdown linter and formatter. It's like MarkdownLint, but faster.
• harper is an English-only local alternative to Grammarly, and you can plug it into your editor or browser.
• Helix. It's like Vim, but faster and modern. And purple.

Manage Multiple Documentation Versions with Git Worktree

When you're writing documentation, you'll often need to work on two things at once. You may be updating docs for the next release while fixing a typo in the current version. Or perhaps you're reviewing a colleague's pull request while you're mid-edit on your own article.

The typical approach is to use git stash to temporarily stash your changes, check out the other branch, do your work, then switch back and unstash. This workflow breaks your concentration and creates friction every time you need to context-switch.

This workflow has some drawbacks, though:

• You lose your mental context every time you switch
• Your editor might reload files, losing your cursor position
• Stashing doesn't always work cleanly, especially with untracked files
• You might forget to stash and accidentally include your changes in their branch

The friction adds up. Each context switch takes mental energy and time.

Git worktrees offer a better solution. Instead of switching branches in a single directory, you create multiple working directories for the same repository. Each directory can be on a different branch, letting you keep multiple contexts active simultaneously. The worktrees share the same Git history and objects, but they have independent working directories.

To get comfortable with worktrees, you'll set up a small docs site and juggle a couple of versions of your docs.

Create the project

Create a new directory and initialize a Git repository:

$ mkdir docs-project && cd docs-project
$ git init

Create three markdown files for your documentation. First, create getting-started.md:

$ cat > getting-started.md << 'EOF'
# Getting Started

Welcome to our product! This guide will help you get started quickly.

## Installation

Download the installer from our website and run it.

## First Steps

1. Open the application
2. Create an account
3. Start using the features
EOF

Then create configuration.md:

$ cat > configuration.md << 'EOF'
# Configuration

Learn how to configure the application for your needs.

## Basic Settings

The application stores settings in a configuration file.

## Advanced Options

Advanced users can modify additional settings in the config file.
EOF

Finally, create troubleshooting.md:

$ cat > troubleshooting.md << 'EOF'
# Troubleshooting

Having problems? Check these common solutions.

## Application Won't Start

Make sure you have the latest version installed.

## Data Not Saving

Check your disk space and file permissions.
EOF

Add these files and commit them to your repository.

$ git add .
$ git commit -m "Initial documentation for version 1.0"

Create a branch for version 1.0 of your documentation.

$ git branch version-1.0

Creating Worktrees

When you create worktrees, you're going to create new directories on your machine, and things will get cluttered quickly.

To keep things organized, create worktrees as siblings of your main repository directory, and use descriptive names that indicate the branch or purpose.

For example, you're going to create worktrees to manage version 1 and version 2 of your docs, so you'll have a structure like this:

projects/
  docs-project/       # main worktree
  docs-v1.0/          # additional worktree
  docs-v2.0/          # additional worktree

Create a worktree for version 1.0 using the version-1.0 branch you created:

$ git worktree add ../docs-v1.0 version-1.0

This creates a new directory called docs-v1.0 next to your main repository, with the version-1.0 branch checked out.

Create a worktree for version 2.0, but this time use the -b flag to create a new version-2.0 branch automatically.

$ git worktree add ../docs-v2.0 -b version-2.0

You cannot check out the same branch in multiple worktrees. Each worktree must have its own branch.

Verify your worktrees:

$ git worktree list

The output shows your worktrees and their associated branches.

/Users/brianhogan/projects/docs-project       abc1234 [main]
/Users/brianhogan/projects/docs-v1.0          abc1234 [version-1.0]
/Users/brianhogan/projects/docs-v2.0          abc1234 [version-2.0]

With the worktrees created, you can now work on multiple features by changing directories instead of switching branches and juggling work.

Manage multiple workstreams

To practice working with your worktrees, you'll run through a common scenario that technical writers find themselves in. There's a new product version coming, so you need to update the documentation to mention it, but you also need to respond to support requests to update the current documentation pages.

Start by working on the new version of your docs. Navigate to the version 2.0 worktree:

$ cd ../docs-v2.0

Update the getting started guide to reference the new version. Run the following command to overwrite the getting-started.md file with new contents:

$ cat > getting-started.md << 'EOF'
# Getting Started

Welcome to version 2.0! This guide will help you get started quickly.

## Installation

Download the installer from our website and run it. Version 2.0 includes an improved installer with progress indicators.

## First Steps

1. Open the application
2. Create an account or sign in with social login
3. Complete the setup wizard
4. Start using the new features
EOF

Add a new feature to the configuration documentation. Run the following command to append some text to the configuration.md file:

$ cat >> configuration.md << 'EOF'

## Cloud Sync (New in 2.0)

Enable cloud sync to access your data from multiple devices.
EOF

Stage and commit these changes:

$ git add .
$ git commit -m "Update documentation for version 2.0 features"

The changes get committed to the version-2.0 branch associated with the worktree.

But now you have a support request to deal with. A user reports an error in the version 1.0 troubleshooting guide. Navigate to the version 1.0 worktree:

$ cd ../docs-v1.0

Add a new section to the troubleshooting file to address the issue:

$ cat >> troubleshooting.md << 'EOF'

## Settings Not Persisting

If your settings reset after closing the application, run the app as administrator once to fix permissions.
EOF

Stage and commit the fix:

$ git add troubleshooting.md
$ git commit -m "Add solution for settings permission issue"

Go back to your version 2.0 work:

$ cd ../docs-v2.0

Your version 2.0 changes are exactly as you left them. No stashing, no switching, no lost context.

The troubleshooting fix you made applies to version 2.0, so merge the 1.0 branch in:

$ git merge version-1.0

When you finish working with a worktree, remove it. For example, you're no longer working on the old docs, so switch to the original docs-project directory and then remove the docs-v1.0 worktree:

$ cd ../docs-project
$ git worktree remove ../docs-v1.0

This removes the working directory but keeps the branch. Delete the branch if you no longer need it:

$ git branch -D version-1.0

You should remove worktrees when you merge or abandon the branch. Keeping too many worktrees around clutters your filesystem.

Git worktrees eliminate the friction of context-switching when you have to manage multiple versions or work on several features simultaneously. Instead of constantly stashing and switching branches or making work-in-progress commits, you keep multiple contexts active and switch between them by changing directories.

Parting Thoughts

Before the next issue, try the following things:

1. Try using git worktree on your current project the next time you need to do some experimentation. Then reflect on how it went. Did it work better than stashing or committing changes and switching branches?
2. Think about the last book you read or course you took. How much practice did you get? Was the practice self-directed, or was it built into the content? How much time did you spend practicing?

As always, thanks for reading. Share this issue with someone who would find this helpful.

I'd love to talk with you about this issue on BlueSky, Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe and by buying a friend a copy of Write Better with Vale, tmux 3, Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.