1 of 26

Version Control and Collaborative Workflows

Fall 2024

1

2 of 26

Reminder of what we did Last Week

  1. Discussed the version control readings
  2. Practiced a “simple” GitHub workflow with the class-exercises-fall2024 repo that involved:
    1. Forking and cloning it
    2. Creating a new branch
    3. Created a new folder (lab02)
    4. Adding a new file (ContainsPair.java)
    5. Pushing your branch to GitHub
    6. Making a pull request

3 of 26

Today’s Agenda

  1. Discussion of Ch 16
  2. Collaborative Workflows
  3. Activity

3

4 of 26

Today’s Agenda

  1. Discussion of Ch 16
  2. Collaborative Workflows
  3. Activity

4

5 of 26

Discussion of Chapter 16: Quick Recap

  • Why is code history important?
  • What is distributed version control?
  • What is git?

6 of 26

Today’s Agenda

  1. Discussion of Ch 16
  2. Collaborative Workflows
  3. Activity

6

7 of 26

Collaborative git workflows

When you start collaborating with other people, the workflow gets more complex. A few other concepts to introduce here:

  1. Branching
  2. Rebasing v. Merging
  3. Pull Requests
  4. Handling conflicts

7

8 of 26

Branching

Branches allow you to create new features (often experimental) without altering the main branch (where the authoritative version of the code lives).

Important ideas:

8

Source: https://www.nobledesktop.com/learn/git/git-branches

  • Think of branches as “works in progress”
  • You can easily create new branches and switch between them
  • Use “pull requests” to incorporate branches into the codebase

Main

9 of 26

Branch Commands Using git

9

git checkout -b my-new-branch

Creates a new branch

git branch

Tells you which branch you’re on

git checkout main

Switches you from your current branch to the main branch

git checkout my-new-branch

Switches you from your current branch to the my-new-branch branch

git branch -d my-new-branch

Deletes my-new-branch from your local repo

git merge my-new-branch

Merges changes from my-new-branch into the current branch.

git rebase my-new-branch

Rebases changes from my-new-branch into the current branch.

10 of 26

Understanding Code History

11 of 26

Basic Git History

  • A is the first commit you ever made
  • C is your most recent commit

12 of 26

Feature Branch

You decide you want to make a new login page for your app. You make a new branch called Feature-Branch and make 3 commits Z, Y, and X that collectively have code for the login page.

What should happen next?

13 of 26

Fast-Forward

Since no one else has made any changes to the repo since you made your branch, you can simply fast-forward:

  • Head is updated to point to Feature-Branch

14 of 26

Feature-Branch When Main is Ahead

New scenario: Since you made your branch, new code (commit D) has been incorporated into the repo that your code doesn’t have.

What should happen next?

15 of 26

Option 1: Merge Commit

A merge commit creates two parent pointers:

  • One to your updates (X)
  • One to the most recent updates from your collaborator (D)

16 of 26

Option 2: Rebasing

  • Can we fast-forward?
  • Not immediately!
  • Why not?

17 of 26

Option 2: Rebasing

Rebasing involves actually making your code history look like you actually branched from D (your collaborator’s commit). In other words, you “rewrite history”. The steps:

  • Re-apply changes to create 3 new commits on top of D
  • Then, fast forward

18 of 26

One More Option: Squash

  • Squash branch into a single commit and rebase.

19 of 26

Conflicts

What happens if Commit D and Feature-Branch modify the same file?

  • Merge: conflicts are handled in Merge Commit
  • Rebase: conflicts are handled during the rebase process (e.g., Z’, Y’, and X’)

20 of 26

Trade-Offs

Merge Commits

  • Generally easier in practice
  • Back out an entire branch with a single commit
  • Preserves Full History�

Rebase

  • Maintains Linear History
  • Rewrites History

21 of 26

Class policy decision: rebasing instead of merging

22 of 26

Pull Requests

  • When you’re ready for the code on your branch to be reviewed, make a pull request on GitHub.
  • There, it will be reviewed, and when it’s ready, it will be incorporated into the codebase (via merge or rebase).

22

23 of 26

Handling Conflicts

  • Git conflicts can happen when two developers edit the same file on their (respective branch) and git can’t figure out how to reconcile the changes automatically (should I use Developer A’s changes or Developer B’s changes)?
  • Conflicts are a normal part of collaborating with other people, but can be minimized through solid communication and planning.

23

24 of 26

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.

24

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

25 of 26

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 . 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.

25

26 of 26

Activity