diff --git a/01_materials/01_git_intro.pdf b/01_materials/01_git_intro.pdf new file mode 100644 index 0000000..57f074b Binary files /dev/null and b/01_materials/01_git_intro.pdf differ diff --git a/01_materials/02_git_setup.md b/01_materials/02_git_setup.md new file mode 100644 index 0000000..e716741 --- /dev/null +++ b/01_materials/02_git_setup.md @@ -0,0 +1,68 @@ +## 1. Git Setup + +--- + +## Situate yourself in the terminal +```bash +pwd +ls +``` + +**Stop and consider:** Are we in the correct working directory to continue? + +--- + +### Check Git Version +First, check if Git is installed: +```bash +git --version +``` + +### Configure identity +Configure your identity (required for commits): +```bash +git config --global user.name "Your Name" +git config --global user.email "your.email@example.com" +``` + +### Configure text editor +Configure your text editor (VSCode is much easier to use than command-line editors): +```bash +git config --global core.editor "code --wait" +``` + +(🍎⚠️ For MacOS users) You may need to enable the VSCode command: [Install the 'code' command for MacOS](https://code.visualstudio.com/docs/setup/mac#_configure-the-path-with-vs-code) + +### Connect to GitHub.com +Login to GitHub.com in your command line +```bash +git credential-manager github login +``` + +Then test your login with +```bash +git credential-manager github list +``` + + +#### Troubleshooting GitHub connection +If the login browser window does not appear, or it doesn't work, try running: +```bash +git credential-manager github login --no-ui --device +``` + +(🍎⚠️ For MacOS users) If you get this error message: `'credential-manager' is not a git command` +* Make sure Git Credential Manager is installed +* Run `brew install --cask git-credential-manager` +* If this still doesn't work, please follow along using SSH authentication. Note that your Git commands will be different than the instructor's. + 1. https://docs.github.com/en/authentication/connecting-to-github-with-ssh/checking-for-existing-ssh-keys + 2. https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent + 3. https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account + 4. https://docs.github.com/en/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection + +### Verify configuration +Verify your configuration: +```bash +git config --list +``` + diff --git a/01_materials/03_git_log_checkout.md b/01_materials/03_git_log_checkout.md new file mode 100644 index 0000000..96ad6e0 --- /dev/null +++ b/01_materials/03_git_log_checkout.md @@ -0,0 +1,49 @@ +# Introduction to Git - Going backwards and forwards in time + +--- + +## Situate yourself in the terminal +```bash +pwd +ls +``` + +**Stop and consider:** Are we in the correct working directory to continue? + +--- + +## 2. Clone a Repository + +Clone an existing repository from GitHub: +```bash +git clone https://github.com/simeon-demo/recipe-book.git +``` + +Navigate into the cloned repository: +```bash +cd recipe-book +``` + +### 2.1 View History + +See the commit history: +```bash +git log +``` + +See a visual branch graph: +```bash +git log --oneline --graph --all +``` + +### 2.2 Go Backwards and Forwards in Time + +Check out a specific commit (use commit hash from `git log`): +```bash +git checkout +``` + +Return to the latest version: +```bash +git checkout main +``` diff --git a/01_materials/04_git_clone_add_push.md b/01_materials/04_git_clone_add_push.md new file mode 100644 index 0000000..ec5ac86 --- /dev/null +++ b/01_materials/04_git_clone_add_push.md @@ -0,0 +1,185 @@ +# Introduction to Git - Making changes + +## 3. Fork a Repository + +**Note:** Forking is done on GitHub through the web interface, not the terminal. + +1. Go to the repository on GitHub +2. Click the "Fork" button in the top-right corner +3. This creates a copy of the repository under your GitHub account + +Think of a fork as "a clone, but on GitHub" - it's your own copy of someone else's project. + +--- + +## Situate yourself in the terminal +```bash +pwd +ls +git status +``` + +**Stop and consider:** Are we in the correct working directory to continue? + +--- + +## 4. Making changes + +### 4.1 Update your remotes + +We only have permissions to make changes to our own fork. + +Let's rename the instructor repo to `upstream`, meaning where we get our changes from. +Then set our fork as the `origin`. + +```bash +git remote mv origin upstream +git remote -v +git remote add origin https://github.com/[your-username]/recipe-book.git +git remote -v +``` + +### 4.3 Create a New Branch + +Create a new branch and checkout +```bash +git branch [your-name]-recipe +git checkout [your-name]-recipe +``` + +Verify which branch you're on: +```bash +git status +``` + +### 4.4 Add Some Commits + +Create a folder with your name: +```bash +cd community-recipes +``` + +Situate yourself: +```bash +ls +pwd +``` + +**Stop and consider:** Are you in the right directory? + +Create your own recipe inside your folder: +```bash +code [your-name]-recipe.md +``` + +Check the status of your changes: +```bash +git status +``` + +Stage all your changes (add all changes to staging area): +```bash +git add -A +``` + +Commit your changes: +```bash +git commit -m "Add my recipe" +``` + +➑️ Add more changes and commit again. + +#### Multiverse Analogy 🌌 + +Think of branches as parallel universes: +- Your branch has the folders and files you created +- Other people's branches have *their* folders and files +- These exist in separate "multiverses" until merged +- Files in your branch don't exist in someone else's branch! + + +### 4.5 Push Your Branch + +Push your branch to GitHub (upload your snapshots): +```bash +git push origin [your-name]-recipe +``` + +Remember we set our own forks as the origin. + +If you get an error message here, check your remotes using: +```bash +git remote -v +``` + +### 4.6 View Commits on GitHub + +1. Go to your repository on GitHub +2. Click on the "Commits" link +3. Click on individual commits to see diffs (what changed) +4. Notice how GitHub highlights additions (green) and deletions (red) + +### 4.7 Create a Pull Request + +**On GitHub (web interface):** +1. Go to your repository +2. Click "Pull requests" tab +3. Click "New pull request" +4. Select your branch to merge into `main` +5. Click "Create pull request" +6. Add a title and description +7. Click "Create pull request" again + +This asks the project maintainers to review and merge your changes. + +--- + +## 5. Pull to See Everybody's Changes + +Switch back to the main branch: +```bash +git checkout main +``` + +Pull the latest changes from GitHub: +```bash +git pull origin main +``` + +This downloads everyone's merged changes to your local machine. + +View the updated history: +```bash +git log --oneline --graph --all +``` + +List all files to see everyone's contributions: +```bash +ls +``` + +--- + +## Quick Reference - Essential Commands + +| Command | Purpose | +|---------|---------| +| `git clone ` | Copy a repository from GitHub | +| `git status` | See what's changed | +| `git log --oneline` | View commit history | +| `git checkout -b ` | Create and switch to new branch | +| `git add .` | Stage all changes | +| `git commit -m "message"` | Save a snapshot | +| `git push origin ` | Upload to GitHub | +| `git pull origin main` | Download latest changes | +| `git branch` | See all branches | + +--- + +## Helpful Tips + +- Always check which branch you're on: `git branch` +- Always pull before starting new work: `git pull` +- Commit early and often with clear messages +- Use descriptive branch names: `jane-data-analysis` not just `feature` +- When in doubt, `pwd`, `ls`, and `git status` tells you what's happening diff --git a/01_materials/05_git_merge_conflicts.md b/01_materials/05_git_merge_conflicts.md new file mode 100644 index 0000000..ce338d6 --- /dev/null +++ b/01_materials/05_git_merge_conflicts.md @@ -0,0 +1,216 @@ +# Resolving Merge Conflicts + +## Setup: Clone the Team Playlist Repository + +```bash +git clone https://github.com/simeon-demo/team-playlist.git +cd team-playlist-demo +``` + +--- + +## Part 1: View the Branches + +### See all available branches +```bash +# List all branches (including remote branches) +git branch -a +``` + +You should see: +- `main` (your current branch) +- `remotes/origin/Max-song-change` +- `remotes/origin/Em-song-change` + +### View the current playlist +```bash +cat playlist.txt +``` + +This is the original playlist that both Max and Em will modify. + +--- + +## Part 2: Merge Max's Changes (No Conflict) + +### Merge Max's branch into main +```bash +# Merge Max's changes +git merge origin/Max-song-change +``` + +βœ… **Success!** This merge works smoothly. + +### View what changed +```bash +cat playlist.txt +``` + +Notice how the playlist has been updated with Max's song choice. + +--- + +## Part 3: Merge Em's Changes (Conflict!) + +### Try to merge Em's branch +```bash +# Try to merge Em's changes +git merge origin/Em-song-change +``` + +πŸ’₯ **CONFLICT!** Git displays an error message: +``` +Auto-merging playlist.txt +CONFLICT (content): Merge conflict in playlist.txt +Automatic merge failed; fix conflicts and then commit the result. +``` + +**What happened?** Both Max and Em edited the same line. Git doesn't know which version to keep! + +--- + +## Part 4: Understand the Conflict + +### Check the status +```bash +git status +``` + +Shows: `both modified: playlist.txt` - This file needs your help! + +### View the conflicted file +```bash +cat playlist.txt +``` + +**What you'll see:** +``` +<<<<<<< HEAD +Song 5: Blinding Lights - The Weeknd +Last updated: Tuesday by Max +======= +Song 5: Levitating - Dua Lipa +Last updated: Tuesday by Em +>>>>>>> origin/Em-song-change +``` + +**Understanding conflict markers:** +- `<<<<<<< HEAD` - Current version (Max's change, already in main) +- `=======` - Separator between the two versions +- `>>>>>>> origin/Em-song-change` - Incoming version (Em's change) + +--- + +## Part 5: Resolve the Conflict + +### Edit the file to resolve +Open `playlist.txt` in your text editor and choose ONE of these options: + +**Option 1: Keep Max's version** +``` +Song 5: Blinding Lights - The Weeknd +Last updated: Tuesday by Max +``` + +**Option 2: Keep Em's version** +``` +Song 5: Levitating - Dua Lipa +Last updated: Tuesday by Em +``` + +**Option 3: Keep both songs!** +``` +Song 5: Blinding Lights - The Weeknd +Song 6: Levitating - Dua Lipa + +Total songs: 6 +Last updated: Tuesday by Team +``` + +**Important:** Delete ALL conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) + +--- + +## Part 6: Complete the Merge + +### Mark the conflict as resolved +```bash +# Stage the resolved file +git add playlist.txt + +# Check status - should say "all conflicts fixed" +git status +``` + +### Commit the merge +```bash +# Complete the merge with a commit +git commit -m "Merge Em-song-change: resolved playlist conflict" +``` + +### View the merge in history +```bash +# See the merge commit in the history graph +git log --oneline --graph --all +``` + +You should see both branches merge together into main! + +--- + +## Quick Reference + +| Command | What It Does | +|---------|-------------| +| `git branch -a` | List all branches (local and remote) | +| `git merge origin/branch-name` | Merge a remote branch into current branch | +| `git status` | Check which files have conflicts | +| `cat filename` | View the conflicted file | +| `git add filename` | Mark conflict as resolved | +| `git commit` | Complete the merge | +| `git merge --abort` | Cancel the merge and start over | +| `git log --oneline --graph --all` | View branch history | + +--- + +## Key Takeaways + +βœ“ **Conflicts are normal** - They happen when two people edit the same lines + +βœ“ **Git asks for help** - It can't (and shouldn't!) decide which version to keep + +βœ“ **You make the choice** - Keep one, keep both, or write something new + +βœ“ **The process:** +1. Git stops with a conflict message +2. You view the conflict with `cat` or open the file +3. You edit the file manually +4. You remove conflict markers +5. You `git add` the file +6. You `git commit` to finish + +βœ“ **Don't panic!** - Your work is safe. Both versions are shown in the file. + +--- + +## Common Mistakes to Avoid + +❌ **Forgetting to remove conflict markers** - Make sure you delete `<<<<<<<`, `=======`, and `>>>>>>>` + +❌ **Not staging the file** - You must `git add` before you can commit + +❌ **Committing without resolving** - Make sure all conflicts are fixed first (check `git status`) + +--- + +## What Just Happened? + +**The Story:** +1. Max made changes to the playlist and pushed them +2. Em made different changes to the same song and pushed them +3. You merged Max's changes first - no problem! βœ“ +4. When you tried to merge Em's changes, Git found a conflict +5. You decided how to resolve it (that's teamwork!) +6. Now both Max and Em's work is in the main branch + +**Real-world parallel:** This is exactly what happens in data science projects when two team members edit the same script, notebook, or configuration file! diff --git a/01_materials/slides/01_git_installation.pdf b/01_materials/slides/01_git_installation.pdf deleted file mode 100644 index c510d81..0000000 Binary files a/01_materials/slides/01_git_installation.pdf and /dev/null differ diff --git a/01_materials/slides/02_git_version_control.pdf b/01_materials/slides/02_git_version_control.pdf deleted file mode 100644 index da03e53..0000000 Binary files a/01_materials/slides/02_git_version_control.pdf and /dev/null differ diff --git a/01_materials/slides/03_git_basics.pdf b/01_materials/slides/03_git_basics.pdf deleted file mode 100644 index c7e586c..0000000 Binary files a/01_materials/slides/03_git_basics.pdf and /dev/null differ diff --git a/01_materials/slides/04_optional_git_slide.pdf b/01_materials/slides/04_optional_git_slide.pdf deleted file mode 100644 index 02ec5e3..0000000 Binary files a/01_materials/slides/04_optional_git_slide.pdf and /dev/null differ diff --git a/01_materials/slides/README.md b/01_materials/slides/README.md deleted file mode 100644 index 1083b13..0000000 --- a/01_materials/slides/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# To Read - -When you have the time, please read this [article](https://www.freecodecamp.org/news/git-the-laymans-guide-to-understanding-the-core-concepts/) about `git`, which includes an analogy as well. diff --git a/03_instructional_team/git_03_repo_setup_script.sh b/03_instructional_team/git_03_repo_setup_script.sh new file mode 100644 index 0000000..eae7686 --- /dev/null +++ b/03_instructional_team/git_03_repo_setup_script.sh @@ -0,0 +1,113 @@ +#!/bin/bash + +# Create repository +mkdir recipe-book +cd recipe-book +git init -b main + +# Commit 1 +cat > cookies.txt << 'EOF' +CHOCOLATE CHIP COOKIES + +Ingredients: +- 2 cups flour +- 1 cup butter +- 1 cup sugar +- 2 eggs +- 1 tsp vanilla + +Instructions: +1. Mix butter and sugar +2. Add eggs and vanilla +3. Mix in flour +4. Bake at 350Β°F for 12 minutes +EOF +git add cookies.txt +git commit -m "Add chocolate chip cookie recipe" + +# Commit 2 +cat > pancakes.txt << 'EOF' +PANCAKES + +Ingredients: +- 2 cups flour +- 2 eggs +- 1.5 cups milk +- 2 tbsp sugar +- 2 tsp baking powder + +Instructions: +1. Mix dry ingredients +2. Whisk in eggs and milk +3. Cook on griddle until bubbles form +4. Flip and cook 2 more minutes +EOF +git add pancakes.txt +git commit -m "Add pancake recipe" + +# Commit 3 +cat > cookies.txt << 'EOF' +CHOCOLATE CHIP COOKIES + +Ingredients: +- 2 cups flour +- 1 cup butter +- 1 cup sugar +- 2 eggs +- 1 tsp vanilla +- 2 cups chocolate chips + +Instructions: +1. Mix butter and sugar +2. Add eggs and vanilla +3. Mix in flour +4. Fold in chocolate chips +5. Bake at 350Β°F for 12 minutes +EOF +git add cookies.txt +git commit -m "Add chocolate chips to cookie recipe" + +# Commit 4 +cat > smoothie.txt << 'EOF' +BERRY SMOOTHIE + +Ingredients: +- 1 cup strawberries +- 1 banana +- 1 cup yogurt +- 0.5 cup orange juice +- 1 tbsp honey + +Instructions: +1. Add all ingredients to blender +2. Blend until smooth +3. Pour and enjoy immediately +EOF +git add smoothie.txt +git commit -m "Add smoothie recipe" + +# Commit 5 +cat > README.md << 'EOF' +# Recipe Book + +Welcome to our recipe collection! + +## Available Recipes: +- Chocolate Chip Cookies (cookies.txt) +- Pancakes (pancakes.txt) +- Berry Smoothie (smoothie.txt) + +## How to use: +1. Choose a recipe file +2. Read the ingredients +3. Follow the instructions +4. Enjoy your food! +EOF +git add README.md +git commit -m "Add README with recipe index" + +# Show git status and log +git status +git log --oneline + +echo "Repository setup complete. Add remote and push as needed." diff --git a/03_instructional_team/git_04_repo_setup_script.sh b/03_instructional_team/git_04_repo_setup_script.sh new file mode 100644 index 0000000..7d7162c --- /dev/null +++ b/03_instructional_team/git_04_repo_setup_script.sh @@ -0,0 +1,175 @@ +#!/bin/bash + +# This script extends the recipe-book repository from git_03_repo_setup_script.sh +# It adds a community-recipes directory and a GitHub Actions workflow to +# automatically approve and merge pull requests that add recipes to the +# community-recipes directory, provided they are text files without executable +# permissions or shebangs. + + +# Create community-recipes directory +mkdir -p community-recipes + +# Create a placeholder file to ensure the directory is tracked by git +cat > community-recipes/.gitkeep << 'EOF' +# This directory is for community-contributed recipes +# Submit your recipes as .txt files via pull request +EOF + +# Create .github/workflows directory +mkdir -p .github/workflows + +# Create the GitHub Actions workflow file +cat > .github/workflows/auto-merge-community-recipes.yml << 'EOF' +# .github/workflows/auto-merge-community-recipes.yml +# +# This workflow validates pull requests for community recipes and, +# if all checks pass, approves and auto-merges them. +# +# Prerequisites: +# 1. Enable "Allow auto-merge" in repository settings (under "Pull Requests") +# 2. For protected branches, this workflow provides the required approval +# +name: Auto-Approve and Merge Community Recipes + +on: + pull_request: + types: [opened, synchronize] # Runs on PR creation and updates + +# Grant the workflow token permissions +permissions: + pull-requests: write # To approve and merge PRs + contents: write # To merge PRs + +jobs: + validate-approve-merge: + runs-on: ubuntu-latest + + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + # Fetch full history to diff between base and head + fetch-depth: 0 + + - name: Validate changed files + id: validate + run: | + #!/bin/bash + set -e # Exit immediately if a command fails + + # --- CONFIGURATION --- + ALLOWED_SUBDIRECTORY="community-recipes" + # --- END CONFIGURATION --- + + echo "Validating files for auto-approval and merge..." + echo "Allowed Subdirectory: $ALLOWED_SUBDIRECTORY" + + # Ensure path has a trailing slash for correct prefix matching + if [[ "$ALLOWED_SUBDIRECTORY" != */ ]]; then + ALLOWED_SUBDIRECTORY="$ALLOWED_SUBDIRECTORY/" + fi + + # Get the base and head commit SHAs from the pull request event + BASE_SHA=${{ github.event.pull_request.base.sha }} + HEAD_SHA=${{ github.event.pull_request.head.sha }} + + echo "Base SHA: $BASE_SHA" + echo "Head SHA: $HEAD_SHA" + + # Get the list of all files that differ between the two commits + CHANGED_FILES=$(git diff-tree --no-commit-id --name-only -r "$BASE_SHA" "$HEAD_SHA") + + if [ -z "$CHANGED_FILES" ]; then + echo "No file changes detected. Skipping." + exit 0 + fi + + echo "---" + echo "Changed files:" + echo "$CHANGED_FILES" + echo "---" + + # Loop through each changed file and check it + while IFS= read -r file; do + echo "Checking file: $file" + + # 1. Path Check: Is the file within the allowed subdirectory? + if [[ ! "$file" == "$ALLOWED_SUBDIRECTORY"* ]]; then + echo "::error file=$file::File is outside the allowed subdirectory '$ALLOWED_SUBDIRECTORY'." + exit 1 + fi + echo " βœ… Path check passed." + + # If the file was deleted, it passed the path check, and we don't + # need to check its contents (it doesn't exist at HEAD). + if [ ! -f "$file" ]; then + echo " File was deleted. Path check is sufficient." + continue + fi + + # 2. Extension Check: Is it '.txt' or has no extension? + filename=$(basename -- "$file") + if [[ "$filename" == *.* ]]; then + # File has an extension + extension="${filename##*.}" + if [[ "$extension" != "txt" ]]; then + echo "::error file=$file::Invalid file extension '.$extension'. Only '.txt' or no extension allowed." + exit 1 + fi + echo " βœ… Extension check passed (.txt)." + else + # File has no extension + echo " βœ… Extension check passed (no extension)." + fi + + # 3. Executable Check: Is the file non-executable? + if [ -x "$file" ]; then + echo "::error file=$file::File is executable." + exit 1 + fi + echo " βœ… Executable check passed." + + # 4. Shebang Check: Does the file NOT start with '#!'? + # Read the first 2 bytes. Add '|| true' to prevent failure on empty files. + first_two_bytes=$(head -c 2 "$file" || true) + if [[ "$first_two_bytes" == "#!" ]]; then + echo "::error file=$file::File contains a shebang." + exit 1 + fi + echo " βœ… Shebang check passed." + + done <<< "$CHANGED_FILES" + + echo "---" + echo "All checks passed. Proceeding to approve and merge." + + - name: Approve Pull Request + if: success() + run: gh pr review --approve "$PR_URL" + env: + PR_URL: ${{ github.event.pull_request.html_url }} + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + + - name: Enable Auto-Merge + if: success() + run: gh pr merge --auto --squash "$PR_URL" + env: + PR_URL: ${{ github.event.pull_request.html_url }} + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} +EOF + +# Stage and commit everything +git add community-recipes/ .github/ +git commit -m "Add community-recipes directory and auto-merge workflow" + +echo "βœ… Setup complete!" +echo "" +echo "Created:" +echo " - community-recipes/ directory" +echo " - .github/workflows/auto-merge-community-recipes.yml" +echo "" +echo "Next steps:" +echo "1. Push changes to remote: git push" +echo "2. Enable 'Allow auto-merge' in repository settings:" +echo " Settings β†’ General β†’ Pull Requests β†’ Allow auto-merge" diff --git a/03_instructional_team/git_05_repo_setup_script.sh b/03_instructional_team/git_05_repo_setup_script.sh new file mode 100644 index 0000000..3b28edf --- /dev/null +++ b/03_instructional_team/git_05_repo_setup_script.sh @@ -0,0 +1,125 @@ +#!/bin/bash + +# Setup script for team-playlist-demo repository +# This creates a repository ready for merge conflict demonstrations + +set -e # Exit on any error + +echo "==========================================" +echo "Setting up team-playlist-demo repository" +echo "==========================================" +echo "" + +# Create and initialize repository +echo "1. Creating repository..." +mkdir -p team-playlist-demo +cd team-playlist-demo +git init +echo "βœ“ Repository initialized" +echo "" + +# Create initial playlist file +echo "2. Creating initial playlist..." +cat > playlist.txt << 'EOF' +TEAM PLAYLIST +============= + +Song 1: Bohemian Rhapsody - Queen +Song 2: Hotel California - Eagles +Song 3: Sweet Child O' Mine - Guns N' Roses +Song 4: Imagine - John Lennon +Song 5: Billie Jean - Michael Jackson + +Total songs: 5 +Last updated: Monday +EOF + +git add playlist.txt +git commit -m "Create initial team playlist" +echo "βœ“ Initial playlist committed" +echo "" + +# Create Max's branch with changes +echo "3. Creating Max's branch (Max-song-change)..." +git checkout -b Max-song-change + +cat > playlist.txt << 'EOF' +TEAM PLAYLIST +============= + +Song 1: Bohemian Rhapsody - Queen +Song 2: Hotel California - Eagles +Song 3: Sweet Child O' Mine - Guns N' Roses +Song 4: Imagine - John Lennon +Song 5: Blinding Lights - The Weeknd + +Total songs: 5 +Last updated: Tuesday by Max +EOF + +git add playlist.txt +git commit -m "Max: Replace Billie Jean with Blinding Lights" +echo "βœ“ Max's changes committed" +echo "" + +# Return to main and create Em's branch with conflicting changes +echo "4. Creating Em's branch (Em-song-change)..." +git checkout main +git checkout -b Em-song-change + +cat > playlist.txt << 'EOF' +TEAM PLAYLIST +============= + +Song 1: Bohemian Rhapsody - Queen +Song 2: Hotel California - Eagles +Song 3: Sweet Child O' Mine - Guns N' Roses +Song 4: Imagine - John Lennon +Song 5: Levitating - Dua Lipa + +Total songs: 5 +Last updated: Tuesday by Em +EOF + +git add playlist.txt +git commit -m "Em: Replace Billie Jean with Levitating" +echo "βœ“ Em's changes committed" +echo "" + +# Return to main branch +echo "5. Returning to main branch..." +git checkout main +echo "βœ“ Back on main branch" +echo "" + +# Display summary +echo "==========================================" +echo "Setup complete!" +echo "==========================================" +echo "" +echo "Repository structure:" +git log --oneline --graph --all +echo "" +echo "Branches created:" +git branch -a +echo "" +echo "==========================================" +echo "Next steps:" +echo "==========================================" +echo "" +echo "To push to GitHub:" +echo " 1. Create a new repository on GitHub named 'team-playlist-demo'" +echo " 2. Run these commands:" +echo "" +echo " git remote add origin https://github.com/YOUR-USERNAME/team-playlist-demo.git" +echo " git branch -M main" +echo " git push -u origin main" +echo " git push origin Max-song-change" +echo " git push origin Em-song-change" +echo "" +echo "To test the merge conflict locally:" +echo " 1. git merge Max-song-change (should succeed)" +echo " 2. git merge Em-song-change (will conflict!)" +echo "" +echo "Repository ready for demonstration!" +echo "==========================================" \ No newline at end of file diff --git a/03_instructional_team/markdown_slides/01_git_installation.md b/03_instructional_team/markdown_slides/01_git_installation.md deleted file mode 100644 index 3135356..0000000 --- a/03_instructional_team/markdown_slides/01_git_installation.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -marp: true -theme: dsi_certificates_theme -style: | - section { - font-family: Inter, -apple-system, BlinkMacSystemFont, 'Helvetica Neue', sans-serif; - } -_class: invert -paginate: true ---- - -# Installing Git - -``` -$ echo "Data Sciences Institute" -``` - ---- - -## `Installing Git` - ---- -Typically, Git is already installed on our system but we can check for that using the `git` command: -```console -$ git --version -``` -Does anyone not see a version? - ---- -##### Installing on Linux -If you're on Ubantu: -```console -$ sudo apt install git -``` -
- -If you're on Fedora, RHEL or CentOS: -```console -$ sudo dnf install git -``` -```console -$ sudo yum install git -``` - ---- -##### Installing on Mac - -You can install Git via Homebrew, if you have Homebrew installed (https://brew.sh/). -```console -$ brew install git -``` - -Finally, you can install Git from source at this link: https://sourceforge.net/projects/git-osx-installer/ - ---- -##### Installing on Windows -The download will start automatically through this link: https://git-scm.com/download/win - ---- - - -Questions? - ---- - - -## `Git Setup` - ---- -The first thing to do now that we have Git installed on our system is to customize it. These changes will remain despite any upgrades to Git that we install. - -Using the command `git config`, we can set configuration variables that control all aspects of how Git looks and operates. - ---- -##### Checking Configurations -Before we change any of our global configurations, we can check what they are: -```console -$ git config --list -``` -If we haven't configured Git, we can do that now! - ---- -##### Identity -First, we'll set our username and email address. Git uses this information every time we commit. -```console -$ git config --global user.name "Jane Doe" -$ git config --global user.email "jane.doe@gmail.com" -``` -The option `--global` means that we only have to pass this through once. - ---- -##### Editor -Next, we'll configure our the default text editor for when Git needs to type in a message. Git uses our system's default editor (usually Vi or Vim) but we can change it if we prefer. If we want to change the editor to emacs, we would do so below: -```console -$ git config --global core.editor emacs -``` - ---- -##### Diff Tool -We can also set the default diff tool which is used to resolve merge conflicts: -```console -$ git config --global merge.tool vimdiff -``` - ---- -##### Checking the Setting -We can use the `git config --list` command to see all Git settings. See the values of a specific specific setting: -```console -$ git config user.name -``` - ---- -##### Help -If we ever need help, even offline, we can access the manual page three ways: -1. `$ git help ` -2. `$ git --help` -3. `$ man git-` - -For example, we can get help for the `config` command: -```console -$ git help config -``` - ---- - - -Questions? diff --git a/03_instructional_team/markdown_slides/02_git_version_control.md b/03_instructional_team/markdown_slides/02_git_version_control.md deleted file mode 100644 index 098f57a..0000000 --- a/03_instructional_team/markdown_slides/02_git_version_control.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -marp: true -theme: dsi_certificates_theme -style: | - section { - font-family: Inter, -apple-system, BlinkMacSystemFont, 'Helvetica Neue', sans-serif; - } -_class: invert -paginate: true ---- - -# Version Control and GitHub - -``` -$ echo "Data Sciences Institute" -``` - ---- -Prerequisites: -- Git version β‰₯2.39 -- Git Credential Manager -- GitHub account - ---- -Key Texts: -- Chacon and Straub, 2014, Pro Git, 2nd Edition. -- Timbers, Campbell, Lee, 2021, Data Science: A First Introduction, https://ubc-dsci.github.io/introduction-to-datascience/ - ---- -References -- Chacon and Straub: Chapter 1 -- Timbers: Chapter 12.3 - 12.4, 13.3.1 - ---- - - -## `Version Control` - ---- -#### What is Version Control? -Version control is a system: -* that records changes to a file or a set of files over time -* that enables recall a specific version - -We may already do this by copying files to another directory to save past versions. While it is simple, it lacks flexibility and complexity. - ---- -#### Why version control? -Version Control Systems (VCS) can do a number of things and can be applied on nearly any type of file on our computers: -* revert files to a previous state -* revert entire project to a previous state -* compare changes over time -* see who modified something last -* who introduced an issue and when -* recover lost files - ---- -#### Why specialized version control for software teams? -* Robust software is documented as it is written - * Log changes and reasoning for why changes are made -* Working in teams requires code-specific version control - * Changing one part of a code project can affect behaviour in seemingly unrelated features - * In-progress state of one component can render the entire program temporarily unusable (e.g. syntax error) - - ---- - - -Questions? - ---- - - -## `Git` - ---- -### Git Basics -Git is the most common VCS in modern coding teams. - -##### Git is efficient with storage -* Git stores snapshots of files in your project directory -* If files have not changed, Git does not store the file again, it links to the previous identical file already stored. - ---- - -![auto center](./pics/02_git_data.png) - ---- -##### Git can operate locally -Most operations on Git only need local files and resources to operate. Git also keeps the entire history of our projects on our local disks meaning we can see changes made months ago without a remote server. - -We also don't need to be connected to the server to get work done, rather we only need to be connected when we want to upload our work. - ---- -##### Git assures integrity -Git uses a check-summing mechanism called *SHA-1 hash* which is calculated based on the contents of a file or directory structure in Git. It looks somehting like this: -``` -24b9da6552252987aa493b52f8696cd6d3b00393 -``` -This checksum means it's impossible to change the contents of any file or directory without Git knowing about it. - -Git generally only adds data, making it fairly difficult to lose data once we've committed, which we'll learn about later. - ---- -##### The Three States -There are three main states that our files can reside in: -- Committed: - - data is safely stored on local database -- Modified: - - file has been changed but not yet committed -- Staged: - - modified file has been marked to go into the next commit - ---- -##### The Three Main Sections -There are three main sections to a Git project: -- The Git directory -- The working directory -- The staging area - ---- -##### The Git Directory -The Git directory is where Git stores the metadata and object database for our projects. It is what is copied when we clone a repository from another computer. - ---- -##### The Working Directory -The working directory is a single checkout of one version of our projects. These files are pulled out of the compressed database in the Git directory and placed on the disk for us to modify. - ---- -##### The Staging Area -The staging area is a simple file that stores information about what will go into our next commit. - ---- -##### Workflow -A basic workflow will look something like this: -1. Modify files in our working directory -2. Stage the files in the staging area -3. Commit the changes which takes the files from the staging area and stores them on the Git directory. - ---- - - -Questions? diff --git a/03_instructional_team/markdown_slides/03_git_basics.md b/03_instructional_team/markdown_slides/03_git_basics.md deleted file mode 100644 index 7708846..0000000 --- a/03_instructional_team/markdown_slides/03_git_basics.md +++ /dev/null @@ -1,542 +0,0 @@ ---- -marp: true -theme: dsi_certificates_theme -style: | - section { - font-family: Inter, -apple-system, BlinkMacSystemFont, 'Helvetica Neue', sans-serif; - } -_class: invert -paginate: true ---- - -# Git Basics -``` -$ echo "Data Sciences Institute" -``` - ---- - -References -- Chacon and Straub: Chapter 2 - ---- - - -## `$ git init` / `$git clone` - ---- -##### Respositories in an Existing Directory -We're quickly getting into how to start our first Git repository, or commonly known as repo. First we'll learn how to import an existing repo into Git: -```console -$ git init -``` -```console -$ git init -b main -``` -Here we're creating a new subdirectory named `.git` that will contain all our necessary repo files. The option `-b` will create a new branch called main. - ---- -##### Cloning an Existing Respository -If we want to collaborate on an existing repo, we need to clone the repo from GitHub. If we don't have a project set up yet, we'll need to do that first. - ---- -1. Create a new project -
- -![w:1100 center](./pics/03_creating_repo_1.png) - ---- -2. Add name and optional description -
- -![w:1100 center](./pics/03_creating_repo_2.png) - ---- -3. Choose public or private and add initialize -
- -![w:1000 center](./pics/03_creating_repo_3.png) - ---- -There are a number of automatically generated files such as log files that we might not want Git to add or show as untracked. We can create a file called `.gitignore` to ignore the automatically generated files. - -The `.gitignore` is dependent on the type of coding language you are using but can also be modified to fit specific purposes. - ---- -If we created a repo on GitHub, we can choose a `.gitignore` template. We can select a template specific to the coding language we are using. - -![w:900 center](./pics/03_git_ignore_small.png) - ---- -Once we have our repo, we can clone it: -```console -$ git clone https://github.com/rachaellam/git-module.git -``` -Using this code, we've created a repo called `git-module` (by taking the last part of the link) and initialized a `.git` directory and pulled all data for that repository while checking for the latest copy. - ---- -The url used in the previous code block is copied directly from GitHub by clicking code and copying the HTTPS: - -![w:1150 center](./pics/03_github.png) - ---- -If we want to change the name of the repo, we can specify that as the next command line option: -```console -$ git clone https://github.com/rachaellam/git-module.git mymodule -``` - ---- - - -Questions? - ---- - -# Git Commands - ---- -References -- Chacon and Straub: Chapter 2 -- Timbers: Chapter 12.5 - ---- - - -## `$ git status` - ---- -##### Tracked and Untracked Files -Files in our working directory can either be tracked or untracked. Tracked files are files that that were in the last snapshot and can be unmodified, modified or staged. Untracked files are files that aren't in our last snapshot or staging area. - -When we modify a file, Git keeps track of the modifications even before we've decided to commit. We can then stage the modifications and then commit. - ---- -![w:1000 center](./pics/03_workflow.png) - ---- -##### File Status -To better understand what state our files are in, we can check the status: -```console -$ git status -``` -If we've just created our repo, we should see (or something similar): -```console -# On branch main -# Your branch is up to date with 'origin/main'. - -# nothing to commit, working tree clean -``` - ---- -Let's now add a README.md file, because every good repo has a good README. - -```console -$ touch README.md -``` - -And see the status: - -```console -$ git status -``` - ---- -```console -On branch main - -No commits yet - -Untracked files: - (use "git add ..." to include in what will be committed) - README.md -``` -Here we can see that we still haven't committed anything and that we have an untracked README.md file. Git also gives us a bit of information including how to add a file to track. - ---- - - -## `$ git add` - ---- -##### Tracking New Files -To track new files, or stage new files, we can use `git add` along with the file that we want to track: -```console -$ git add README.md -``` -We can run `git status` again to see the results of `git add`. - ---- -```console -On branch main - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: README.md -``` -Now we can see that our README.md file is staged to be committed. - ---- -Let's say we add some more info to our README.md file, which has now been tracked. If we run `git status`, we can know: -```console -On branch main - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: README.md - -Changes not staged for commit: - (use "git add ..." to update what will be committed) - (use "git restore ..." to discard changes in working directory) - modified: README.md - -``` - ---- -We can stage our additional changes and check the status: -```console -$ git add README.md -$ git status -``` -```console -On branch main - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: README.md - -``` - ---- -Let's try adding another file into our directory. It can be something that you've been working on independently, or we can add our project from the previous Unix module. - ---- -If we modify many things at once, we can add the option `-A` to add all files, rather than adding one by one -```console -$ git add -A -``` -A little note about this: it's best to upload your work in small chunks for readability and for collaboration. So if you have a bunch of files, it's recommended to split them into smaller chunks. - ---- - - -Questions? - ---- - - -## `$ git commit` - ---- -Once we've staged your selected files, it's time to commit the changes. Anything that wasn't staged (any modifications since `git add`) will not be included in the commit. - -`git commit` is most easily run with the option `-m`. This adds a message to your commit - -```console -$ git commit -m "adding a message here" -``` - ---- -##### -m -Messages should be clear. They can also be extremely detailed if needed. By not including the option `-m`, Git will provide the latest output of `git status`. If you want even more information, you can use the option `-v`. - ---- -Messages are extremely important for our own records and also when collaborating with others. They can act as a reminder for what our commit includes, and also tell our collaborators what we did last. - -It's important to commit often as well so that merges are easier to locate and fix. - -It's also helpful if you want to go back to an earlier version. You have more options to choose from. - ---- -Practices around messages can vary but if we want to add a longer message we can remove the `-m` option. -```console -$ git commit -``` -Then hit `i` to add a message. You'll see `-- INSERT --` at the bottom and you can begin typing your message. - -When finished, press `esc` then `:wq` or `:x`. - -`w` means write and `q` means quit. `x` is shorthand for `wq` - ---- -``` -Short (50 chars or less) summary of changes - -More detailed explanatory text, if necessary. Wrap it to about -72 characters or so. In some contexts, the first line is treated -as the subject of an email and the rest of the text as the body, -the blank line separating thesummary from the body is critical -(unless you omit the body entirely). - -Further paragraphs come after blank lines. - -- Bullet points are okay, too - -- Typically a hyphen or asterisk is used for the bullet, preceded - by a single space with blank lines in between, but conventions - vary here -``` - ---- - - -## `$ git remote` - ---- -Remote repos are versions of our projects that are hosted on the internet or some network. This allows us to collaborate with others outside of our local repo. - -We can see the remote servers we've configured using `git remote`. If we add the option `-v`, we can see the URL: -```console -$ git remote -v -``` -Cloned repos will be displayed as origin by default. - ---- -##### Remote Setup -Before we connect our local repo to a remote repo, we need to setup our permissions. This is so we can send and retrieve work to and from our remote repositories. There are two ways to do this: - -1. Access Tokens - ---- -##### Access Tokens - -               ![w:350 left](./pics/03_settings.png)           ![w:340 right](./pics/03_developer.png) - ---- -![w:1150 center](./pics/03_personal_auth.png) - ---- -##### remote add -To add a remote repo, we can use `git remote add` followed by the name and URL. Now we can connect our local repo to a remote repo: -```console -$ git remote add origin https://github.com/rachaellam/git-r.git -$ git remote -v -``` -After checking we'll see: -```console -origin https://github.com/rachaellam/git-r.git (fetch) -origin https://github.com/rachaellam/git-r.git (push) -``` - ---- -If we want to see more information about a remote repo, we can use the command: -```console -$ git remote show origin -``` -Here we can see the URL that we're fetching and pulling from, our remote branches, and configurations for git push (to the main branch or another). - ---- -To send and retrieve work between our local and remote repositories, we use Git Credential Manager. - -```console -$ git credential-manager github login -``` - -To check our login status - -```console -$ git credential-manager github list -``` - ---- - - -Questions? - ---- - - -## `$ git fetch` / `$ git push` - ---- -When collaborating with others, changes might be made that are important to copy to your local directory. `git fetch` will get any new changes but it won't merge it to our work or modify our work. -```console -$ git fetch origin -``` - ---- -`git pull` will automatically fetch and merge a remote branch to our current branch (more on branching later). It's a good practice to pull before every work session, especially when working with others. Otherwise, a collaborator might have made changes, and you won't be able to push your changes to GitHub. -```console -$ git pull -``` - ---- -If we've create our remote repository using `init` and `remote add`, we need to specify the remote that we want to pull to and the branch we want to pull from. -```console -$ git pull origin main -``` -`origin` being the name of the remote repo we created earlier and `main` being the main branch on our GitHub repo. - ---- - - -Questions? - ---- - - -## `$ git push` - ---- -When we're ready to share our modifications, we have to push our project and files upstream using `git push` -```console -$ git push origin main -``` -Here we're pushing to our origin server on your main branch. The main branch is sometimes called the master branch. - -This command only works if we have write access and if no collaborator is pushing upstream at the same time as we are. We'd have to instead pull and merge their work before pushing our own. - ---- - - -Questions? - ---- - -# Git Branching - ---- -References -- Chacon and Straub: Chapter 3 -- Timbers: Chapter 12.8 - ---- -Branching allows us to diverge from the main line to do work without accidentally messing with the main line. This helps with testing without making any accidental changes to the working branch. - -To understand how branching works, let's go back and understand how Git saves files. -- blob -- tree -- pointer - ---- -![w:1000 center](./pics/03_blobs.png) - ---- -A branch is a way to move different pointers to a specific commit. In Git, the default branch is named *master* or *main*. When we first start making commits, we start at the master branch that automatically points to the last commit made. - -![w:700 center](./pics/03_master.png) - ---- - - -## `$ git branch` - ---- -We can make a new branch which creates a new pointer for us to move around. We can do this by using the command `git branch`: -```console -$ git branch testing -``` - ---- -Here, we've created a branch called testing, which means we've created a new pointer that could point to our current commit. - -![w:800 center](./pics/03_testing.png) - ---- - - -## `$ git checkout` - ---- -Git tracks what branch we're on using a pointer called `HEAD`. If we move the `HEAD` to the branch *main*, we'll see: -```console -Already on 'main' -``` -To move `HEAD` to point to the testing branch that we just created, we use `git checkout`: -```console -$ git checkout testing -``` -and we should see.. -```console -Switched to branch 'testing' -``` - ---- -![w:800 center](./pics/03_testing_head.png) - ---- -If we make some changes to our testing branch and commit, our head will move with the new commit. - -![w:800 center](./pics/03_testing_commit.png) - ---- -If we want to go back to an older version of our project and make changes, we can use `git checkout` again to redirect the head back to our master branch: -```console -$ git checkout main -``` -Using this command will move the `HEAD` pointer back to our master branch and revert our files in our working directory back to the snapshot that the master branch points to. - ---- - - -Questions? - ---- - - -## `Branching` - ---- -Let's take a look at a workflow that you might encounter: -```console -$ git commit -m "commits to master branch" -``` -![w:800 center](./pics/03_workflow_1.png) - ---- -```console -$ git checkout -b iss53 -``` -![w:600 center](./pics/03_workflow_2.png) - ---- -```console -$ git commit -a -m "commits to iss53" -``` -![w:700 center](./pics/03_workflow_3.png) - ---- -```console -$ git checkout master -$ git checkout -b 'hotfix' -$ git commit -m "commits to hotfix" -``` -![w:600 center](./pics/03_workflow_4.png) - ---- -```console -$ git checkout master -$ git merge hotfix -``` -![w:500 center](./pics/03_workflow_5.png) - ---- -##### Pushing -When we're ready to share our work, we'll use `git push`. If the remote branch already exists, we can push directly to that branch: -```console -$ git checkout testing -$ git add -A -$ git commit -m "testing branch commit" -$ git push origin testing -``` -This will push our changes to the existing testing branch on GitHub. - ---- -If we were working with a branch that only exists locally, we can push it to GitHub with a slight tweak: -```console -$ git checkout new-branch -$ git add -A -$ git commit -m "new branch commit" -$ git push origin main:new-branch -``` -This will create a new branch on GitHub called `new-branch`. From here, if we want to continue updating this branch, we can just run `git push origin new-branch`. -Then we'll create a branch that exists on our local drive: -```console -git checkout -b testing origin/testing -``` -Here we're pointing the `HEAD` to the new branch (`-b`) called `testing` from `origin/testing` diff --git a/03_instructional_team/markdown_slides/04_optional_git_slide.md b/03_instructional_team/markdown_slides/04_optional_git_slide.md deleted file mode 100644 index ac166cc..0000000 --- a/03_instructional_team/markdown_slides/04_optional_git_slide.md +++ /dev/null @@ -1,2140 +0,0 @@ ---- -marp: true -theme: dsi_certificates_theme -style: | - section { - font-family: Inter, -apple-system, BlinkMacSystemFont, 'Helvetica Neue', sans-serif; - } -_class: invert -paginate: true ---- - -# Version Control and GitHub -``` -$ echo "Data Sciences Institute" -``` - ---- -Prerequisites: -- GitHub account - ---- -Key Texts: -- Chacon and Straub, 2014, Pro Git, 2nd Edition. -- Timbers, Campbell, Lee, 2021, Data Science: A First Introduction, https://ubc-dsci.github.io/introduction-to-datascience/ - ---- -References -- Chacon and Straub: Chapter 1 -- Timbers: Chapter 12.3 - 12.4, 13.3.1 - ---- - - -## `Version Control` - ---- -##### What is Version Control? -Version control is a system that records changes to a file or a set of files over time so that we can recall a specific version later. We may already do this by copying files to another directory to save past versions.While it is simple, it lacks flexibility and complexity. - ---- -Version Control Systems (VCS) can do a number of things and can be applied on nearly any type of file on our computers: -- revert files to a previous state -- revert entire project to a previous state -- compare changes over time -- see who modified something last -- who introduced an issue and when -- recover lost files - ---- -##### Local Version Control Systems -Local VCSs were developed to keep track of changes to our files by putting them in a version database. - -![bg right contain](./pics/02_lvc.png) - ---- -##### Centralized Version Control Systems -Centralized VCSs (CVCS) were developed to enable collaboration with developers on other systems. CVCSs have a single server that contains all the versioned files. - -![bg left contain](./pics/02_cvcs.png) - ---- -CVCSs allow some level of transparency to others' work and give Administrators a level of control over what developers can and can't do. - -Unfortunately, a single server means that if it ever goes down, all collaboration halts for however long that lasts for. Additionally, if backups haven't been kept, work could easily be lost. - ---- -##### Distributed Version Control Systems -To handle the limitations of LVCSs and CVCSs, Distributed VCSs were created. This includes Git, Mercurial and Bazaar. - -Collaborators mirror the entire repsoitory, therefore if a server dies, any one of the collaborators' repositories can be copied back to the server to restore it. - ---- -![w:560 center](./pics/02_dvcs.png) - ---- - - -Questions? - ---- - - -## `Git` - ---- -##### Git Basics -Git thinks of data in a very different way than other VCSs. Instead of storing a set of files and the changes over time, Git thinks of its data more like a set of snapshots of a mini file system. - -If files have not changed, Git does not store the file again, it links to the previous identical file already stored. - ---- -![w:1100 center](./pics/02_git_data.png) - ---- -##### Local Operations -Most operations on Git only need local files and resources to operate. Git also keeps the entire history of our projects on our local disks meaning we can see changes made months ago without a remote server. - -We also don't need to be connected to the server to get work done, rather we only need to be connected when we want to upload our work. - ---- -##### Benefits -Git uses a check-summing mechanism called *SHA-1 hash* which is calculated based on the contents of a file or directory structure in Git. It looks somehting like this: -``` -24b9da6552252987aa493b52f8696cd6d3b00393 -``` -This checksum means it's impossible to change the contents of any file or directory without Git knowing about it. - -Git generally only adds data, making it fairly difficult to lose data once we've committed, which we'll learn about later. - ---- -##### The Three States -There are three main states that our files can reside in: -- Committed: - - data is safely stored on local database -- Modified: - - file has been changed but not yet committed -- Staged: - - modified file has been marked to go into the next commit - ---- -##### The Three Main Sections -There are three main sections to a Git project: -- The Git directory -- The working directory -- The staging area - ---- -##### The Git Directory -The Git directory is where Git stores the metadata and object database for our projects. It is what is copied when we clone a repository from another computer. - ---- -##### The Working Directory -The working directory is a single checkout of one version of our projects. These files are pulled out of the compressed database in the Git directory and placed on the disk for us to modify. - ---- -##### The Staging Area -The staging area is a simple file that stores information about what will go into our next commit. - ---- -##### Workflow -A basic workflow will look something like this: -1. Modify files in our working directory -2. Stage the files in the staging area -3. Commit the changes which takes the files from the staging area and stores them on the Git directory. - ---- - - -Questions? - ---- - - -## `Installing Git` - ---- -Typically, Git is already installed on our system but we can check for that using the `git` command: -```console -$ git --version -``` -Does anyone not see a version? - ---- -##### Installing on Linux -If you're on Ubantu: -```console -$ sudo apt install git -``` -
- -If you're on Fedora, RHEL or CentOS: -```console -$ sudo dnf install git -``` -```console -$ sudo yum install git -``` - ---- -##### Installing on Mac - -You can install Git via Homebrew, if you have Homebrew installed (https://brew.sh/). -```console -$ brew install git -``` - -Finally, you can install Git from source at this link: https://sourceforge.net/projects/git-osx-installer/ - ---- -##### Installing on Windows -The download will start automatically through this link: https://git-scm.com/download/win - ---- - - -Questions? - ---- - - -## `Git Setup` - ---- -The first thing to do now that we have Git installed on our system is to customize it. These changes will remain despite any upgrades to Git that we install. - -Using the command `git config`, we can set configuration variables that control all aspects of how Git looks and operates. - ---- -##### Checking Configurations -Before we change any of our global configurations, we can check what they are: -```console -$ git config --list -``` -If we haven't configured Git, we can do that now! - ---- -##### Identity -First, we'll set our username and email address. Git uses this information everytime we commit. -```console -$ git config --global user.name "Jane Doe" -$ git config --global user.email "jane.doe@gmail.com" -``` -The option `--global` means that we only have to pass this through once. - ---- -##### Editor -Next, we'll configure our the default text editor for when Git needs to type in a message. Git uses our system's default editor (usually Vi or Vim) but we can change it if we prefer. If we want to change the editor to emacs, we would do so below: -```console -$ git config --global core.editor emacs -``` - ---- -##### Diff Tool -We can also set the default diff tool which is used to resolve merge conflicts: -```console -$ git config --global merge.tool vimdiff -``` - ---- -##### Checking the Setting -We can use the `git config --list` command to see all Git settings. See the values of a specific specific setting: -```console -$ git config user.name -``` - ---- -##### Help -If we ever need help, even offline, we can access the manual page three ways: -1. `$ git help ` -2. `$ git --help` -3. `$ man git-` - -For example, we can get help for the `config` command: -```console -$ git help config -``` - ---- - - -Questions? - ---- - - -# Git Basics - ---- -References -- Chacon and Straub: Chapter 2 - ---- - - -## `$ git init` / `$git clone` - ---- -##### Respositories in an Exisiting Directory -We're quickly getting into how to start our first Git repository, or commonly known as repo. First we'll learn how to import an existing repo into Git: -```console -$ git init -``` -```console -$ git init -b main -``` -Here we're creating a new subdirectory named `.git` that will contain all our necessary repo files. The option `-b` will create a new branch called main. - ---- -##### Cloning an Existing Respository -If we want to collaborate on an existing repo, we need to clone the repo from GitHub. If we don't have a project set up yet, we'll need to do that first. - ---- -1. Create a new project -
- -![w:1100 center](./pics/03_creating_repo_1.png) - ---- -2. Add name and optional description -
- -![w:1100 center](./pics/03_creating_repo_2.png) - ---- -3. Choose public or private and add initialize -
- -![w:1000 center](./pics/03_creating_repo_3.png) - ---- -There are a number of automatically generated files such as log files that we might not want Git to add or show as untracked. We can create a file called `.gitignore` to ignore the automatically generated files. - -The `.gitignore` is dependent on the type of coding language you are using but can also be modified to fit specific purposes. - ---- -If we created a repo on GitHub, we can choose a `.gitignore` template. We can select a template specific to the coding language we are using. - -![w:900 center](./pics/03_git_ignore_small.png) - ---- -Once we have our repo, we can clone it: -```console -$ git clone https://github.com/rachaellam/git-module.git -``` -Using this code, we've created a repo called `git-module` (by taking the last part of the link) and initialized a `.git` directory and pulled all data for that repository while checking for the latest copy. - ---- -The url used in the previous code block is copied directly from GitHub by clicking code and copying the HTTPS: - -![w:1150 center](./pics/03_github.png) - ---- -If we want to change the name of the repo, we can specify that as the next command line option: -```console -$ git clone https://github.com/rachaellam/git-module.git mymodule -``` - ---- - - -Questions? - ---- - -# Git Commands - ---- -References -- Chacon and Straub: Chapter 2 -- Timbers: Chapter 12.5 - ---- - - -## `$ git status` - ---- -##### Tracked and Untracked Files -Files in our working directory can either be tracked or untracked. Tracked files are files that that were in the last snapshot and can be unmodified, modified or staged. Untracked files are files that aren't in our last snapshot or staging area. - -When we modify a file, Git keeps track of the modifications even before we've decided to commit. We can then stage the modifications and then commit. - ---- -![w:1000 center](./pics/03_workflow.png) - ---- -##### File Status -To better understand what state our files are in, we can check the status: -```console -$ git status -``` -If we've just created our repo, we should see (or something similar): -```console -# On branch main -# Your branch is up to date with 'origin/main'. - -# nothing to commit, working tree clean -``` - ---- -Let's now add a README.md file, because every good repo has a good README. - -```console -$ touch README.md -``` - -And see the status: - -```console -$ git status -``` - ---- -```console -On branch main - -No commits yet - -Untracked files: - (use "git add ..." to include in what will be committed) - README.md -``` -Here we can see that we still haven't committed anything and that we have an untracked README.md file. Git also gives us a bit of information including how to add a file to track. - ---- - - -## `$ git add` - ---- -##### Tracking New Files -To track new files, or stage new files, we can use `git add` along with the file that we want to track: -```console -$ git add README.md -``` -We can run `git status` again to see the results of `git add`. - ---- -```console -On branch main - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: README.md -``` -Now we can see that our README.md file is staged to be committed. - ---- -Let's say we add some more info to our README.md file, which has now been tracked. If we run `git status`, we can know: -```console -On branch main - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: README.md - -Changes not staged for commit: - (use "git add ..." to update what will be committed) - (use "git restore ..." to discard changes in working directory) - modified: README.md - -``` - ---- -We can stage our additional changes and check the status: -```console -$ git add README.md -$ git status -``` -```console -On branch main - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: README.md - -``` - ---- -Let's try adding another file into our directory. It can be something that you've been working on independently, or we can add our project from the previous Unix module. - ---- -If we modify many things at once, we can add the option `-A` to add all files, rather than adding one by one -```console -$ git add -A -``` -A little note about this: it's best to upload your work in small chunks for readability and for collaboration. So if you have a bunch of files, it's recommended to split them into smaller chunks. - ---- - - -Questions? - ---- - - -## `$ git diff` - ---- -If we want to see more details of the changes that we've made, we can use the command `git diff`. - -`git diff` compares what is in our working directory to what is in our staging area. If we've made changes to our files without running `git add`, we'll see the comparison. If there are no differences, nothing will be shown. - ---- -```console -diff --git a/README.md b/README.md -index e69de29..4711fce 100644 ---- a/README.md -+++ b/README.md -@@ -0,0 +1 @@ -+# git-r -\ No newline at end of file -``` - ---- -```console -diff --git a/README.md b/README.md -``` -This is telling us what we're comparing. In this case, it's the difference between a previous version of the README file and the current one - ---- -```console -index e69de29..4711fce 100644 -``` -Here is some meta data, or hash identifier that we likely won't need. - ---- -```console ---- a/README.md -+++ b/README.md -``` -This is acting as a legend. Changes from `a/README.md` are marked by `---` and changes from `b/README.md` are marked by `+++` - ---- -```console -@@ -0,0 +1 @@ -+# git-r -``` -Here we're being told the lines that have changed and what on those lines changed. Because there was nothing removed, this is a bit of a simplistic representation. - ---- -We might see something more like... -```console -@@ -21,5 +77, 12 -``` -This is telling us 5 lines were removed starting on line 21 and 12 lines were added starting on line 77. - ---- -##### --staged -If we want to see the details of what will go into the next commit, we can use `git diff` with the option `--staged` - ---- - - -## `$ git commit` - ---- -Once we've staged your selected files, it's time to commit the changes. Anything that wasn't staged (any modifications since `git add`) will not be included in the commit. - -`git commit` is most easily run with the option `-m`. This adds a message to your commit - -```console -$ git commit -m "adding a message here" -``` - ---- -##### -m -Messages should be clear. They can also be extremely detailed if needed. By not including the option `-m`, Git will provide the latest output of `git status`. If you want even more information, you can use the option `-v`. - ---- -Messages are extremely important for our own records and also when collaborating with others. They can act as a reminder for what our commit includes, and also tell our collaborators what we did last. - -It's important to commit often as well so that merges are easier to locate and fix. - -It's also helpful if you want to go back to an earlier version. You have more options to choose from. - ---- -Practices around messages can vary but if we want to add a longer message we can remove the `-m` option. -```console -$ git commit -``` -Then hit `i` to add a message. You'll see `-- INSERT --` at the bottom and you can begin typing your message. - -When finished, press `esc` then `:wq` or `:x`. - -`w` means write and `q` means quit. `x` is shorthand for `wq` - ---- -``` -Short (50 chars or less) summary of changes - -More detailed explanatory text, if necessary. Wrap it to about -72 characters or so. In some contexts, the first line is treated -as the subject of an email and the rest of the text as the body, -the blank line separating thesummary from the body is critical -(unless you omit the body entirely). - -Further paragraphs come after blank lines. - -- Bullet points are okay, too - -- Typically a hyphen or asterisk is used for the bullet, preceded - by a single space with blank lines in between, but conventions - vary here -``` - ---- -##### -a -If we want to commit all the files we've worked on without putting them in the staging area, we can use the option `-a`. This will avoid using `git add` and condense our workflow. -```console -$ git commit -a -m "skip staging add message" -``` -Here we've used two options, `-a` and `-m` to skip the staging and add a message. - ---- - - -Questions? - ---- - - -## `$ git rm` - ---- -If we delete a file from our working directory after staging it using `rm` without `git`, the file will show up in our untracked files. We can then use `git rm` to stage the file's removal. - -Let's follow the code below to understand this better: -```console -$ touch test.sh -$ git status -$ rm test.sh -$ git status -``` -Because we haven't tracked the `test.sh` file so we can remove it and we don't need to tell git to also remove it. - ---- -What happens if we add a file to our staging area but then want to delete it? Let's try the two codes below: -```console -$ touch test.sh -$ git add test.sh -$ git rm test.sh -``` - -```console -$ touch test.sh -$ git add test.sh -$ rm test.sh -$ git rm test.sh -``` - ---- -##### -f -If we've modified and staged a file, we have to force the removal with the option `-f`. This is a safety feature so that we don't accidentally delete something. - ```console - $ touch testfile - $ git add testfile - $ git rm -f testfile - ``` - - --- - ##### --cached - The option `--cashed` allows us to remove a file from our staging area without permanently deleting it from our local drive. -```console -$ git rm --cached testfile -``` -We can use wildcards to remove files from our staging area in bulk, although we have to add a backslash in front of `*` because Git does its own filename expansion. -```console -$ git rm -f \*.txt -``` - ---- -We can also delete files in a folder of our working directory: -```console -$ git rm -f dir1/\*.sh -``` - ---- - - -## `$ git mv` - ---- -Using `git mv`, we can rename files conveniently and succinctly: -```console -$ git mv test.txt test.sh -``` - ---- - - -Questions? - ---- - - -## `$ git log` - ---- -Sometimes we might want to see a history of our commits or we want to see previous commits after cloning an existing repository. We can do this using the `git log` command. - -```console -$ git log -``` -There are a number of options that help us see even more, or sometimes less, information about each commit. - ---- -If we attempt to run a log before any commits have been made, we will get an error: -```console -fatal: your current branch 'main' does not have any commits yet -``` - ---- -##### -p -Adding the option `-p` will show the `diff` introduced in each commit. We can also pass a number option that will limit the number of entries shown: - -```console -$ git log -p -2 -``` -Entries can be any number of entries (`-`)but is limited to one page of log out puts - ---- -##### --stat -The `--stat` option shows abbreviated stats for each commit: -```console -$ git log --stat -``` - ---- -```console -commit 6c91df668d1899317a643153bd169d37fe05d9f1 (HEAD -> main) -Author: Jane Doe -Date: Fri Feb 18 14:56:27 2022 -0500 - - first commit - - .gitignore | 4 ++++ - README.md | 1 + - test.Rproj | 13 +++++++++++++ - testfile.r | 0 - 4 files changed, 18 insertions(+) -``` -`+` or `-`(if there were any) show the number of insertions or deletions. We can also see the date of the commit, who committed and the message. - ---- -##### --pretty -The `--pretty=` option is an interesting feature that enables us to specify the log output when we combine it with `format:`, creating an extremely useful data extraction feature: -```console -$ git log --pretty=format:"%h - %an, %ar : %s" -``` - ---- -##### Formatting Options -Option | Description -:-----|:------ -%H | Commit hash -%h | Abbreviated commit hash -%t | Abbreviated tree hash -%p | Abbreviated parent hashes - ---- -Option | Description -:-----|:------ -%an | Author name -%ae | Author email -%ad | Author date (ex. Thu Dec 2 14:14:55 2021 -0500) -%ar | Author date relative (ex. 26 hours ago) -%cn | Committer name -%s | Subject (-m) - ---- -##### --since / --until -The options `--since=` and `--until=` are more usually more useful than `-(n)`. They produce the logs of any time before (`--until`) or after (`--since`) a certain date. You can specify an exact date or relative date: -```console -$ git log --since=2.weeks -``` -```console -$ git log --since="2 days 3 minutes ago" -``` -```console -$ git log --until="2021-11-20" -``` - ---- -We can also combine log options to generate specific outputs: -```console -$ git log --pretty=format:"%h: %s" --author=Rachael -``` -```console -$ git log --after="2020-11-01" --since="2020-11-30" -``` - ---- -Finally, and a favourite for quick glances: - -```console -$ git log --oneline -``` - ---- - - -Questions? - ---- - - -## `undo undo undo` - ---- -##### Changing Commit -If we already committed a few files but forgot to add one or made modifications since our commit that we want to add, we can use the option `--amend` -```console -$ git commit -m "initial commit" -$ git add missed_file -$ git commit --amend -m "initial commit with missed_file" -``` -We can still add the `-m` option to add a new comment. - ---- -##### Unstaging -When we want to remove a file from our staging area because we accidentally added one too many files, we can use the code below: -```console -$ git reset HEAD README.md -``` -If we ever forget how to do this, running `git status` will remind us. - ---- -##### Unmodify -We can also revert our files back to the version from our previous commit using `git checkout --`. It's important to realize that this command essentially rewrites the file so any changes that were made will not be able to be recovered. - -As well, any commit can usually be recovered but anything that was never committed will most likely be lost forever. -```console -$ git checkout -- README.md -``` - ---- -##### Select Previous Commit -To select a previous commit to revert to, we need the hash of the commit: -```console -$ git log -$ git checkout file1 -``` -This can be used forwards or backwards, ie. you can also "revert" to a commit that later than your current version. - -You can also revert several files at the same time -```console -$ git checkout file1 file2 -``` - ---- - - -Questions? - ---- - -# Remote Repositories - ---- -References -- Chacon and Straub: Chapter 2 -- Timbers: Chapter 12.5-12.6 - ---- - - -## `$ git remote` - ---- -Remote repos are versions of our projects that are hosted on the internet or some network. This allows us to collaborate with others outside of our local repo. - -We can see the remote servers we've configured using `git remote`. If we add the option `-v`, we can see the URL: -```console -$ git remote -v -``` -Cloned repos will be displayed as origin by default. - ---- -##### Remote Setup -Before we connect our local repo to a remote repo, we need to setup our permissions. This is so we can send and retrieve work to and from our remote repositories. There are two ways to do this: - -1. Access Tokens - -2. SSH - ---- -##### Access Tokens - -               ![w:350 left](./pics/03_settings.png)           ![w:340 right](./pics/03_developer.png) - ---- -![w:1150 center](./pics/03_personal_auth.png) - ---- -##### SSH -```console -$ ls -al ~/.ssh -``` -If SSH has not been set up on your computer, you should see something like: - -```console -ls: cannot access '/c/Users/rachaellam/.ssh': No such file -or directory -``` - -Otherwise you'll see filenames `id_ed25519` and `id_ed25519.pub` OR `id_rsa` and `id_rsa.pub` which represent your public and private keys. - ---- -```console -$ ssh-keygen -t ed25519 -C "rachael.lam@mail.utoronto.ca" -``` -Use the code above but with your email. This will output: - -```console -Generating public/private ed25519 key pair. -Enter file in which to save the key (/c/Users/rachaellam/.ssh/ -id_ed25519): -``` -Press `enter` to use the default file. - ---- -You will then be prompted to add a passphrase. You cannot reset this passphrase, so be sure to remember it or write it down somewhere safe: - -```console -Created directory '/c/Users/Vlad Dracula/.ssh'. -Enter passphrase (empty for no passphrase): -``` - -It will then ask you to reenter the passphrase: - -```console -Enter same passphrase again: -``` - ---- -You will then get a confirmation with a random piece of art at the end. It will show the private key (*identification*) which you should never share, the *public key* and the *key fingerprint* which is a shorter version of the public key. -```console -Your identification has been saved in /c/Users/rachaellam/.ssh/ -id_ed25519 -Your public key has been saved in /c/Users/rachaellam/.ssh/ -id_ed25519.pub -The key fingerprint is: -SHA256:SMSPIStNyA00KPxuYu94KpZgRAYjgt9g4BA4kFy3g1o -rachael.lam@mail.utoronto.ca -``` - ---- -Now we can check that we have the public and private key files: -```console -$ ls -al ~/.ssh -``` - ---- -It's time to give GitHub our public key so let's read the public key file and copy it: -```console -$ cat ~/.ssh/id_ed25519.pub -``` -Output: -```console -ssh-ed25519 AAAAC3NzaC1lZDI1NPN7AAAAIDmRA3d51X0uu9wXek559gfn6UFNF -69yZjChyBIU2qKI rachael.lam@mail.utoronto.ca -``` -Copy the long public key to add to GitHub. - ---- -##### Settings --> SSH and GPG keys --> New SSH key -Add a title like `rachael's key` and paste the public key then click *Add SSH key*. - -Finally, we can check that it's been authenticated: -```console -$ ssh -T git@github.com -``` - ---- -##### remote add -To add a remote repo, we can use `git remote add` followed by the name and URL. Now we can connect our local repo to a remote repo: -```console -$ git remote add origin https://github.com/rachaellam/git-r.git -$ git remote -v -``` -After checking we'll see: -```console -origin https://github.com/rachaellam/git-r.git (fetch) -origin https://github.com/rachaellam/git-r.git (push) -``` - ---- -If we want to see more information about a remote repo, we can use the command: -```console -$ git remote show origin -``` -Here we can see the URL that we're fetching and pulling from, our remote branches, and configurations for git push (to the main branch or another). - ---- -To send and retrieve work between our local and remote repositories, we have to authenticate a personal access token: - -               ![w:350 left](./pics/03_settings.png)           ![w:340 right](./pics/03_developer.png) - ---- -![w:1150 center](./pics/03_personal_auth.png) - ---- - - -Questions? - ---- - - -## `$ git fetch` / `$ git push` - ---- -When collaborating with others, changes might be made that are important to copy to your local directory. `git fetch` will get any new changes but it won't merge it to our work or modify our work. -```console -$ git fetch origin -``` - ---- -`git pull` will automatically fetch and merge a remote branch to our current branch (more on branching later). It's a good practice to pull before every work session, especially when working with others. Otherwise, a collaborator might have made changes, and you won't be able to push your changes to GitHub. -```console -$ git pull -``` - ---- -If we've create our remote repository using `init` and `remote add`, we need to specify the remote that we want to pull to and the branch we want to pull from. -```console -$ git pull origin main -``` -`origin` being the name of the remote repo we created earlier and `main` being the main branch on our GitHub repo. - ---- - - -Questions? - ---- - - -## `$ git push` - ---- -When we're ready to share our modifications, we have to push our project and files upstream using `git push` -```console -$ git push origin main -``` -Here we're pushing to our origin server on your main branch. The main branch is sometimes called the master branch. - -This command only works if we have write access and if no collaborator is pushing upstream at the same time as we are. We'd have to instead pull and merge their work before pushing our own. - ---- - - -Questions? - ---- - -# Git Branching - ---- -References -- Chacon and Straub: Chapter 3 -- Timbers: Chapter 12.8 - ---- -Branching allows us to diverge from the main line to do work without accidentally messing with the main line. This helps with testing without making any accidental changes to the working branch. - -To understand how branching works, let's go back and understand how Git saves files. -- blob -- tree -- pointer - ---- -![w:1000 center](./pics/03_blobs.png) - ---- -A branch is a way to move different pointers to a specific commit. In Git, the default branch is named *master* or *main*. When we first start making commits, we start at the master branch that automatically points to the last commit made. - -![w:700 center](./pics/03_master.png) - ---- - - -## `$ git branch` - ---- -We can make a new branch which creates a new pointer for us to move around. We can do this by using the command `git branch`: -```console -$ git branch testing -``` - ---- -Here, we've created a branch called testing, which means we've created a new pointer that could point to our current commit. - -![w:800 center](./pics/03_testing.png) - ---- - - -## `$ git checkout` - ---- -Git tracks what branch we're on using a pointer called `HEAD`. If we move the `HEAD` to the branch *main*, we'll see: -```console -Already on 'main' -``` -To move `HEAD` to point to the testing branch that we just created, we use `git checkout`: -```console -$ git checkout testing -``` -and we should see.. -```console -Switched to branch 'testing' -``` - ---- -![w:800 center](./pics/03_testing_head.png) - ---- -If we make some changes to our testing branch and commit, our head will move with the new commit. - -![w:800 center](./pics/03_testing_commit.png) - ---- -If we want to go back to an older version of our project and make changes, we can use `git checkout` again to redirect the head back to our master branch: -```console -$ git checkout main -``` -Using this command will move the `HEAD` pointer back to our master branch and revert our files in our working directory back to the snapshot that the master branch points to. - ---- - - -Questions? - ---- - - -## `Branching and Merging` - ---- -Let's take a look at a workflow that you might encounter: -```console -$ git commit -m "commits to master branch" -``` -![w:800 center](./pics/03_workflow_1.png) - ---- -```console -$ git checkout -b iss53 -``` -![w:600 center](./pics/03_workflow_2.png) - ---- -```console -$ git commit -a -m "commits to iss53" -``` -![w:700 center](./pics/03_workflow_3.png) - ---- -```console -$ git checkout master -$ git checkout -b 'hotfix' -$ git commit -m "commits to hotfix" -``` -![w:600 center](./pics/03_workflow_4.png) - ---- -```console -$ git checkout master -$ git merge hotfix -``` -![w:500 center](./pics/03_workflow_5.png) - ---- - - -## `$ git merge` - ---- -In the last step we saw a command called `git merge`. Once we've committed changes and are ready to deploy, we can use `git merge` to merge our working branch back into our master branch. - -```console -$ git merge testing -``` - ---- -![w:600 center](./pics/04_delete_branch.png) - ---- -We can then delete the branch that we've created, as the master branch points to the same place. - -Adding the option `-d` will delete the branch that had been merged with the main, as we no longer need it. -```console -$ git branch -d testing -``` - ---- -Remember that changes to our master branch have not been added to our *iss53* branch. We either need to `pull` them in or wait to integrate them when we `pull` *iss53* into the master branch - -![w:600 center](./pics/04_difference.png) - ---- -If we're merging a branch with the main that has been changed since we diverged, merging isn't as simple for Git. - -Git will create a new snapshot of the merge and automatically create a new commit that points to it, called a `merge commit`. - -![w:600 center](./pics/04_merge.png) - ---- -We saw `git branch` earlier with the option `-d` to delete a branch, but to get a list of our current branches, we can run `git branch` without any arguments. -```console -$ git branch -``` -The `*` indicates the branch we are currently on or have checked out (`git checkout`) - ---- -If we run `git branch` with the option `-v`, we can see the last commit on each branch. This is another reason why comments are so important to add to our commits: they can be extremely useful when looking back at our work and seeing what we've done. - ---- -We can also add the options `--merged` or `--no-merged` to `git branch`. `--merged` allows us to see what branches been merged to the branch we're currently on. Branches without the `*` are generally safe to delete because we've already merged our work with our main branch. -```console -$ git branch --merged -``` - ---- -On the other hand, `--no-merged` allows us to see all the branches that haven't been merged. -```console -$ git branch --no-merged -``` -If we try to delete one of these branches, we will receive an error. We can force delete using the option `-D`. - ---- - - -## `Merge Conflicts` - ---- -Often times, merging our work with other topic branches or the main branch creates errors. - -For example, if we've changed the same part of the same file differently in the two branches we're merging, we will encounter a conflict. - -Luckily, Git helps us see where the error is to correct it. - ---- -![bg contain](./pics/04_merge_conflicts.png) - ---- -Git shows us the beginning of the merge conflict with -`<<<<<<< HEAD` and the end with `>>>>>>>`. -
- -`=======` separates the differences. -
- -To fix the merge, you can choose one set of changes, the difference you prefer or re-write it entirely. You have to remove all identifiers of the merge conflict as well. - ---- - - -Questions? - ---- - - -## `Branching Workflow` - ---- -##### Long-Running Branches -Multiple long running branches are helpful when tackling large and complex projects. - -Typically, developers will keep the master branch as the stable branch or code that has been or will be released. They will then have parallel branches that are used for development and testing. - -Braches can also have various levels of stability, and will graduate/merge branches once they're fully tested. - ---- -![w:1000 center](./pics/04_topics_1.png) - ---- -##### Topic Branches -Topic branches are short-lived branches that are created for a particular feature or related work. They allow us to quickly switch between topics and keep changes there for as long or as little as needed, regardless of the created or modified order, before merging. - ---- - -![w:600 left](./pics/04_topics_2.png) -![w:435 right](./pics/04_topics_3.png) - ---- - - -Questions? - ---- - - -## `Remote Branches` - ---- -Remote branches are pointers to the state of branches on our remote repositories. Our remote repositories can have multiple remote branches, just as we can have multiple braches on our local repositories. - -The format is `(remote)/(branch)` or `(remote) (branch)` - -If branches already exist on your GitHub repo, you will have access to these branches. If we're working with a branch that does not exist yet, we can push it to our remote repo. - ---- -##### Pushing -When we're ready to share our work, we'll use `git push`. If the remote branch already exists, we can push directly to that branch: -```console -$ git checkout testing -$ git add -A -$ git commit -m "testing branch commit" -$ git push origin testing -``` -This will push our changes to the existing testing branch on GitHub. - ---- -If we were working with a branch that only exists locally, we can push it to GitHub with a slight tweak: -```console -$ git checkout new-branch -$ git add -A -$ git commit -m "new branch commit" -$ git push origin main:new-branch -``` -This will create a new branch on GitHub called `new-branch`. From here, if we want to continue updating this branch, we can just run `git push origin new-branch`. - ---- -##### Fetching -When we `fetch` or `pull` files from our remote repos, we don't automatically have access to local, editable copies of files of the remote branches. - -We can do this in several steps. First we're going go fetch the remote branches: -```console -$ git fetch -``` - ---- -We can then see what branches exist remotely: -```console -$ git branch -v -a -``` -And we'll see something like this: -```console -* main 3d850f2 a commit - remotes/origin/HEAD -> origin/main - remotes/origin/main 3d850f2 another commit - remotes/origin/testing 3d850f2 another committ -``` - ---- -Then we'll create a branch that exists on our local drive: -```console -git checkout -b testing origin/testing -``` -Here we're pointing the `HEAD` to the new branch (`-b`) called `testing` from `origin/testing` - ---- -##### Tracking Branches -Tracking branches are branches that have a direct relationship with a remote branch. We can `push` and `pull` to and from these branches, as Git automatically knows which server and branch we're working with. - -For this to work, the name of your local branch must be the same as the remote branch - ---- -If the branches are named differently, we must run a different command for the push to be successful: -```console -$ git push origin HEAD:remote-branch -``` - ---- -##### Deleting Branches -If we've merged all our changes into our main branch, we can delete the remote branch with the following code: -```console -$ git push origin :testing -``` - ---- - - -Questions? - ---- - -# Collaborating - ---- -References -- Chacon and Straub: Chapter 3 + 5 -- Timbers: Chapter 12.8 - ---- -Much of the work that we do will involve working with others. It's important that we learn how best do this so we can successfully collaborate and avoid conflicts where possible. If conflicts arise, good collaboration practices help us resolve them with ease. - -So far we've learned several practices and commands that help us collaborate with others, including remote repositories and branches, `git pull` `git push` and `git merge` but we'll learn more practices that make collaboration straightforward. - ---- -There are many different factors that influence what workflow you might follow and how you might contribute to a project including: - -1. Active contributor size -Teams can vary from a few collaborators to thousands, varying the number of commits per day. - -2. Chosen workflow -Each project could have a different process to check patches including an integration manager or peer reviews. - -3. Commit access -Policies regarding how to contribute work can differ between projects, even by how much work or how often. - ---- -Let's take a look at a couple possible workflows: - -![w:500 center](./pics/04_colab_workflow.png) - ---- -![w:600 center](./pics/04_colab_workflow_2.png) - ---- - - -## `GitHub` - ---- -##### Adding Collaborators -To collaborate with others on our GitHub repo, we can add collaborators so they have direct access to the repo: - -![w:1100 center](./pics/04_git_collabs_1.png) - ---- -![w:1100 center](./pics/04_git_collabs_2.png) - ---- -![w:800 center](./pics/04_git_collabs_3.png) - ---- -Access does not have to be permanent. We can remove collaborators at any time and add additional ones when needed. - -Granting access to your repo this way, enables collaborators to make changes and push them to the repo without our constant permission. If we do not add push access, collaborators have to fork the repo and create pull request. - ---- -##### Forking Projects -Forking allows us to collaborate on projects without push access. We can fork a public project on GitHub and then clone it into our local server to begin making changes. - -![w:1150 center](./pics/04_fork_1.png) - ---- -Once a project has been forked, we can find the repo in our GitHub repositories. We can then clone the repo (`git clone`), make changes and push our changes without altering the original repo. - -Alternatively, we can clone the original repo, make our changes, fork the original repo and then merge our branch to the master branch of the forked repo. - -If we're collaborating with someone and we want our changes to be merged to the original repo, we can create a pull request. - ---- -##### Pull Request -After making a few changes, we now want to create a pull request to merge our changes with the original repo. We can do this directly in GitHub: - -![w:1100 center](./pics/04_pull_request_2.png) - ---- -To the pull request, we can see what branches and repos we're attempting to merge: - -![w:800 center](./pics/04_pull_request_3.png) - ---- -We can also see the changes that were made: - -![w:1100 center](./pics/04_pull_request_4.png) - ---- -GitHub will also check to make sure that there are no conflicts with the base branch: - -![w:900 center](./pics/04_pull_request_5.png) - ---- -Pull requests with no merge conflicts are easy to merge into the branches but it gets more complicated if there are merge conflicts: - -![w:1100 center](./pics/04_pull_request_merge_conflict_1.png) - ---- -You can still create a pull request with merge conflicts: - -![w:1100 center](./pics/04_pull_request_merge_conflict_2.png) - ---- -![w:1000 center](./pics/04_pull_request_merge_conflict_3.png) - ---- -To resolve conflicts, it's very similar to merging conflicts through terminal: - -![w:1100 center](./pics/04_pull_request_merge_conflict_4.png) - -Because resolving conflicts is done on GitHub, it's a good practice to resove conflicts before creating a pull request. - ---- - - -Questions? - ---- - -# Conflicts - ---- -References -- Chacon and Straub: Chapter 3 + 6 -- Timbers: Chapter 12.5 - ---- -Conflicts are going to arise at some point, especially when working with others. It's important that we learn how to handle these conflicts for easier and more successful collaboration. - ---- - - -## `GitHub Issues` - ---- -GitHub issues are an extremely useful tool for communicating decisions, ideas and problems that are project specific. - -They are an alternative to email or Slack that keep communication isolated to a particular project. - -Issues can be *opened* on GitHub and even when they're *closed*, they remain available. They're also accessible to all collaborators for transperancy. - ---- -To open an issue, navigate to the project page and click *Issues*: - -![w:1100 center](./pics/04_issues_1.png) - ---- -Then open a new issue: - -![w:1100 center](./pics/04_issues_2.png) - ---- -From here, we can add a title and description of the issue, and add any specific collaborators, labels, etc. - -![w:1100 center](./pics/04_issues_3.png) - ---- -##### Information -Title: should be descriptive and quickly convey what the issue is about - -Description: explain the purpose of the issue and how to potentially resolve it. If it's a bug fix, include a reprex, what you wanted to happen and what actually happen. You can also include steps already taken to solve the issue. - ---- -##### Reprex -- A reprex is a REPRoducible EXample. - -- It contains just enough of the code to reproduce the error, ie. it is self-contained - -- We might have to create a smaller version of the code in order to create the reprex. Don't include anything that isn't related to the problem. - -- Sometimes, this process will help us solve our issue. - ---- -##### Inclusions -A minimal dataset to demonstrate the problem. This could be a regularly used one such as *iris* -```python -install.packages("dyplr") -library(dplyr) -head(mtcars) -``` - -or one easily built yourself. -```python -df <- data.frame (col1 = c(1, 2), - col2 = c(3, 4)) -df -``` - ---- -- Make sure to include classes that are necessary to your reprex (ex. dates, factors, etc.) - -- If you're using randomly sampled data, set the seed to so the same data is produced each time. -```rstudio -set.seed(853) -``` - ---- -Include all packages that you need. -
- -- Make sure they are placed at the top of the script so it's quick and easy to see what is necessary for the reprex. - ---- -##### Other Inclusions -- Details about the issues you are facing. - -- Comments that will add clarification to your error. - -- Add what fixes have been attempted. This could include pages to StackOverflow articles that you've viewed. - -- Communicate cleary what you're desired outcome is. - ---- -##### Task Lists -If an issue is quite large, it's possible to add tasks lists to break the issue into smaller pieces. -- Use square brackets `- [ ]` - -- To mark it complete, use `- [x]` - -- Issues can be linked to previous issues using - - the number `- [x] #11` - - a URL `- [x] https://github.com/rachaellam/git-r/issues/11` - ---- -Once an issue has been opened, we can respond and comment. - -When we decide it has been resolved, we can close the issue. The history of the issues can still be seen, even if it has been closed. - ---- - - -Questions? - ---- - - -## `Debugging` - ---- -##### File Annotation -File annotation can help us resolve issues in our code if we know where thie issue is. We can see when the code was introduced and by whom, line by line, using the aptly named `git blame`. - -```console -$ git blame -L 1,3 script.sh -^8e9b89da (Jane Doe 2021-12-02 15:01:02 -0500 1) #line 1 -8e9b89da (Jane Doe 2021-12-02 15:01:02 -0500 2) #line 2 -8e9b89da (Jane Doe 2021-12-02 15:01:02 -0500 3) #line 3 -``` - ---- -`git blame` is combined with the filename we want to inspect. We can also use the option `-L` followed by two numbers to limit the number of lines shown. - -We can then see the partial SHA-1 of the commit that last modified the line, the author name and date of the commit, and the content of the file by line. - -When the SHA-1 is preceeded by a `^`, it indicates that those commits were when the file was first added to the project and have not changed since. - ---- -##### Binary Search -If we don't know where the issue is, we can use `git bisect` to get identify the commit that introduced an issue. -```console -$ git bisect start -$ git bisect bad -$ git bisect good [good_commit] -``` -First, we've started the bisect program. We then told the system that the current commit is broken using `bisect bad` followed by the last good commit using `bisect good [good_commit]`. We can see the different commit if we run `git log` that we learned earlier. - ---- -Git produced the number of commits that were between the good and the bad commit and then checked out the middle one. - -From here, we can run our test to see if the issue still exists. If it does, it means the issue was introduced in a commit before this middle commit and we can run `git bisect bad` to tell the system that there is still an issue. - -If it does not, then the issue was introduced after and we can run `git bisect good`. - ---- -We can keep running this loop until we find the commit that introduced an issue and make our corrections. - -When we're finished, we can run `git bisect reset` to reset our `HEAD` to where we were before we started. - ---- - - -## `Best Practices` - ---- -- Topic branches should be used to try out new code before integrating. They enable us to play around or leave for the time being it if it's not working. -- Commit often rather than submitting a massive commit. This makes it easier to review and merge changes, or revert if necessary. - ---- -- Create quality commit messages so that your collaborators can easily understand what has been done. For example: -``` -Short (50 chars or less) summary of changes - -More detailed explanatory text, if necessary. Wrap it to about -72 characters or so. In some contexts, the first line is treated -as the subject of an email and the rest of the text as the body, -the blank line separating thesummary from the body is critical -(unless you omit the body entirely). - -Further paragraphs come after blank lines. - -- Bullet points are okay, too - -- Typically a hyphen or asterisk is used for the bullet, preceded - by a single space with blank lines in between, but conventions - vary here -``` - ---- - - -Questions? - ---- - - -## `Reproducibility` - ---- -- Reproducibility is the ability for for independent researches to obtain the same or similar results when repeating an experiment or test. - -- This concept has been widely used in natural sciences, but is not yet as popular in data science. - -- Remember, data science is a science. We question, hypothesize, test, and therefore, we should also have the same rigour of confirmation. - ---- -- Skepticism should always be able to be independently verified. We should be able to defend our results and decisions. - -- Who would believe your results otherwise? More importantly, you should not believe results if they cannot be verified. - ---- - - -Why is reproducibility important? - ---- -1. New Insights - -2. Reduce Error Risks - -3. Validate Results - -4. Transparency - ---- - - -How can we make our work reproducible? - ---- -There are a number of practices that can help make our work reproducible including: -- Reproducible Examples -- Commenting Code -- Technical Documentation -- Folder Structure - ---- - - -## `Reproducible Examples` - ---- -##### Reprex -- A reprex is a REPRoducible EXample. - -- It contains just enough of the code to reproduce the error, ie. it is self-contained - -- We might have to create a smaller version of the code in order to create the reprex. Don't include anything that isn't related to the problem. - -- Sometimes, this process will help us solve our issue. - ---- -##### Inclusions -A minimal dataset to demonstrate the problem. This could be a regularly used one such as *iris* -```python -install.packages("dyplr") -library(dplyr) -head(mtcars) -``` - -or one easily built yourself. -```python -df <- data.frame (col1 = c(1, 2), - col2 = c(3, 4)) -df -``` - ---- -- Make sure to include classes that are necessary to your reprex (ex. dates, factors, etc.) - -- If you're using randomly sampled data, set the seed to so the same data is produced each time. -```rstudio -set.seed(853) -``` - ---- -Include all packages that you need. -
- -- Make sure they are placed at the top of the script so it's quick and easy to see what is necessary for the reprex. - ---- -##### Other Inclusions -- Details about the issues you are facing. - -- Comments that will add clarification to your error. - -- Add what fixes have been attempted. This could include pages to StackOverflow articles that you've viewed. - -- Communicate cleary what you're desired outcome is. - ---- - - -## `Commenting Code` - ---- - - -How does commenting code help in reproducibility? - ---- -Commenting code is an important practice that benefits both ourselves and collaborators. - -Not only can we understand what we did to fix our own errors or improve our work, but others can better understand our code to reproduce it. - ---- -[Ellen Spertus](https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/) outlines 9 rules to follow: -
- -1. Comments should not duplicate the code - -2. Good comments do not excuse unclear code -3. If you can’t write a clear comment, there may be a problem with the code -4. Comments should dispel confusion, not cause it - ---- -5. Explain unidiomatic code in comments - -6. Provide links to the original source of copied code -7. Include links to external references where they will be most helpful -8. Add comments when fixing bugs -9. Use comments to mark incomplete implementations - ---- -##### 1. Comments should not duplicate the code -- Comments should add value to whoever is reading your code. -- Duplicating code adds unneccesary bulk and can actually make it more difficult to understand the code. -
- -Can you think of a bad example? - ---- -Here is an example of what you should not do: -```bash -x=5 - -if [ $x = 5 ]; then - echo "x equals 5." # if x = 5 then ouput x equals 5 - -else - echo "x does not equal 5." # otherwise output x does not equal 5 - -fi -``` - ---- -##### 2. Good comments do not excuse unclear code -- Our aim should always be having clear code, rather than relying on our comments to add clarity. -- Remember, we should not be adding more bulk to the code that makes it more difficult to understand. - ---- -##### 3. If you can’t write a clear comment, there may be a problem with the code ->Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to -debug it. - -\- Kernighan's Law - ---- -##### 4. Comments should dispel confusion, not cause it -- If our comments are adding further confusion, we should either rewrite the comment or remove it entirely. -- A could comment should always be written with the intent to help better understand what is being done. - ---- -##### 5. Explain unidiomatic code in comments -- If we've purposefully written code that others may find unecessary, we need to comment our reasoning. -- Others may try to simplify our code if we don't explain our reasoning. -
- -Can you think of an example? - ---- -##### 6. Provide links to the original source of copied code -- Often times, we'll use code that others have written. It's important to give credit to the original source, but as well as give us a reminder as to where we got the code to reference it later if we need. -- Referencing the source can also provide other information such as what the problem was, why the solution was recommended and how it can be improved. It also means, we don't have to comment all of these details again in our own code. - ---- -An example: -```bash -# I got these 9 rules from Ellen Spertus' blog post on -# StackOverflow: https://stackoverflow.blog/2021/12/23/ -# best-practices-for-writing-code-comments/ -``` -- It's best to include the URL so other's don't have to search for the exact location. -- Remember: never copy code that you don't personally understand. -- Code from StackOverflow falls under Create Commons licenses so a reference comment is needed. - ---- -##### 7. Include links to external references where they will be most helpful -- References don't just have to be used for copied code. They can also provide information on decisions made or changes in practices - ---- -##### 8. Add comments when fixing bugs -- Comments can help others understand what we modified, if the modification is still needed, and how to test our modifications -- Although `git blame` can be used to find the commit that modified the code, a good comment can help locate the change and are quite brief. - ---- -##### 9. Use comments to mark incomplete implementations -- Sometimes we have limitations in our knowledge or time. Adding code documenting these limitations can allow us to better address and fix the issues. - ---- -##### Some other good practices: -- Comments should be clear and efficient. Don't add more information than necessary, but don't be too vague -- Remember to update your comments if you update your code. Old comments can add more confusion. -- Inline comments can add noise as they're mixed with our code. Spacing can be helpful here: - -```python -colors = [[213/255,94/255,0], # vermillion - [86/255,180/255,233/255], # sky blue - [230/255,159/255,0], # orange - [204/255,121/255,167/255]] # reddish purple -``` - ---- ->Code tells you how, comments tell you why. - -\- Jeff Atwood, Co-founder of StackOverflow - ---- - - -## `Technical Documentation` -## `Writing` - ---- - - -What is technical documentation writing? - ---- - - -Why is it important to write a good technical documentation? - ---- -Technical documents are necessary for reproducibility as they relay important information about your project to others. Writing technical documents is not easy but should not be overlooked. - -A well done technical document will communicate the goals of a project and in doing so, can generate interest in the project. - ---- -GitHub outlines several pieces of information to include: -1. What the project does -2. Why the project is useful -3. How users can get started with the project -4. Where users can get help with the project -5. Who maintains and contributes to the project -
- -This is just part of the story and we'll add more to this in the coming slides. - ---- -##### README -- Technical documentation writing is typically found in a `README.md` file. -- If the `README.md` file is placed in our repo's root, `doc` folder, or hidden in the `.github` directory, GitHub will place the contents of the `README.md` on the main repo page. -- The `README.md` file will be the first thing visitors see when they come to the project page so it's important to make it as appealing as possible. - ---- -##### Examples -Let's walk through some good examples of `README.md` files: -- [Create Go App CLI](https://github.com/create-go-app/cli#readme) -- [Human Activity Recognition](https://github.com/ma-shamshiri/Human-Activity-Recognition#readme) -- [Markdownify](https://github.com/amitmerchant1990/electron-markdownify#readme) -- [More!](https://github.com/matiassingers/awesome-readme) - ---- - - -What did you like about these README files? - -What similarities can you see? - ---- -##### What should be included? -1. Name of the project -2. What the project does -3. The project's usages -4. How to get started -5. Where to find help -6. Who contributes - ---- -##### 1. Name of the Project -- The name of your project should be unambiguous. - ---- -##### 2. What the project does -- This should be a description of the project. -- Provide context to the project and any reference links. -- Include features or background information -- *Can be titled "Description"* - ---- -##### 3. The project's usages -- This should include how the project can be used. -- Provide examples using the code along with the expected output of said code. -- It should be a smaller example. Longer examples can be linked to. -- *Can be titled "Usages"* - ---- -##### 4. How to get started -- This is the installation guide. -- Think of your particular audience and how much detail you might need to include. -- Add a requirements section if there are specific dependencies or needs to run in a particular programming language. -- *Can be titled "Installation"* - ---- -##### 5. Where to find help -- Direct people on where to find help if they need. -- This could be the issues page on GitHub, a forum, or an email address. -- *Can be titled "Support"* - ---- -##### 6. Who contributes -- This should outline how others can contribute to your project and what your requirements are for accepting contributions. -- *Can be titled "Contributing"* - ---- -##### Additional Additions -- Visuals: Visuals can grab people's attention, but they can also be helpful for showcasing what the code does. Include screenshots or GIFs that demonstrate your project. -- Badges: Badges provide metadata such as issue tracking, test results and downloads. [Shields.io](https://shields.io/) provides this service and you can also look at their [GitHub](https://github.com/badges/shields) for more information. -- Acknowledgements: Include the authors or anyone that helped with the project. - ---- -##### Markdown -- As noted by the extension, `README.md` files are usually written in markdown, thus using markdown syntax for styling. -- [GitHub](https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) provides a good reference on how to write your README in markdown. - ---- -##### Headings -```markdown -# Largest Heading -## Second Largest Heading -### Third Largest Heading -``` -![w:1000 center](./pics/04_headings.png) - ---- -##### Text Styling -```markdown -bold -*italic* -~~strikethrough~~ -this is a *nested* example -*bold and italic* -``` -![w:1000 center](./pics/04_text_styling.png) - ---- -##### Quoting -```markdown -> Block quote some text -``` -![w:1000 center](./pics/04_block_quote.png) - ---- -##### Unordered Lists -```markdown -- this is an unordered list -- second item - - nested - - second nest -``` -![w:1000 center](./pics/04_unordered.png) - ---- -##### Ordered Lists -```markdown -1. This is an ordered list -2. This is the second item - - with some additional information -3. This is the third -``` -![W:1000 center](./pics/04_ordered.png) - ---- -##### Codeblock -Wrap your code in ``` to create a codeblock. - -![W:1000 center](./pics/04_code_block.png) - ---- -##### Links -```markdown -[Rachael's GitHub](https://github.com/rachaellam) -``` -![W:1000 center](./pics/04_link.png) - ---- -##### Images -```markdown -![w:1000 center](./pics/.png) -``` -![w:500 center](./pics/04_bobs_burgers_louise.gif) -As we see, images can also be GIFs. We can also play around with the size and alignment. - ---- - - -## `Folder Structure` - ---- - - -What is folder structure and why is important? - ---- -A good folder structure is important for reproducibility because it easily allows for others to navigate and implement our projects. If someone references a file that is self contained, they know they won't have to change the file path to gain access. - -For example, what is the difference between these two paths: - -1. `"/Users/rachaellam/Documents/all-projects/this-project/data/"` - -2. `"this-project/data/"` - ---- -Folder structure can vary based on the project but a basic one to follow is... -- /inputs - - Everything that will not be edited including raw data and references -- /outputs - - Everything that was created during the project and your results -- /scripts - - All code that was written for the project - ---- -[Wilson et. al](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005510#sec009) also outline a file structure that is similar... -- /doc - - All text documents including documentation or references -- /data - - All raw data and metadata -- /results - - Files generated during the analysis including generated data or cleaned data - - Results can be further divided into subdirectories that contain intermediate files and finished files -- /src - - All code that was written for the project - ---- -References - -Reproducibility: -- [Reproducibility and Research Integrity](https://doi.org/10.1080/08989621.2016.1257387) -- [Reproducibility, Replicability, and Reliability](https://doi.org/10.1162/99608f92.dbfce7f9) - ---- -Commenting: -- [Elena Kosourova](https://towardsdatascience.com/the-art-of-writing-efficient-code-comments-692213ed71b1) -- [Ellen Spertus](https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/) - ---- -Technical Documentation Writing: -- [GitHub README](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes) -- [GitHub Markdown](https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) -- [KyuWoo Choi](https://www.freecodecamp.org/news/what-i-learned-from-an-old-github-project-that-won-3-000-stars-in-a-week-628349a5ee14/) -- [Make a README](https://www.makeareadme.com/) -- [Matias Singers](https://github.com/matiassingers/awesome-readme) - ---- -Folder Structure: -- [Rohan Alexander](https://www.tellingstorieswithdata.com/reproducible-workflows.html) -- [Wilson et. al](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005510#sec009) diff --git a/03_instructional_team/markdown_slides/git_as_story.md b/03_instructional_team/markdown_slides/git_as_story.md new file mode 100644 index 0000000..4255e73 --- /dev/null +++ b/03_instructional_team/markdown_slides/git_as_story.md @@ -0,0 +1,387 @@ +--- +marp: true +theme: dsi_certificates_theme +style: | + section { + font-family: Inter, -apple-system, BlinkMacSystemFont, 'Helvetica Neue', sans-serif; + } +_class: invert +paginate: true +--- + +# 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. Write a message: "What changed and why?" +3. Create a known good state + +Now you have a reliable history to fall back on. + +![width:600px](./images/git_commits_linear.svg) + +--- + +## 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. + +![width:600px](./images/git_commits_linear.svg) + +--- + +## 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 + +![width:600px](./images/git_commits_linear.svg) + +--- + +## 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.** + +![width:600px](./images/git_commits_branch_experiments.svg) + +--- + +## 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.** + +![width:600px](./images/git_commits_branch_bugfix.svg) + +--- + +## 🌳 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. + +![width:600px](./images/git_braches_with_tags.svg) + +--- + +## 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. 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 + +**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. **🌳 Branches** – Explore ideas in parallel +3. **🀝 Merges** – Bring ideas together coherently by comparing *differences* + +--- + +## Review: The Story So Far + +**The Journey:** +1. Started with messy file copies (`report_final_v3.xlsx`) +2. Built a system to take snapshots (**commit**) +3. Added ability to view history (**log**) and time travel (**checkout**) +4. Created parallel timelines for experiments (**branch**) +5. Marked important moments (**tag**) +6. Enabled collaboration by sharing complete copies (**clone/fork**) +7. Protected integrity with digital signatures (**hashes**) +8. Combined work from different branches (**merge**) +9. Organized changes before saving (**staging/add**) + +--- + +## 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/03_instructional_team/markdown_slides/images/git_braches_with_tags.svg b/03_instructional_team/markdown_slides/images/git_braches_with_tags.svg new file mode 100644 index 0000000..4220e22 --- /dev/null +++ b/03_instructional_team/markdown_slides/images/git_braches_with_tags.svg @@ -0,0 +1 @@ +v1v2v3v4v5v6v1v2v3v4v5v6mainbugfixtestmain \ No newline at end of file diff --git a/03_instructional_team/markdown_slides/images/git_commits_branch.svg b/03_instructional_team/markdown_slides/images/git_commits_branch.svg new file mode 100644 index 0000000..844352e --- /dev/null +++ b/03_instructional_team/markdown_slides/images/git_commits_branch.svg @@ -0,0 +1 @@ +v1v2v3v4v5 \ No newline at end of file diff --git a/03_instructional_team/markdown_slides/images/git_commits_branch_bugfix.svg b/03_instructional_team/markdown_slides/images/git_commits_branch_bugfix.svg new file mode 100644 index 0000000..cb8385a --- /dev/null +++ b/03_instructional_team/markdown_slides/images/git_commits_branch_bugfix.svg @@ -0,0 +1 @@ +v1v2v3v4v5v6 \ No newline at end of file diff --git a/03_instructional_team/markdown_slides/images/git_commits_branch_experiments.svg b/03_instructional_team/markdown_slides/images/git_commits_branch_experiments.svg new file mode 100644 index 0000000..2e4b93f --- /dev/null +++ b/03_instructional_team/markdown_slides/images/git_commits_branch_experiments.svg @@ -0,0 +1 @@ +v1v2v3v4v5v6 \ No newline at end of file diff --git a/03_instructional_team/markdown_slides/images/git_commits_linear.svg b/03_instructional_team/markdown_slides/images/git_commits_linear.svg new file mode 100644 index 0000000..db3ab20 --- /dev/null +++ b/03_instructional_team/markdown_slides/images/git_commits_linear.svg @@ -0,0 +1 @@ +v1v2v3 \ No newline at end of file diff --git a/03_instructional_team/markdown_slides/images/images_source.pptx b/03_instructional_team/markdown_slides/images/images_source.pptx new file mode 100644 index 0000000..5b448e5 Binary files /dev/null and b/03_instructional_team/markdown_slides/images/images_source.pptx differ diff --git a/03_instructional_team/markdown_slides/pics/02_cvcs.png b/03_instructional_team/markdown_slides/pics/02_cvcs.png deleted file mode 100644 index 78aedb8..0000000 Binary files a/03_instructional_team/markdown_slides/pics/02_cvcs.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/02_dvcs.png b/03_instructional_team/markdown_slides/pics/02_dvcs.png deleted file mode 100644 index 02d18fa..0000000 Binary files a/03_instructional_team/markdown_slides/pics/02_dvcs.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/02_git_data.png b/03_instructional_team/markdown_slides/pics/02_git_data.png deleted file mode 100644 index 716f6bd..0000000 Binary files a/03_instructional_team/markdown_slides/pics/02_git_data.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/02_lvc.png b/03_instructional_team/markdown_slides/pics/02_lvc.png deleted file mode 100644 index 98bff71..0000000 Binary files a/03_instructional_team/markdown_slides/pics/02_lvc.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_blobs.png b/03_instructional_team/markdown_slides/pics/03_blobs.png deleted file mode 100644 index 39cafdd..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_blobs.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_creating_repo_1.png b/03_instructional_team/markdown_slides/pics/03_creating_repo_1.png deleted file mode 100644 index f0eb874..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_creating_repo_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_creating_repo_2.png b/03_instructional_team/markdown_slides/pics/03_creating_repo_2.png deleted file mode 100644 index f024603..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_creating_repo_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_creating_repo_3.png b/03_instructional_team/markdown_slides/pics/03_creating_repo_3.png deleted file mode 100644 index 0d4c9cd..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_creating_repo_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_developer.png b/03_instructional_team/markdown_slides/pics/03_developer.png deleted file mode 100644 index 1a89e90..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_developer.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_git_ignore_small.png b/03_instructional_team/markdown_slides/pics/03_git_ignore_small.png deleted file mode 100644 index c2a549f..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_git_ignore_small.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_github.png b/03_instructional_team/markdown_slides/pics/03_github.png deleted file mode 100644 index f81aa24..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_github.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_master.png b/03_instructional_team/markdown_slides/pics/03_master.png deleted file mode 100644 index e3bb2d6..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_master.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_personal_auth.png b/03_instructional_team/markdown_slides/pics/03_personal_auth.png deleted file mode 100644 index 801b852..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_personal_auth.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_settings.png b/03_instructional_team/markdown_slides/pics/03_settings.png deleted file mode 100644 index 288009d..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_settings.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_testing.png b/03_instructional_team/markdown_slides/pics/03_testing.png deleted file mode 100644 index 764c23f..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_testing.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_testing_commit.png b/03_instructional_team/markdown_slides/pics/03_testing_commit.png deleted file mode 100644 index eeaac5f..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_testing_commit.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_testing_head.png b/03_instructional_team/markdown_slides/pics/03_testing_head.png deleted file mode 100644 index 0483b49..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_testing_head.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow.png b/03_instructional_team/markdown_slides/pics/03_workflow.png deleted file mode 100644 index b1c7019..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow_1.png b/03_instructional_team/markdown_slides/pics/03_workflow_1.png deleted file mode 100644 index 80d647b..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow_2.png b/03_instructional_team/markdown_slides/pics/03_workflow_2.png deleted file mode 100644 index 971e846..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow_3.png b/03_instructional_team/markdown_slides/pics/03_workflow_3.png deleted file mode 100644 index 45bea59..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow_4.png b/03_instructional_team/markdown_slides/pics/03_workflow_4.png deleted file mode 100644 index 7ed0d9f..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow_4.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow_5.png b/03_instructional_team/markdown_slides/pics/03_workflow_5.png deleted file mode 100644 index 8d48f61..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow_5.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/03_workflow_6.png b/03_instructional_team/markdown_slides/pics/03_workflow_6.png deleted file mode 100644 index 60f7401..0000000 Binary files a/03_instructional_team/markdown_slides/pics/03_workflow_6.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_block_quote.png b/03_instructional_team/markdown_slides/pics/04_block_quote.png deleted file mode 100644 index 97c511e..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_block_quote.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_bobs_burgers_louise.gif b/03_instructional_team/markdown_slides/pics/04_bobs_burgers_louise.gif deleted file mode 100644 index b296ab5..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_bobs_burgers_louise.gif and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_code_block.png b/03_instructional_team/markdown_slides/pics/04_code_block.png deleted file mode 100644 index 6c947bd..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_code_block.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_colab_workflow.png b/03_instructional_team/markdown_slides/pics/04_colab_workflow.png deleted file mode 100644 index b0fbc16..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_colab_workflow.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_colab_workflow_2.png b/03_instructional_team/markdown_slides/pics/04_colab_workflow_2.png deleted file mode 100644 index 828e0dc..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_colab_workflow_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_delete_branch.png b/03_instructional_team/markdown_slides/pics/04_delete_branch.png deleted file mode 100644 index d854504..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_delete_branch.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_difference.png b/03_instructional_team/markdown_slides/pics/04_difference.png deleted file mode 100644 index b647ec5..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_difference.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_fork_1.png b/03_instructional_team/markdown_slides/pics/04_fork_1.png deleted file mode 100644 index 9be2b76..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_fork_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_git_collabs_1.png b/03_instructional_team/markdown_slides/pics/04_git_collabs_1.png deleted file mode 100644 index 642c286..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_git_collabs_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_git_collabs_2.png b/03_instructional_team/markdown_slides/pics/04_git_collabs_2.png deleted file mode 100644 index 321b917..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_git_collabs_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_git_collabs_3.png b/03_instructional_team/markdown_slides/pics/04_git_collabs_3.png deleted file mode 100644 index 5682905..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_git_collabs_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_headings.png b/03_instructional_team/markdown_slides/pics/04_headings.png deleted file mode 100644 index b786874..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_headings.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_issues_1.png b/03_instructional_team/markdown_slides/pics/04_issues_1.png deleted file mode 100644 index 759e63f..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_issues_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_issues_2.png b/03_instructional_team/markdown_slides/pics/04_issues_2.png deleted file mode 100644 index 1d3b27d..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_issues_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_issues_3.png b/03_instructional_team/markdown_slides/pics/04_issues_3.png deleted file mode 100644 index e2aa744..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_issues_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_link.png b/03_instructional_team/markdown_slides/pics/04_link.png deleted file mode 100644 index f61afe4..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_link.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_merge.png b/03_instructional_team/markdown_slides/pics/04_merge.png deleted file mode 100644 index c618560..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_merge.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_merge_conflicts.png b/03_instructional_team/markdown_slides/pics/04_merge_conflicts.png deleted file mode 100644 index 20f4c00..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_merge_conflicts.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_ordered.png b/03_instructional_team/markdown_slides/pics/04_ordered.png deleted file mode 100644 index 5b50a4d..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_ordered.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_1.png b/03_instructional_team/markdown_slides/pics/04_pull_request_1.png deleted file mode 100644 index 41f1703..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_2.png b/03_instructional_team/markdown_slides/pics/04_pull_request_2.png deleted file mode 100644 index 0dfc699..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_3.png b/03_instructional_team/markdown_slides/pics/04_pull_request_3.png deleted file mode 100644 index e77d8ef..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_4.png b/03_instructional_team/markdown_slides/pics/04_pull_request_4.png deleted file mode 100644 index 3ade7d8..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_4.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_5.png b/03_instructional_team/markdown_slides/pics/04_pull_request_5.png deleted file mode 100644 index ced584e..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_5.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_1.png b/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_1.png deleted file mode 100644 index a18d33c..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_2.png b/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_2.png deleted file mode 100644 index 55bc398..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_3.png b/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_3.png deleted file mode 100644 index a1f5cd6..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_4.png b/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_4.png deleted file mode 100644 index 1672265..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_pull_request_merge_conflict_4.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_text_styling.png b/03_instructional_team/markdown_slides/pics/04_text_styling.png deleted file mode 100644 index 0fe65a4..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_text_styling.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_topics_1.png b/03_instructional_team/markdown_slides/pics/04_topics_1.png deleted file mode 100644 index 730e3e9..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_topics_1.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_topics_2.png b/03_instructional_team/markdown_slides/pics/04_topics_2.png deleted file mode 100644 index 18ef375..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_topics_2.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_topics_3.png b/03_instructional_team/markdown_slides/pics/04_topics_3.png deleted file mode 100644 index 316f586..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_topics_3.png and /dev/null differ diff --git a/03_instructional_team/markdown_slides/pics/04_unordered.png b/03_instructional_team/markdown_slides/pics/04_unordered.png deleted file mode 100644 index 3ec7a26..0000000 Binary files a/03_instructional_team/markdown_slides/pics/04_unordered.png and /dev/null differ diff --git a/README.md b/README.md index 0079b85..3fd99a6 100644 --- a/README.md +++ b/README.md @@ -44,19 +44,19 @@ Participants should review the [Assignment Submission Guide](https://github.com/ ## Contacts -**Questions can be submitted to the #dc2-help channel on Slack** +**Questions can be submitted to the #cohort-8-help channel on Slack** * Technical Facilitator: - * **Daniel Razavi** - daniel.razavi@utoronto.ca + * **Simeon Wong** + me@simeon.dev * Learning Support Staff: * **Dmytro Bonislavskyi** dmytro.bonislavskyi@gmail.com - * **Anjali Desphande** - anju_shrivastava@yahoo.com - * **Sergii Khomych** - svkhomich1@gmail.com + * **Moniz Chan** + chanmoniz526@gmail.com + * **Xindi Zhang** + xindi.zhang@mail.utoronto.ca Β  ## Delivery of the Learning Module