diff --git a/01_materials/03_git_log_checkout.md b/01_materials/03_git_log_checkout.md index 96ad6e0..b6a933c 100644 --- a/01_materials/03_git_log_checkout.md +++ b/01_materials/03_git_log_checkout.md @@ -16,7 +16,7 @@ ls Clone an existing repository from GitHub: ```bash -git clone https://github.com/simeon-demo/recipe-book.git +git clone https://github.com/gvwilson/recipe-book.git ``` Navigate into the cloned repository: diff --git a/01_materials/05_git_merge_conflicts.md b/01_materials/05_git_merge_conflicts.md index ce338d6..0e1419c 100644 --- a/01_materials/05_git_merge_conflicts.md +++ b/01_materials/05_git_merge_conflicts.md @@ -3,7 +3,7 @@ ## Setup: Clone the Team Playlist Repository ```bash -git clone https://github.com/simeon-demo/team-playlist.git +git clone https://github.com/gvwilson/team-playlist.git cd team-playlist-demo ``` diff --git a/01_materials/git_cheatsheet.md b/01_materials/git_cheatsheet.md index 1e37ea7..808b7b1 100644 --- a/01_materials/git_cheatsheet.md +++ b/01_materials/git_cheatsheet.md @@ -3,11 +3,11 @@ ## 🔧 Configuration ```bash -git --help # Show overview of Git commands -git config --global user.name "Simeon" # Set your Git username globally -git config --global user.email "me@simeon.dev" # Set your Git email globally -git config list --global # List global Git configuration settings -git config --global core.editor "code --wait" # Set VS Code as default Git editor +git --help # Show overview of Git commands +git config --global user.name "gvwilson" # Set your Git username globally +git config --global user.email "gvwilson@third-bit.com" # Set your Git email globally +git config list --global # List global Git configuration settings +git config --global core.editor "code --wait" # Set VS Code as default Git editor ``` --- diff --git a/01_materials/slides/git_as_story.html b/01_materials/slides/git_as_story.html new file mode 100644 index 0000000..41bab50 --- /dev/null +++ b/01_materials/slides/git_as_story.html @@ -0,0 +1,534 @@ +Git as a Story
+

Git as a Story

+

A Version Control Journey for Everyone

+
+
+

🧭 Why Version Control Matters

+

You already use version control informally:

+
    +
  • report_final_v3_reallyfinal.xlsx
    • +
  • Multiple presentation drafts
    • +
  • Document copies "just in case"
    • +
+

Sound familiar?

+
+
+

The Questions We Ask

+

When someone hands you a file, you want to know:

+
    +
  • Who made this?
    • +
  • Where did the data come from?
    • +
  • Why did they make these changes?
    • +
  • How did it change over time?
    • +
  • Does it have the latest updates?
    • +
+
+
+

What You Really Want

+

Like a lab notebook for your work:

+
    +
  • Undo mistakes
    • +
  • Go back in time to see what changed
    • +
  • Audit trail of edits
    • +
  • See which experiments were run
    • +
  • Understand what worked before
    • +
+

Git was designed to serve this need.

+
+
+

Building from Scratch

+

Let's design this system together.

+

Simple approach: Make a copy every time we like our work

+
    +
  • report_v1 → report_v2 → report_v3
    • +
+

Works ok for single files. But what about projects?
+report_v1 also depends on other files (images, spreadsheet, charts, other code files)

+
    +
  • It can get unmanageable quickly
    • +
+
+
+

Building from Scratch

+

Option 2:
+Google Docs and Office 365 save automatically...

+

But what if:

+
    +
  • You step away mid-edit
    • +
  • The snapshot catches a broken state
    • +
  • You didn't mean to save yet
    • +
+
+
+

The Best of Both Worlds

+

Option 3:
+Let's create a COMMIT BUTTON that:

+
    +
  • Takes a snapshot when you decide
    • +
  • Saves the entire folder, not just one file
    • +
  • Lets you add a message describing the change
    • +
  • Doesn't create file explosion (v1, v2, v3...)
    • +
+

Why save the whole folder?
+Otherwise: report_v20 + spreadsheet_v3 + image_v6 = chaos!

+
+
+

📸 Commit: Your Time Machine Control

+

Click COMMIT to:

+
    +
  1. Save a snapshot of your work
    2. +
  2. Write a message: "What changed and why?"
    3. +
  3. Create a known good state
    4. +
+

Now you have a reliable history to fall back on.

+

+
+
+

2. Going Backwards and Forwards

+

If every commit has a message describing what changed...

+

We need a LOG BUTTON to see the list of changes over time.

+

We need a CHECKOUT BUTTON to jump to any point in history.

+

+
+
+

The Bookshelf Analogy

+

Every commit is like a book on a shelf:

+
    +
  • Each book is a complete snapshot of your work at that moment
    • +
  • Want to see how things looked last month? Pick up that book
    • +
  • Checkout = checking out a book from the library
    • +
+

+
+
+

3. The Problem with Linear History

+

Real work isn't linear:

+
    +
  • Scientists test multiple hypotheses
    • +
  • Analysts try different formulas
    • +
  • Writers explore alternate endings
    • +
+

You need to experiment without breaking what works.

+
+
+

Real Example 1: The Dashboard Analyst

+

You're building a biomedical research dashboard:

+
    +
  • You have a better formula to try
    • +
  • Want to test it without switching everyone
    • +
  • Can't stop working while people test
    • +
  • Still need the current version running
    • +
+

We need a way to do work without affecting the main.

+

+
+
+

Real Example 2: The Emergency Bug Fix

+

Your live dashboard has a bug:

+
    +
  • Need to fix it now
    • +
  • But you have unfinished work in progress
    • +
  • Can't release half-done features
    • +
+

Solution: Branch from the released version, fix it there.

+

+
+
+

🌳 Introducing: BRANCHES

+

The BRANCH BUTTON lets you:

+
    +
  • Split off from main history
    • +
  • Work on experiments safely
    • +
  • Keep the main version stable
    • +
  • Track the "tip" (latest commit) of each branch
    • +
+
+
+

Branch Visualization

+

Each branch explores a different direction.
+Every commit still traces back to the beginning.

+

+
+
+

6. 🏷️ Tags: Milestones and Signposts

+

Sometimes you need to mark special versions:

+
    +
  • v1.0 - First release
    • +
  • publication-draft - Submitted to journal
    • +
  • final-report-2024 - Year-end version
    • +
+

TAG BUTTON: Label any commit for easy reference.

+
+
+

Quick Review: Your Personal Time Machine

+

So far, we've built a system for individual work:

+
    +
  • COMMIT - Save snapshots with messages
    • +
  • LOG - See the history of changes
    • +
  • CHECKOUT - Jump to any point in time
    • +
  • BRANCH - Experiment without breaking things
    • +
  • TAG - Mark important milestones
    • +
+

You can now work safely, experiment freely, and never lose your work.

+
+
+

7. Distributed Collaboration

+

Code (and analysis) is rarely done alone.

+

The problem:

+
    +
  • Can't have people overwriting each other
    • +
  • Need coordination without chaos
    • +
+
+
+

The Solution: Everyone Gets a Copy

+

The CLONE/FORK BUTTON gives someone:

+
    +
  • The entire history
    • +
  • All the branches
    • +
  • Full ability to work independently
    • +
  • No interference with your work
    • +
+

They have their own time machine!

+
+
+

8. 🔒 Hashes and Identity

+

New concern: What if someone edits the history?

+
    +
  • Sneaks in malicious changes
    • +
  • Accidentally breaks something
    • +
+

Solution: Digital signatures (hashes)

+
+
+

How Hashes Work

+

Every commit gets a unique fingerprint:

+
24b9da6552252987aa493b52f8696cd6d3b00393
+
+
    +
  • Changes even with tiny edits
    • +
  • Each commit includes the previous commit's hash
    • +
  • Any past change changes all future hashes
    • +
  • Makes tampering immediately obvious
    • +
+
+
+

9. Merges: Bringing Work Together

+

Now we have:

+
    +
  • ✓ Snapshots (commits)
    • +
  • ✓ Independent work (branches)
    • +
  • ✓ Complete history (log)
    • +
  • ✓ Easy comparison (hashes)
    • +
+

How do we combine our work?

+
+
+

The MERGE BUTTON

+

Merging combines branches:

+
    +
  1. Find the most recent common commit
    2. +
  2. Combine the differences from both branches
    3. +
  3. Create a new commit with combined work
    4. +
+
+
+

11. The Staging Area

+

Problem: Sometimes you make a bunch of unrelated edits.

+

Best practice: Package related changes together in one commit.

+

Challenge: What if you forgot to commit before making other changes?

+
+
+

The ADD BUTTON

+

The staging area is like a shopping cart:

+
    +
  • ADD changes you want in the next commit
    • +
  • Leave out changes that belong elsewhere
    • +
  • COMMIT when your cart is ready
    • +
+

Workflow: Edit → Add → Commit

+
+
+

The Three States Visualized

+
Working Directory  →  Staging Area  →  Repository
+   (modified)          (staged)        (committed)
+   
+      📝      →   ADD   →   🛒   →   COMMIT   →   📚
+
+
+
+

14. Wrap-Up: Git as a Cognitive Model

+

Git isn't just a tool—it's a way of thinking about work:

+
    +
  • Work as structured history
    • +
  • Changes as navigable snapshots
    • +
  • Experiments as parallel explorations
    • +
+
+
+

Three Key Metaphors

+
    +
  1. 📸 Snapshots – Freeze moments in time
    2. +
  2. 🌳 Branches – Explore ideas in parallel
    3. +
  3. 🤝 Merges – Bring ideas together coherently by comparing differences
    4. +
+
+
+

Review: The Story So Far

+

The Journey:

+
    +
  1. Started with messy file copies (report_final_v3.xlsx)
    2. +
  2. Built a system to take snapshots (commit)
    3. +
  3. Added ability to view history (log) and time travel (checkout)
    4. +
  4. Created parallel timelines for experiments (branch)
    5. +
  5. Marked important moments (tag)
    6. +
  6. Enabled collaboration by sharing complete copies (clone/fork)
    7. +
  7. Protected integrity with digital signatures (hashes)
    8. +
  8. Combined work from different branches (merge)
    9. +
  9. Organized changes before saving (staging/add)
    10. +
+
+
+

The Buttons We've Created

+
    +
  • COMMIT - Save a snapshot
    • +
  • LOG - View history
    • +
  • CHECKOUT - Jump in time
    • +
  • BRANCH - Split off to experiment
    • +
  • TAG - Mark milestones
    • +
  • CLONE/FORK - Share the entire history
    • +
  • MERGE - Combine work
    • +
  • ADD - Stage changes
    • +
+
+
+

You Now Understand Git

+

Everything else is just:

+
    +
  • Syntax and commands
    • +
  • Tools and interfaces
    • +
  • Best practices and workflows
    • +
+

The concepts? You've got them.

+
+
+

Questions?

+
$ git commit -m "Learning complete"
+
+
+
+

Thank You

+

Remember: Version control is about telling the story of your work.

+

Git just gives you the tools to tell it well.

+
+
\ No newline at end of file diff --git a/01_materials/slides/git_as_story.pdf b/01_materials/slides/git_as_story.pdf index cbf8375..d699269 100644 Binary files a/01_materials/slides/git_as_story.pdf and b/01_materials/slides/git_as_story.pdf differ diff --git a/02_activities/practice/git_advanced.md b/02_activities/practice/git_advanced.md index 3356a73..c908407 100644 --- a/02_activities/practice/git_advanced.md +++ b/02_activities/practice/git_advanced.md @@ -5,7 +5,7 @@ The `dtxe/DSI_git_assignment` repository contains a short Python script that loads the TTC Bus Delay dataset, computes the average delay by route, then plots the average delay as a histogram. s -1. Clone this repository: https://github.com/dtxe/DSI_git_assignment +1. Clone this repository: https://github.com/gvwilson/DSI_git_assignment * `git clone` ### Task 1 diff --git a/03_instructional_team/markdown_slides/git_as_story.md b/03_instructional_team/markdown_slides/git_as_story.md index a5cb4be..bf3009f 100644 --- a/03_instructional_team/markdown_slides/git_as_story.md +++ b/03_instructional_team/markdown_slides/git_as_story.md @@ -270,17 +270,6 @@ Merging combines branches: 2. Combine the **differences** from both branches 3. Create a new commit with combined work - ---- - -## 11. The Staging Area - -**Problem:** Sometimes you make a bunch of unrelated edits. - -**Best practice:** Package related changes together in one commit. - -**Challenge:** What if you forgot to commit before making other changes? - --- ## 11. The Staging Area diff --git a/README.md b/README.md index 48c3b41..9ced5f3 100644 --- a/README.md +++ b/README.md @@ -47,25 +47,21 @@ Participants should review the [Assignment Submission Guide](https://github.com/ **Questions can be submitted to the #cohort-8-help channel on Slack** * Technical Facilitator: - * **Simeon Wong** - me@simeon.dev + * **Greg Wilson** gvwilson@third-bit.com * Learning Support Staff: - * **Dmytro Bonislavskyi** - dmytro.bonislavskyi@gmail.com - * **Moniz Chan** - chanmoniz526@gmail.com - * **Xindi Zhang** - xindi.zhang@mail.utoronto.ca + * **Dmytro Bonislavskyi** dmytro.bonislavskyi@gmail.com + * **Sergii Khomych** svkhomich1@gmail.com / khsergvl + * **Anjali Shrivastava** anju_shrivastava@yahoo.com / anjali-deshpande-hub -  -## Delivery of the Learning Module + +## Delivery of the Learning Module This module will include live learning sessions and optional, asynchronous work periods. During live learning sessions, the Technical Facilitator will introduce and explain key concepts and demonstrate core skills. Learning is facilitated during this time. Before and after each live learning session, the instructional team will be available for questions related to the core concepts of the module. Optional work periods are to be used to seek help from peers, the Learning Support team, and to work through the practice problems and assignments in the learning module, with access to live help. Content is not facilitated, but rather this time should be driven by participants. We encourage participants to come to these work periods with questions and problems to work through. -  -Participants are encouraged to engage actively during the learning module. The key to developing the core skills in each learning module is through practice. The more participants engage in coding along with the instructional team, and applying the skills in each module, the more likely it is that these skills will solidify. -  +Participants are encouraged to engage actively during the learning module. They key to developing the core skills in each learning module is through practice. The more participants engage in coding along with the instructional team, and applying the skills in each module, the more likely it is that these skills will solidify. + + ## Requirements * Participants are not expected to have any coding experience; the learning content has been designed for beginners.