Paste into SafeAppeals chat for guided help with this topic.

Local Git Backups

Optional version history for a case folder on this computer—so you can see what changed and roll back mistakes. This is a backup habit for matter work, not a requirement to publish anywhere.

Privacy rule: For client matters and legal case folders, use Git locally only. Do not push confidential case data to GitHub or any other remote unless you explicitly trust that provider and confirm you intend to send the files off this machine.

What Source Control Means Here

SafeAppeals includes a Source Control view (built on Git) so you can stage and commit changes to files in your open folder. For appeal work, that usually means:

  • A dated history of drafts, briefs, and correspondence you choose to commit
  • A way to compare versions of a file before you overwrite something important
  • A local safety net if you reorganize folders or regenerate notes

You do not need a GitHub account, pull requests, or a coding forge to use this. SafeAppeals does not run git init for you—start a repository only when you want local history.

Stays on This Computer

Commits live in a .git folder inside your case workspace unless you add a remote

Optional History

Commit when it helps you; skip it entirely if file copies are enough

Never Push Case Data

Legal matters: local backup only. Coding projects are a different path

Prerequisites

Source Control uses Git installed on your machine:

  1. Install Git 2.0+ for your OS if it is not already available (git-scm.com).
  2. Optionally set your name and email once (used only in local commit metadata):
    git config --global user.name "Your Name"
git config --global user.email "you@example.com"

These settings label commits on your machine. They do not create a remote account or upload your case folder.

Open Source Control for a Case

  1. Open your case folder (File → Open Folder) or its .code-workspace file
  2. Click the Source Control icon in the left activity bar (branch icon), or press Ctrl+Shift+G
  3. If the folder is not a Git repository yet, SafeAppeals prompts you to initialize one—only do that if you want local history

Tip: Try this on the sample case from Help → Tutorials first. The sample includes teaching notes about local git backups and ships a starter .gitignore—no credits, fictional data only.

Initialize a Repository (Optional)

When Source Control shows that the folder has no repository, choose Initialize Repository (or run Command Palette → Git: Initialize Repository). That creates a local .git directory in the case folder.

  • SafeAppeals will not initialize Git automatically for new cases
  • Skip initialization if you prefer ordinary file backups instead
  • Do not add a remote for client matters

Stage and Commit Locally

After you edit files in the case folder:

  1. Open the Source Control view
  2. Review the list of changed files. Click + next to a file to stage it, or stage all when you are ready
  3. Type a short commit message (for example, "Add treating physician note" or "Update AGENTS.md claim snapshot")
  4. Click Commit (checkmark). The snapshot stays on this computer

Lawyer-Friendly Commit Habits

  • →Commit after meaningful milestones—not after every keystroke
  • →Prefer clear messages you would understand months later
  • →Review the change list before committing so temporary junk is not included

Never Push Legal Case Data

Pushing sends your committed files to a server outside this computer. For workers' compensation and other client matters, treat that as disclosing confidential documents.

  • Case / legal workspaces: commit locally when you want history; never push to GitHub or another remote. If you (or the assistant) are asked to push, stop and confirm explicitly—confidential documents would leave this machine.
  • Pure coding / software projects that are not client matters may push after you clearly intend to publish—confirm once, then proceed.

Ignore prompts to "Publish to GitHub," sync remotes, or open pull requests for case folders. Those paths are for software collaboration, not appeal files.

Selective .gitignore for Case Work

A .gitignore file tells Git which paths to skip. The Tutorials sample case includes one with this teaching posture:

  • Ignore SafeAppeals organizer churn (for example .safeAppeals/organization_log.json, .safeAppeals/undo_plan.json, and to_sort/_originals/)
  • Ignore everyday OS/editor junk (.DS_Store, temp Office files, and similar)
  • Keep case document folders, .safeAppeals/skills/, and .safeAppeals/agents/ trackable so skills and matter files can be part of local history
  • Optionally ignore timeline state by uncommenting .safeAppeals/timeline.json in the sample ignore file if you do not want that JSON in history

For Plan Mode files under .safeAppeals/plans/, you may also choose to ignore plan drafts when they contain case strategy—see the Plan Mode guide.

Example ignore posture (from the sample case)

# Organizer churn
.safeAppeals/organization_log.json
.safeAppeals/undo_plan.json
to_sort/_originals/

# OS & editor junk
.DS_Store
Thumbs.db
~$*
*.tmp

# Optional — uncomment to skip timeline state
# .safeAppeals/timeline.json

Diffs and File Timeline

Two quiet tools help you review history without leaving SafeAppeals:

  • Diff view — From Source Control, open a changed file to see what differs from the last commit (side-by-side or inline)
  • Timeline (Explorer) — Select a file, then open the Timeline pane to scan prior Git commits for that file. Useful when you need “what did this letter look like last week?”

This Timeline pane is Git/file history—not the Case Timeline for deadlines. For hearings and filing dates, see the Timeline & Deadlines guide.

What to Skip for Case Work

Features aimed at software teams are easy to ignore for legal folders:

  • Publish / sync to GitHub or other remotes
  • Pull requests, issues, and forge integrations
  • AI-generated commit messages (optional; write your own plain labels)
  • Marketplace SCM providers beyond built-in Git

Next Steps

First StepsCase ManagementFAQ