AI Guide for Economists - Menu
Chapter 5 · Version control

GitHub and Dropbox

How economists should keep code, data, branches, and coauthor work straight.

Here is the source of the confusion. A Git repository has exactly one "current branch" at any moment, and Git has no concept of multiple users. Git only knows "this folder is on branch X." When that folder is synced through Dropbox, every coauthor sees the same folder, which means every coauthor sees whatever branch happens to be checked out. There is no per-user view. There is one folder, one branch, and what is checked out is what everyone gets.

Concrete example. A coauthor switches the folder from main to their sandbox branch coauthor/experiment-X, edits a do-file, and closes their editor without switching back. You open Dropbox the next morning. You see the do-file. You assume it is the team's main version. It is not. It is the version from coauthor/experiment-X, because the folder was left checked out on that branch when your coauthor stopped working.

This is why you must never infer the Git state from what the Dropbox folder looks like. Before editing, always ask: what branch is this folder actually on?

Terminal
git status --short --branch

The Mental Model

Dropbox is the storage layer. GitHub is the collaboration layer. Dropbox can hold your local copies, but GitHub defines the shared code history.

One assumption underlies everything here: economists usually share one Dropbox folder across all coauthors. Everyone sees every clone, and the data, directly on disk. This guide assumes that shared-Dropbox setup. GitHub is still how code is shared, reviewed, and given a history; the shared Dropbox just means you can also see each other's files directly.

For research projects, GitHub and Dropbox solve different problems. Dropbox stores files and syncs them across machines. GitHub records the meaning of code states: which branch is production, which branch is experimental, who changed what, and what was reviewed before it became part of the project.

In economics projects, this distinction matters because code and data have different lives. Code, LaTeX files, small configuration files, and reproducible outputs belong in GitHub. Large datasets, proprietary data, raw extracts, and heavy intermediate files belong in Dropbox and should usually stay out of Git.

Saving Is Not Committing

The deepest source of confusion is not branches, it is the difference between saving and committing. They are two independent systems layered on the same folder.

When you press Ctrl-S, you write the file to disk and Dropbox immediately backs it up across your machines. Git does nothing. Git only records a version when you deliberately run git commit. So Dropbox always holds your latest save, while Git holds only the snapshots you chose to take.

Two consequences follow. First, uncommitted does not mean lost. If you forget to commit and reopen your laptop, you see your saved code, not the old committed version. Git never silently reverts your files; your folder always holds your last save. Second, your coauthors see your work only after commit and push, never from Ctrl-S alone. In your own sandbox that is exactly what you want: half-finished experiments stay private until you choose to share them.

The Folder Layout

The practical setup is simple: keep the project data in Dropbox, and put separate Git clones inside the Dropbox project folder when you need synced local code folders. Each clone is still a normal GitHub repository. Dropbox is only helping your laptop sync the folder.

The reason for multiple code folders is that a Git folder can only show one branch at a time. If two coauthors share one folder called code_experimentation_main/ and each person checks out their own branch, the visible files keep changing depending on the last branch checkout. The folder then stops answering the basic question: whose code am I looking at?

The shared experimentation clone has a different job from the sandbox clones. code_experimentation_main/ is the common baseline that everyone branches from and eventually merges back into. It should stay clean, readable, and close to what the team currently agrees is the active working version.

Each sandbox clone is where one person experiments without changing what everyone else sees. With two coauthors, you have two sandbox folders. With n coauthors, you have n sandbox folders. Each sandbox folder is checked out on that person's Git branch, so the folder name, the branch name, and the human owner all point to the same thing.

Dropbox project layout
Dropbox/project_name/
  data/
    source/
    temp/
    output/

  code_main/
    # Git clone on main
    # Production code that should reproduce the current paper.

  code_experimentation_main/
    # Git clone on experimentation_main
    # Shared baseline for a research phase.

  code_experimentation_main_name1Sandbox/
    # Git clone on name1/experimentation-sandbox
    # Name 1's sandbox for trying changes.

  code_experimentation_main_name2Sandbox/
    # Git clone on name2/experimentation-sandbox
    # Name 2's sandbox for trying changes.

  code_experimentation_main_[NAME]Sandbox/
    # Git clone on [name]/experimentation-sandbox
    # Repeat once per coauthor who needs a sandbox.

The folder name is not decoration. To see why, it helps to know what the hidden .git/ directory actually contains. .git/ holds the full local history of the project: every branch, every commit, every past version of every file, all on disk. It is not a tiny pointer file; it is the entire repository database. The files you see when you open the project folder are not "all branches at once". They are a snapshot of one branch, the one currently checked out. When you switch branches, Git rewrites those visible files from data already inside .git/, instantly and without needing internet, and updates a marker to remember the new active branch. GitHub is a separate copy of .git/ used to sync that history with coauthors via push and pull, not the source of truth.

All of this happens inside Dropbox in our setup: .git/ sits at the root of the project folder, not in your home directory like ~/.claude/, so Dropbox syncs it along with the rest of the project. The active branch is recorded on disk, but Dropbox does not surface it in its file browser UI. You therefore cannot tell from Dropbox alone what branch the folder is on, and the folder name is the workaround: it puts the intended branch in plain sight.

Still, the folder name is only a label. The actual branch is what git status --short --branch reports.

Is Git in Dropbox Safe?

Keeping Git clones inside a shared Dropbox folder raises a fair worry: Dropbox is also mirroring the hidden .git/ database between machines. For the typical usage of economists, the risk is barely there, and the folder design is built to keep it that way.

The only way to corrupt a repository is for two machines to write the same .git at the same moment. Your sandbox is where you work most intensively, so naively that is where trouble would be most likely. That is exactly why each author gets their own sandbox clone: a sandbox is written by only one person on one machine, so the busiest folder is also single-writer and safe. The only residual risk sits on the shared clones, code_main and code_experimentation_main, which several people reach into but which you touch rarely.

This is a different problem from "whose code am I looking at." Separate folders solve the branch-confusion problem. They do not, by themselves, stop Dropbox from mirroring .git. What protects you there is that sandboxes are single-writer, plus the one heads-up habit for shared clones below.

The Branch Model

Use main for production code. It should reproduce the latest paper, slides, and core results from beginning to end. Do not commit directly to main; use a branch and a pull request.

For a major phase, create a shared working branch such as experimentation_main or revision_r1_main. This becomes the team's active baseline while main stays stable. Individual sandboxes branch from that shared working branch, not from main.

Branch structure
main
  Production branch.

experimentation_main
  Shared working branch for the current phase.

name1/experimentation-sandbox
  Name 1's personal experiment.

name2/experimentation-sandbox
  Name 2's personal experiment.

name/experimentation-sandbox
  Repeat once per coauthor who needs a sandbox.

What to Ask Claude Code

You do not need to memorize Git commands to work correctly. Ask Claude Code to set up the folder and branch structure, then make it verify the branch before editing.

Start a shared experimentation phase
Please create a separate Dropbox code folder called code_experimentation_main/.
It should be a clone of the same GitHub repository, checked out on a shared
branch called experimentation_main.

If experimentation_main does not exist yet, create it from main, push it to
GitHub, and verify that the local folder tracks the GitHub branch.
Work in a personal sandbox
Please work in code_experimentation_main_[NAME]Sandbox/.
First verify which Git branch this folder is on. Then pull the latest version
of the sandbox branch from GitHub.

After making the code changes, show me the changed files, run the relevant
checks, commit the changes to the sandbox branch, and push the branch to
GitHub.

Rules That Prevent Painful Mistakes