Claude Code for RAs - Menu
Chapter 5 · Version control

GitHub and Dropbox

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

The most common GitHub and Dropbox confusion is that Dropbox shows the files from the branch a local Git folder is currently on. It does not show "your branch" as a separate concept. It shows the actual files sitting in that folder at that moment.

Suppose a coauthor creates a sandbox branch, modifies a do-file, and checks out that branch in a Dropbox-synced folder. The do-file you see in that Dropbox folder is now the version from the coauthor's sandbox branch. It can look like the shared project code, or like your own working copy, even though the folder is actually on a different branch.

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.

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.

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. It makes the intended branch visible in Dropbox, where Git branch state is otherwise hidden inside the .git/ folder. Still, the folder name is only a label. The actual branch is what git status --short --branch reports.

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