1 of 29

Intro to Version Control

Fall 2025

2 of 29

Readings for Next Week

  • Read the following sections from the Git Wikipedia article
    • "History"
    • "Characteristics"
  • As we work through the next two labs, the following sections of the Pro Git book will provide context and some useful conceptual models:
    • Chapter 2, sections 1, 2, 3, 4, 5
    • Chapter 3, sections 1, 2, 3, 6

3 of 29

What is ssh?

“SSH, or Secure Shell, is a cryptographic network protocol that enables secure access to a remote machine over the internet.”��Terms:

  • Cryptographic network protocol?
  • Secure access?
  • Remote machine over the internet?

​

4 of 29

What is “the cloud”?

  • Bunch of servers that store stuff.
  • Send stuff, receive stuff, listen, delete, “compute”
  • Can “scale it” – dynamically

5 of 29

Intro to git

  • What is git?
  • What experience do you have using git (if any)?
  • Good Reference: https://git-scm.com/book/en/v2

6 of 29

Today: Local Workflow

7 of 29

Intro to git

  • What is git?
  • What experience do you have using git (if any)?
  • Good Reference: https://git-scm.com/book/en/v2

8 of 29

Git v. GitHub

  • What is git?
    • Git is a free and open source version control system
  • What is GitHub?
    • GitHub is a company that provides cloud-based hosting services for managing your git repositories.
  • What are some of the services GitHub provides?
    • Issue trackers, third-party integrations (e.g., CI/CD tools), website hosting, branch protection, tools for managing teams and organizations, tools / notifications to identify security issues (i.e., problematic node / python dependencies, accidentally checking in passwords and API keys, and more)

8

9 of 29

How to Learn Git

The best way to learn git is to practice using git while working on a collaborative software project (like this class)!

There are also many great references you can draw from, including:

  • The Git SCM Book (SCM stands for source code management)
  • Video tutorials (e.g., Google “youtube rebase” or “google revert”)
  • Conceptual diagrams (Google them) – which explain how various commands / workflows work (like today’s assigned video).

9

10 of 29

Simple Git Workflow: Solo Project (Today)

  1. Fork the class repository (“fork” is the same as clone, but refers to creating a copy of a remote branch on GitHub). csci338 workspace → your workspace
  2. Clone an existing GitHub repository
  3. Create a new branch
  4. Edit / update / delete some files
  5. Stage your changes to git
  6. Commit your changes to git
  7. Push (upload) your changes back to the original repository.

10

11 of 29

Solo Project Workflow (Simple)

11

Scenario: you want to make changes to a code repository that

lives on another computer / server (e.g., on GitHub)

12 of 29

Solo Project Workflow (Simple)

12

First, issue the git clone command. This downloads the code files (left) as well as a hidden .git folder of tracking files (middle), to your working directory (pwd)

13 of 29

Solo Project Workflow (Simple)

13

Note: In addition to the local repo, git has a concept of a “staging area.” �Files are ignored by git until they are staged.

14 of 29

Solo Project Workflow (Simple)

14

Use the git status command to tell you which of your files have been changed since the last commit (the current version of your codebase).

15 of 29

Solo Project Workflow (Simple)

15

To stage your changes (tell git which files you want to commit), use the git add command. You can add individual files (by path), or all changed files (use dot).

16 of 29

Solo Project Workflow (Simple)

16

When you’re ready to commit your changes (add them to the codebase), use the git commit command. All commits require a message describing the commit.

17 of 29

Solo Project Workflow (Simple)

17

Note that the added files are no longer highlighted, as they are now part of the code repository (changes are stored within the .git system files)

18 of 29

Solo Project Workflow (Simple)

18

To publish your changes back to the shared codebase (remote server), �use the git push command.

19 of 29

Simple Git Workflow: Solo Project Commands

19

clone

Copies a remote repository (e.g., one hosted on a GitHub server) onto your local machine (within your current directory).

status

Tells you which of the files in your current directory are different from the latest commit in the repo.

checkout -b �branchname

Creates and checks out a new branch (pointer) – to track subsequent changes that you don’t want on the previous branch.

add

Stages the specified files to be committed

log

Shows you the commit history

commit

Saves a snapshot of your staged files at the moment the commit is issued. Each commit represents the state of your code at a particular moment in time.

push

Uploads your commits to a remote repo

pull

Downloads changes from a remote repo to your local repo

20 of 29

Common Mistakes People Make

20

21 of 29

1. Avoid nested git repos

​

csci338

└── app

├── .git

├── .gitignore

├── README.md

└── class-exercises-spring2025

├── .git

├── .gitignore

├── README.md

└── src

21

BAD: reps are nested (class-exercises-spring2025 is a child of app).

​

Should app also be tracking the code in class-exercises-spring2025?

22 of 29

1. Side by Side Repos OK!

​

csci338

├── app

│ ├── .git

│ ├── .gitignore

│ ├── README.md

│ └── src

└── class-exercises-spring2025

├── .git

├── .gitignore

└── README.md

22

OK: Separate repos are not nested (in sibling directories)

23 of 29

2. Don’t forget to add a commit message

If you issue the git commit command without a commit message, it may open a vim editor and ask you to add your commit message via vim.

If this happens, you can either:

  1. Add a message to the top of the text file using the vim commands we practiced on Tuesday.
  2. Exit vim (press Escape Key and then :q!) and try again with a message:
    • git commit -m 'Thoughtful commit message'

23

24 of 29

3. Don’t check in API keys, passwords, or dependencies

Use the .gitignore file to exclude files you don’t want under version control.

Files you typically want to exclude from version control:

  • Third party modules / packages
  • Protected information (e.g., passwords, API keys, etc.),
  • Personal config files (e.g., .vscode settings file)
  • System files (e.g., .DS_Store, etc.) that aren’t part of the shared codebase.
  • Compiled files (e.g., *.pyc, *.class files)
  • Virtual environment files

24

25 of 29

Intro to Public / Private Keys

For GitHub Authentication

26 of 29

Authentication: What is a public/private key pair?

  • Relies on asymmetric cryptography
  • Every public key has exactly one matching private key.
  • If Sarah wants to send a secret message to Walter, she can encode it using Walter’s public key. Walter (and only Walter) can only decode it using his matching private key.
  • Public keys are shared. Like saying, “if you want to send me an encrypted message, here’s the way to do it!”
  • Private keys are never shared – only you should be able to decrypt messages sent to you.

26

Source: https://www.ssh.com/academy/ssh/public-key-authentication

27 of 29

Public/private keys on Servers

  • Many servers do not allow password authentication via ssh because it’s less secure than public private keys
    • If your password gets compromised, ANYONE can access the server – Sarah brought down several servers at the University of Florida this way!
  • Instead…
    • Copy your public key to a special text file within your home directory on the server, and (b) ensure that your private key is in the .ssh folder of your home directory. It’s like saying:
    • Assumption: “If the user had the permission to copy their public key here, they must be authorized.”
    • Save your private key (super secret) on your local computer – usually within the .ssh directory in your home directory.

27

28 of 29

Outline

  1. Discussion of the Readings
  2. Git v. GitHub
  3. Git Concepts
  4. Lab 2

28

29 of 29

Lab 2