Digital Workplace Tools: File Systems, Version Control Concepts, Cloud Storage, and Productivity Suites

Why File Organization and Version Control Matter

Data science projects generate many files quickly: raw data downloads, cleaned datasets, Jupyter notebooks, visualizations, and written reports. Without a deliberate system, files become impossible to trace, teammates overwrite each other's work, and errors are hard to reverse. Professional data teams solve this with three practices working together: a standardized folder structure, version control through Git, and cloud collaboration through a productivity suite.

Standardized Project Folder Structure

A consistent folder layout means any teammate — or your future self — can navigate a project without asking questions. A widely accepted convention in data science uses these top-level folders inside one project root folder:

• raw_data/ — original source files, never edited after download
• processed_data/ — cleaned or transformed versions of the source files
• notebooks/ — Jupyter notebooks or other analysis scripts
• reports/ — final outputs: charts, slide decks, written summaries
• docs/ — documentation, data dictionaries, meeting notes

Placing a README.md file at the root level is standard practice. A README is a plain-text file written in Markdown that tells readers what the project is, where the data came from, what each folder contains, and how to run any code. It is the first file a new collaborator reads.

File Naming with snake_case

File names should be machine-readable and human-readable. The snake_case convention joins words with underscores and uses only lowercase letters, digits, and underscores — no spaces, no capital letters, no special characters. For example: `sales_data_2024_raw.csv`, `clean_customer_records.csv`, `exploratory_analysis_v1.ipynb`. Spaces in file names break command-line tools and cause errors in many programming environments.

Version Control with Git

Git is a distributed version-control system that records every change you make to a project over time. Each saved snapshot is called a commit. You can review, compare, or restore any earlier commit, which makes it safe to experiment.

Core Git workflow — four commands you use every session:

1. `git init` — creates a new, empty Git repository in the current folder

2. `git add <filename>` or `git add .` — stages files, meaning you are telling Git which changes to include in the next snapshot

3. `git commit -m "descriptive message"` — saves a permanent snapshot with a human-readable message explaining what changed and why

4. `git push origin main` — uploads your local commits to a remote repository on GitHub so others can see your work and it is backed up off your machine

A commit message should be specific: write `Add raw sales CSV and initial README` rather than `update files`. Future reviewers — including yourself — depend on these messages to understand history.

The edit-stage-commit cycle is the normal rhythm of work: make a meaningful change, stage it, commit it with a message, repeat. Committing after each logical unit of work (not after every keystroke, and not after a week of changes) gives you a useful, navigable history.

GitHub

GitHub is a web-based hosting service for Git repositories. A remote repository on GitHub stores your project in the cloud and enables collaboration. After creating a free account and a new repository on GitHub, you link your local project to it with `git remote add origin <URL>`, then push. Your code and its full history become visible and shareable.

Cloud Storage and Collaboration

Google Drive and Microsoft OneDrive are cloud storage platforms bundled with productivity suites (Google Workspace and Microsoft 365 respectively). Both allow you to store files, sync them across devices, and share them with precise permission settings.

Permission levels to know:

• Viewer — can read files only
• Commenter — can read and leave inline comments, cannot edit content
• Editor — can make direct changes

For peer review and feedback on a README or report, comment-only access is the appropriate choice: collaborators can annotate without accidentally altering your work. In Google Docs or Word Online, you can add an inline comment by selecting text and clicking the comment icon. The document owner can then resolve a comment once the feedback is addressed, which hides it from the main view while preserving the record.

Safety and Professional Responsibility

Digital workplace safety is real. Several principles apply directly to this work:

• Never commit credentials or passwords. If an API key, database password, or personal access token is accidentally pushed to a public GitHub repository, it must be considered compromised immediately. Use a `.gitignore` file to exclude sensitive files and environment variables.
• Protect personal data. Raw data files containing names, addresses, or other personally identifiable information (PII) should not be pushed to public repositories. Check data for PII before committing.
• Permission discipline. Share cloud folders at the minimum permission level needed for the task. Over-sharing editor access increases the risk of accidental data loss or corruption.
• Back up regularly. Pushing to GitHub and syncing to cloud storage are both forms of backup. Relying on only one copy of a project on a single computer is a professional risk.

Bringing It Together

A professional data project folder committed to GitHub and shared through a cloud platform demonstrates three skills employers look for in every role that touches data: organization, reproducibility, and collaboration. The Google Data Analytics Certificate, IBM Data Science Professional Certificate, CompTIA Data+, and Microsoft PL-300 exam all assume you can navigate and describe a structured project environment — this lab builds exactly that foundation.