Managing Source Code: Shared Folders and Version Control with Git

final_v2_REALLY_final.py

You have probably seen a folder like this: essay.docx, essay_v2.docx, essay_final.docx, essay_final_FIXED.docx. Now imagine four people doing that with twelve program files at once. Someone emails a module to a teammate who has already changed it. Someone copies an old file over a new one. A bug appears and nobody knows which change caused it, or how to get back the version that worked yesterday.

The curriculum asks you to use shared resources to manage source code effectively and securely, for example by organizing software components using shared files and folders with timestamps, and proper version control. This lesson covers both: an organized shared folder, and Git, the version control system used by most of the software industry.

Level 1: an organized shared folder

Even before version control, a team needs a clear, shared folder structure that everyone follows:

• One folder per kind of thing: source code (src), tests (tests), sample data (data), documents (docs).
• Clear, consistent names in lower case with no spaces: test_loans.py, not Test Loans NEW.py.
• Date stamps in ISO order for documents that come in a series: 2026-11-20_status-report-3.md. Putting the year first means alphabetical order is time order.
• One copy of each file in the shared place, which everyone reads from and saves to; no private copies emailed around.

A shared folder alone cannot stop two people from overwriting each other's work or recover yesterday's version. For that you need version control.

Level 2: version control with Git

A version control system records every change: what changed, who changed it, when, and why. With it you can:

• go back to any earlier version of any file;
• see exactly which change introduced a bug;
• let several people work on the same project at once and combine their changes safely (next lesson);
• keep a backup: every team member's copy of a Git repository contains the full history.

Git is free and runs on Windows, macOS and Linux (download it from git-scm.com, or ask a parent or teacher to install it). It is used from a terminal; most editors, including VS Code and Thonny, also have Git buttons. If you cannot install anything, free hosting sites such as GitHub let you create a repository and commit files in a web browser (check the site's age rules and ask a parent first).

Three places your work can be

Git thinks about your files in three places:

1. The working directory: the normal files you edit.
2. The staging area: the changes you have chosen for the next commit (git add puts them there).
3. The repository: the permanent history of commits (git commit saves a snapshot there).

The staging area lets you commit related changes together. If you fixed a bug and also started a new feature, you can stage and commit the bug fix by itself, with its own message.

Your first repository

Here is Priya starting LendIt's repository early in the project. The lines starting with $ are commands typed in a terminal; the other lines are Git's replies. (This listing is a terminal session, not Python.)

Now Priya adds a line, checks what changed, and commits again. git status --short gives a one-line summary (M means modified). git diff shows the exact lines: + for added, - for removed.

How Git knows that nothing was changed behind its back

Git names every file version, folder listing and commit by a hash: a 40-character code calculated from the contents with the SHA-1 function (by default). The same contents always give the same hash; changing even one letter gives a completely different one. Because each commit's hash includes its parent's hash, changing any old file would change every later commit's ID, so tampering or disk damage is easy to detect. This program calculates a file's ID the way Git does: the word blob, the length, a zero byte, then the contents.

Writing good commit messages

A project's history is only useful if you can read it. Teams agree on a message style, such as:

• A summary line of at most about 50 characters, starting with a capital letter, no full stop.
• The imperative mood, as if giving an order: "Add late fee cap", not "Added" or "Adds". (Read it as "If applied, this commit will add late fee cap.")
• Mention the requirement or task ID: "(R3)" or "(task F)". This links the code to the traceability matrix and the schedule.
• If needed, a blank line and then a longer explanation of why.

Commit small, commit often: one logical change per commit, and commit whenever the tests pass. Small commits are easy to review and easy to undo.

Keeping a repository secure and clean

"Securely" matters in B1.7. Three rules:

1. Never commit secrets: passwords, access keys, members' personal data. Everything in the history stays there, even after you delete the file, and anyone with a copy of the repository can read it. Keep secrets in a separate file listed in .gitignore, and use made-up sample data (like sample_items.csv) for testing.
2. Ignore generated files: __pycache__/ folders and other files that Python or your editor rebuilds automatically. List them in .gitignore so they never clutter git status.
3. Control access: a shared repository should be private, shared only with team members and the teacher, unless the client agrees to make it public.

And make backups: a repository on a hosting site, a school server or a USB key kept in a different place from the main computer.