Set Up a Workspace You Can Safely Change

Create a place to experiment, record a known state, and practice getting back to it.

A small edit breaks a working script. The AI assistant suggests another edit, then another. Soon nobody remembers the original file or which change caused the problem.

A useful workspace makes changes visible and recovery ordinary. You need a clear project boundary, a record of known versions, isolated dependencies, and a way to tell which files belong to the experiment.

These tools do different jobs. Version control records selected files. An environment isolates dependencies. A backup protects against loss of the project itself. None should be assumed to replace the others.

Give the project a clear boundary

Use a dedicated folder for the learning project. Keep source code, sample inputs, generated output, and setup instructions distinguishable. Avoid beginning in a folder full of unrelated personal files.

For a small project, a few clearly named files are enough. You do not need an elaborate directory structure merely to appear professional.

Record which commands read files, which write them, and where output will go. A command run from the wrong working directory may affect a different project than intended.

The lab below creates a uniquely named disposable project beside the script. It does not reuse an existing repository or change global Git identity settings.

Understand the parts of version control

Git records snapshots of selected content in commits. The working tree contains the files you are editing. Staging chooses what the next commit will include. A diff shows changes between relevant states.

A branch is a movable reference to a line of development; it is useful for organizing experiments, but it does not create an independent backup of the repository. You can learn the initial recovery task without introducing branches yet.

Review the diff before recording a change. A commit message should explain the purpose of the change, not merely say “AI update.”

Git’s initialization documentation explains repository creation. Its restore documentation describes restoring selected paths from a specified source. A restore can discard uncommitted changes to the selected file, so use it deliberately on the disposable example after inspecting the diff.

Isolate dependencies without overstating the boundary

A Python virtual environment gives a project its own interpreter environment and package installation area. It helps avoid accidental interference between dependency sets. It does not prevent a program from reading files, using the network, or acting with the operating-system permissions of the user running it.

The official Python venv documentation describes creation and use, including direct invocation of the environment’s interpreter without activation. That direct invocation makes the lab’s interpreter choice explicit on both Windows and POSIX systems.

The example uses only the standard library and creates its environment without pip. No package installation or network download is required by the lab itself. A project with external dependencies would need setup instructions and a reproducible dependency specification appropriate to its package manager.

Record the Python version as well as package versions. A list of package names alone is not a complete reproducible environment description.

Run a complete recovery exercise

Save this script as workspace_lab.py in a disposable learning folder with Python 3 and Git available. It creates a new project, records print(2 + 3), changes it to subtraction, shows the diff, restores the committed file, and checks that the result is five again.

import os
from pathlib import Path
import subprocess
import sys
import tempfile

root = Path(tempfile.mkdtemp(prefix="workspace-", dir=Path(__file__).parent))
def git(*args):
    return subprocess.run(["git", *args], cwd=root, check=True,
                          capture_output=True, text=True).stdout.strip()

git("init", "--quiet")
(root / ".gitignore").write_text("ai-env/\n__pycache__/\n.env\n", encoding="utf-8")
app = root / "app.py"
app.write_text("print(2 + 3)\n", encoding="utf-8")
git("add", "app.py", ".gitignore")
git("-c", "user.name=Learning Example", "-c",
    "[email protected]", "commit", "--quiet", "-m", "Known working baseline")
subprocess.run([sys.executable, "-m", "venv", "--without-pip", str(root / "ai-env")], check=True)
python = root / "ai-env" / ("Scripts/python.exe" if os.name == "nt" else "bin/python")
def output():
    return subprocess.run([str(python), str(app)], check=True,
                          capture_output=True, text=True).stdout.strip()
assert output() == "5"
app.write_text("print(2 - 3)\n", encoding="utf-8")
assert output() == "-1"
print(git("diff", "--", "app.py"))
git("restore", "--source=HEAD", "--worktree", "--", "app.py")
assert output() == "5"
assert git("status", "--porcelain") == ""
print("Recovered output:", output())
print("Disposable project:", root.resolve())

The exercise creates its own new directory next to the script. It does not initialize Git in an existing project or change your global Git identity. The temporary name printed at the end identifies the directory to inspect afterward.

There are three different pieces of evidence. The original program prints 5. The modified program prints -1. After restoration, the program prints 5 again, and Git reports no tracked changes. Seeing the original output alone would be weaker: someone could simply have edited the program a second time. The displayed diff and clean status help explain which version was restored.

This exercise ran successfully with Python 3.12.13 and Git during preparation of this article. It uses Python's standard library and installs no third-party packages. Your environment still needs a working Python installation and Git on its command search path.

Know what restoration actually restores

The command in the exercise selects one file and restores its working copy from the current commit. It discards that file's uncommitted edits. Before applying the same idea in a real project, inspect the diff and preserve any work you want to retain. A restoration command cannot decide whether a change was valuable.

Git's working tree, staging area, and commits are separate concepts. The working tree is what you are editing. The staging area selects content for a future commit. A commit records a snapshot. The explicit flags in this exercise make the source and destination of the restoration visible. Other combinations can change the staging area too. Git's restore documentation explains those distinctions.

Source recovery also differs from data recovery. If a script modified a spreadsheet outside the repository, restoring its source code would not restore that spreadsheet. If an application sent a message, changing the code would not unsend it. The recovery plan must cover the effect you intend to permit.

For a first file-processing project, work on disposable copies and write results to a new directory. That arrangement makes a failed experiment easy to inspect without depending on a perfect undo function. Article 106 uses this approach.

Keep secrets outside the shared project

A project may eventually need an API credential. Keep that credential in a protected environment setting or the appropriate secret service for the deployment environment. Your README can document the variable name without including its value.

The .gitignore file in the exercise excludes a file named .env. That is a convenience, not a complete secret protection system. Ignoring a filename does not remove content that was already committed. It also does not prevent a program, screenshot, terminal transcript, or AI conversation from exposing the same secret.

Before sharing a project, inspect the actual diff and the files being included. A harmless example value should be unmistakably fictional. Do not paste a real credential into a prompt so an assistant can check its formatting.

If a credential has been exposed, removing the visible text is only part of the response. Revoke or rotate the exposed credential through its issuer and check where it may have been used. For this lesson, the strongest practical choice is simpler: the project needs no credential at all.

Make the workspace explainable to someone else

A useful README tells another person how to reproduce the result. Include the supported interpreter version, the entry command, the expected output, the files that may change, and the recovery method. Also identify any dependency installation that would require network access.

When a later project uses third-party packages, record dependency versions using the package manager's supported workflow. A version list alone does not guarantee identical behavior across operating systems, hardware, or external services. The objective is to make the important assumptions explicit enough to investigate differences.

Keep the project narrow. A coding assistant working on a title-cleaning function does not need your home directory, email account, or production database. The permissions you grant should follow from the task's actual inputs and outputs.

A virtual environment helps separate Python dependencies. It does not prevent a script from reading or writing files accessible to your user account. That distinction matters because a tidy project directory can look more isolated than it really is. Python's virtual-environment documentation describes what the environment creates and how to use its interpreter directly.

A reusable prompt

Help me set up an isolated learning project for [task] on [operating system]. Explain every proposed command's effect before showing the command. Use synthetic inputs, name the files that may change, and define a verified baseline. Show how to inspect a diff and restore one deliberately changed file. Keep credentials out of the project. Explain which effects version control can recover and which need a separate data recovery plan.

For students: submit evidence of a reproducible experiment

A strong programming submission can include the specification, the baseline result, one intentional change, the resulting diff, and the recovery result. Together, those artifacts show understanding of the development process.

If the assignment permits AI assistance, record how it helped: perhaps it explained a command, suggested a directory structure, or identified a missing recovery step. Follow the instructor's disclosure requirements. You should still be able to explain why restoring a source file cannot reverse a change to an external dataset.

For group projects, agree on which files belong in version control before collecting any real data. Use synthetic fixtures during setup. A student should be able to clone or copy the project and run its basic checks without receiving another student's personal files or credentials.

Practice: break and recover a tiny project

Run the complete exercise in a learning directory. Read the printed diff and locate the disposable project. Identify the baseline commit and explain why the virtual environment does not appear as a tracked change.

Then create a second, equally small program of your own. Record a baseline, change one behavior, inspect the difference, and restore that file using an explicit source commit. Write down the expected output before each run.

Completion check: You can reproduce the original output, identify the exact restored version, and explain what would happen to an unrelated file outside the repository. No secret or private dataset is needed to reproduce your work.

Stretch: Write a README that lets a classmate reproduce the exercise on a fresh machine. Ask them to follow it without verbal assistance, and revise the first instruction that causes uncertainty.