Introduction

Running git pull over many subdirectories is a common maintenance task when you keep multiple repositories under one parent directory. The main challenge is not looping over directories. It is doing so safely, only in actual Git repositories, and without masking failures or trampling dirty working trees. A good solution should make those checks explicit.

Use find and git -C to Target Real Repositories

A reliable shell pattern is locating .git directories and then running Git against the parent directory.

1find . -type d -name .git -prune | while read -r gitdir; do
2  repo_dir="$(dirname "$gitdir")"
3  echo "Updating $repo_dir"
4  git -C "$repo_dir" pull --ff-only
5 done

This avoids trying to run git pull in ordinary directories that just happen to sit under the same tree.

Using git -C is cleaner than repeatedly cd-ing in and out of directories because the current shell context stays stable.

Check for Dirty Working Trees First

Blindly pulling every repository is risky if some of them have local changes.

1find . -type d -name .git -prune | while read -r gitdir; do
2  repo_dir="$(dirname "$gitdir")"
3
4  if ! git -C "$repo_dir" diff --quiet || ! git -C "$repo_dir" diff --cached --quiet; then
5    echo "Skipping dirty repo: $repo_dir"
6    continue
7  fi
8
9  echo "Pulling clean repo: $repo_dir"
10  git -C "$repo_dir" pull --ff-only
11 done

This protects you from surprising merge behavior in repositories that are mid-work.

The --ff-only option is also deliberate. It makes the update fail instead of creating an unexpected merge commit.

Decide Whether You Want Pull, Fetch, or Rebase

git pull is not the only possible operation. Depending on your workflow, you may prefer:

• 'git fetch to refresh remote state without changing local branches'
• 'git pull --ff-only for safe fast-forward updates only'
• 'git pull --rebase if your team uses a rebase-based workflow'

The loop structure stays the same. What changes is the operation you run inside it.

For many multi-repo maintenance tasks, fetch is safer as a first pass because it never rewrites the working branch unexpectedly.

Handle Failures Per Repository

One bad repository should not hide the state of the others. Emit clear output and keep going.

1find . -type d -name .git -prune | while read -r gitdir; do
2  repo_dir="$(dirname "$gitdir")"
3  echo "== $repo_dir =="
4
5  if git -C "$repo_dir" pull --ff-only; then
6    echo "OK"
7  else
8    echo "FAILED"
9  fi
10 done

This makes the command useful as an operational report rather than a noisy one-liner that leaves you guessing where the problem occurred.

Consider a Dedicated Multi-Repo Tool When the Pattern Is Permanent

If you do this constantly, raw shell loops may not be the best long-term interface. Tooling such as Git submodules, repo managers, or a small project-specific maintenance script can make the workflow more explicit.

The point is not that shell loops are wrong. The point is that repeated operational tasks deserve a shape that matches how often they are used.

Common Pitfalls

• Running git pull in every subdirectory instead of only actual Git repositories.
• Pulling over dirty working trees and triggering conflicts or accidental merges.
• Using plain git pull when --ff-only or even fetch would be safer.
• Writing a loop that stops at the first error and hides the condition of later repositories.
• Treating many unrelated repositories like one project when a stronger multi-repo workflow would be clearer.

Summary

• Use find plus git -C to run Git commands only in real repositories.
• Check for local modifications before pulling.
• Prefer safe update modes such as --ff-only when you automate pulls.
• Report failures per repository instead of hiding them in one large loop.
• If the task is permanent, consider a more explicit multi-repo workflow than ad hoc shell commands.