Git Workflows for Distributed Teams Across Time Zones

1. The core problem of asynchronous collaboration

In a co-located team, a merge conflict or an unclear commit message can be resolved in seconds by simply asking across the room. Across several time zones, eight to twelve hours often pass between a question and its answer, sometimes an entire working day.

That changes the requirements for a Git workflow fundamentally. Every commit, every pull request description, and every branch name has to carry enough context that a colleague on the other side of the world can keep working without needing to ask.

Teams that do not make this shift consciously run into familiar symptoms: pull requests sit untouched for days because nobody understands what needs reviewing, and simple conflicts escalate because clarification is only possible the following day.

# Make time zones visible within the team, e.g. in the PR template
# Reviewer at UTC minus 8, author at UTC plus 1: realistically 16 hours latency
git log --format='%an <%ae>, %ad' --date=iso -1

2. Branching strategy for follow the sun development

Trunk-based development with short lived feature branches usually suits distributed teams better than GitFlow with its long lived develop and release branches. The shorter a branch lives, the less time there is for it to drift from the main line across time zones.

A branch that stays open longer than a day or two carries a noticeably higher conflict risk in a distributed team than in the same office, simply because nobody can quickly check in on whether a change to the main line has any impact.

In practice this means features get broken into small, independently mergeable steps, hidden behind feature flags, instead of maturing in a single large branch over weeks. That keeps the main line in a state every time zone can build on immediately.

# Create a short lived feature branch and merge it back quickly
git switch -c feature/checkout-validation
# ... small, self contained change ...
git push -u origin feature/checkout-validation
gh pr create --fill --base main

3. Commit message discipline as a stand in for conversation

In a distributed team, a commit message is often the only communication a colleague in another time zone receives about a change. A terse subject line rarely covers that, the body of the message needs to explain why, not just what.

A proven format follows this pattern: a subject line of at most 50 to 72 characters, a blank line, then a paragraph explaining the reason for the change plus relevant ticket references. That lets a reviewer follow the decision without reaching the author.

Conventional Commits as a format help further, because they make the type of change instantly recognizable. A colleague scanning the overnight history recognizes at a glance, from fix: or feat:, which commits matter for their current work.

git commit -m "fix(checkout): correct rounding error in discount calculation

For percentage discounts under one euro, the amount was rounded
incorrectly, causing the total price to be off by one cent. The
cause was a missing rounding step before the sum was computed.

Ref: PROJ-482"

4. Pull requests as an asynchronous communication tool

In a distributed team, the pull request description is not optional, it is the central document a reviewer relies on when the author cannot be asked live. A good description states the context, the chosen solution, open questions, and the test path.

Draft pull requests are an underrated tool for follow the sun work: a developer opens a draft with the current state before ending their day, so the team in the next time zone immediately sees what is being worked on, even if the change is not finished yet.

Just as important is explicitly naming reviewers and setting clear expectations for response time. Without a firm convention, pull requests in distributed teams tend to stay open noticeably longer than in co-located teams.

# Open a draft PR before ending the day so the next time zone can continue
gh pr create --draft --title "WIP: Checkout validation" \
  --body "Status: base validation done, edge cases still missing. Please do not merge yet."

5. Minimizing merge conflicts across time zones

A conflict that gets resolved in five minutes in an office can block an entire working day across time zones. It therefore pays off to structurally lower the conflict risk instead of only reacting to it after the fact.

Small, topically focused pull requests significantly reduce the chance of overlapping changes to the same files. A branch that only touches one file or a clearly bounded module collides less often with parallel changes coming from another time zone.

Regularly rebasing or merging the main line into your own feature branch, ideally at the start of every shift, surfaces conflicts early while the original author is still available, instead of discovering them only at the final merge.

# Keep your own branch current at the start of a shift
git switch feature/checkout-validation
git fetch origin
git rebase origin/main
# Resolve conflicts now, while context is still fresh

6. Automated gates instead of live reviews

Because a human reviewer is often not immediately available, as many quality criteria as possible should be checked automatically before review. Linting, tests, and static analysis as mandatory checks in the CI pipeline take trivial error classes off the human reviewer's plate.

Required status checks in branch protection rules ensure that a merge is only possible once all automated gates are green. That decouples quality assurance from the availability of specific people in specific time zones.

Bots for automatic reviewer assignment, based on CODEOWNERS and working hours, further ensure a request lands as directly as possible with someone who is actually online right now, instead of sitting in the inbox of someone at the end of their day.

# CODEOWNERS sets automatic reviewers per directory
# .github/CODEOWNERS
/src/checkout/  @team-checkout-eu @team-checkout-us
/src/payments/  @team-payments

7. Time zone aware release and freeze windows

A release started right before the only person who knows the deployment pipeline logs off is a risk. Distributed teams should deliberately schedule releases within a window where multiple time zones are active at once, so a problem can be addressed quickly.

Code freeze periods before a release should be clearly communicated and visible on calendars across every involved time zone. Without that clarity, it easily happens that one time zone keeps working during the freeze simply because the information did not reach them in time.

A rollback plan that can be executed without asking a specific person first is essential for distributed teams. The person who notices a broken deploy is rarely the same one who originally triggered it.

# Release tag with a clear timestamp readable across every time zone
git tag -a v2.4.0 -m "Release 2.4.0, freeze from 2026-08-10 14:00 UTC"
git push origin v2.4.0

8. Documentation in the repository instead of tribal knowledge

In a distributed team, nobody can rely on knowledge simply being passed along verbally, since working hours barely overlap. Architecture decisions therefore belong directly in the repository as Architecture Decision Records, not in meeting notes that only one time zone ever heard.

A CODEOWNERS file makes visible who owns which area, independent of who happens to be online right now. That reduces the number of questions that go nowhere because they are asked of the wrong person or at the wrong time.

An up to date README with setup instructions, test strategy, and deployment process in the repository itself replaces many follow up questions that would otherwise only get answered after many hours of waiting.

# Store and version an ADR directly in the repository
mkdir -p docs/adr
git add docs/adr/0007-client-side-checkout-validation.md
git commit -m "docs: ADR 0007 on client side checkout validation"

9. Tooling for distributed collaboration

Besides draft pull requests, scheduled merges help, where a pull request is automatically merged at a set time once all checks pass. That lets an author in Europe prepare a merge for the start of the US working day without having to be awake for it.

Notifications should be configured so they do not intrude outside of someone's own working hours but still arrive reliably once a shift begins. Many teams use daily digests instead of real time notifications for every single piece of PR activity.

A shared dashboard, visible across every time zone, listing open pull requests, their age, and check status helps spot bottlenecks early, before a change sits unnoticed for days.

# List open PRs untouched for more than two days
gh pr list --search "is:open updated:<$(date -d '-2 days' +%Y-%m-%d)"

10. Summary

11. FAQ: Distributed Teams