Git & Version Control Remote Repositories and Collaboration Syllabus

Since August 2021, why can you no longer use your account password for Git operations over HTTPS on GitHub?

GitHub removed password authentication for Git operations. Over HTTPS you must use a Personal Access Token (PAT) in place of the password; SSH keys are the alternative.

Which command generates a new modern (Ed25519) SSH key pair, and what two files does it produce?

ssh-keygen -t ed25519 -C "your_email@example.com". It produces a private key (e.g., ~/.ssh/id_ed25519) and a public key (~/.ssh/id_ed25519.pub).

When adding an SSH key to GitHub, which of the two key files do you upload, and why never the other?

You upload the PUBLIC key (the .pub file). The private key must NEVER be shared or uploaded; it stays on your machine and proves your identity.

What is the purpose of the ssh-agent, and how do you add your key to it?

ssh-agent holds your decrypted private key in memory so you don't retype the passphrase each time. Start it (eval "$(ssh-agent -s)") then add the key with ssh-add ~/.ssh/id_ed25519.

How do you test that your SSH key is correctly configured with GitHub?

Run ssh -T git@github.com. A successful setup returns a message like "Hi username! You've successfully authenticated, but GitHub does not provide shell access."

What is a Personal Access Token (PAT), and what is it used in place of?

A PAT is a generated secret string that acts as a credential for HTTPS Git operations and API access, used in place of your account password. It can be scoped to specific permissions and given an expiration date.

What is the difference between a classic PAT and a fine-grained PAT on GitHub?

A classic PAT grants broad scopes across all repositories you can access. A fine-grained PAT can be restricted to specific repositories and specific granular permissions, and always has a required expiration, making it more secure by least privilege.

When cloning over HTTPS and prompted for a username and password, what should you enter for the password now?

Enter your Personal Access Token (PAT) as the password, not your account password. The username is your GitHub username.

What is a Git credential manager (credential helper), and what problem does it solve?

A credential helper securely stores and retrieves your HTTPS credentials (username/PAT) so you don't re-enter them on every push/pull. Examples: Git Credential Manager (GCM), osxkeychain on macOS, cache, and store.

Compare the "cache" and "store" credential helpers in Git.

cache keeps credentials in memory for a limited time (default 15 minutes, configurable via --timeout) and never writes to disk. store saves credentials permanently in a plaintext file (~/.git-credentials), which is convenient but insecure.

How do you configure Git to cache HTTPS credentials in memory for one hour?

git config --global credential.helper 'cache --timeout=3600' (the timeout is given in seconds).

What is "forking" a repository, and how does it differ from cloning?

Forking creates a server-side copy of someone else's repository under your own account (on the host, e.g., GitHub). Cloning downloads a repository to your local machine. Typically you fork on GitHub, then clone your fork locally.

In the standard fork-based contribution workflow, what do the remotes "origin" and "upstream" conventionally refer to?

origin refers to YOUR fork (the copy under your account that you can push to). upstream refers to the ORIGINAL repository you forked from (which you usually cannot push to, only fetch from).

List the sequence of commands to sync your fork's main branch with the upstream repository.

git fetch upstream; git checkout main; git merge upstream/main (or git rebase upstream/main); then git push origin main to update your fork on the host.

Why do you add an "upstream" remote after cloning your fork, and how?

Because your fork does not automatically receive new commits from the original project. You add it so you can pull the latest changes: git remote add upstream <original-repo-url>.

Outline the typical end-to-end workflow for contributing to an open-source project via a fork.

1) Fork the repo on the host. 2) Clone your fork and add upstream. 3) Create a feature branch. 4) Make commits. 5) Push the branch to your fork (origin). 6) Open a Pull Request against the upstream repo. 7) Respond to review feedback. 8) Maintainer merges.

Why is it best practice to create a dedicated feature branch (rather than working on main) when contributing to open source?

It isolates your changes, keeps main clean and in sync with upstream, lets you work on multiple contributions simultaneously, and makes the pull request focused and easy to review or revise.

What is a Pull Request (PR), also called a Merge Request in GitLab?

A PR is a request to merge the commits from one branch (usually a feature/fork branch) into another branch (usually the project's main branch). It is a collaboration surface for review, discussion, automated checks, and approval before code is integrated.

Name the key anatomical parts of a Pull Request.

Title and description (summary of changes), source/head branch and target/base branch, the commit list, the file diff (changes), conversation/comments thread, review approvals/requested changes, linked issues, and status checks (CI/tests).

What do the "base" branch and the "compare" (head) branch mean when opening a Pull Request?

The base branch is the branch you want to merge INTO (the target, e.g., main). The compare/head branch is the one containing your new commits (the source, e.g., your feature branch).

After pushing a new branch to your fork, what are the two common ways to open a Pull Request?

Use the GitHub web UI (a "Compare & pull request" banner appears, or click New pull request and select base/compare branches), or use the GitHub CLI: gh pr create.

What is a "draft" pull request and when would you use it?

A draft PR signals that the work is in progress and not yet ready to merge; it cannot be merged until marked ready for review. Use it to get early feedback or run CI while still working.

What is the purpose of the code review process on a pull request?

To catch bugs, ensure code quality and consistency, verify the change meets requirements, share knowledge across the team, and maintain a shared standard before code is merged into the main branch.

On GitHub, what are the three review outcomes a reviewer can submit?

Comment (general feedback, no explicit approval or rejection), Approve (sign off that the changes are good to merge), and Request changes (block the merge until specified issues are addressed).

Compare the three merge methods offered by GitHub: merge commit, squash and merge, and rebase and merge.

Merge commit: keeps every commit and adds a merge commit, preserving full history. Squash and merge: combines all PR commits into a single new commit on the base, giving a clean linear history. Rebase and merge: replays each PR commit individually onto the base with no merge commit, keeping commits but linear.

Which merge method produces a single combined commit, and which preserves each individual commit while keeping history linear?

Squash and merge produces a single combined commit. Rebase and merge preserves each individual commit while keeping the history linear (no merge commit).

What causes conflicts in a pull request, and generally how are they resolved?

A PR conflict occurs when the base branch has changed the same lines that the PR branch modified, so Git cannot auto-merge. Resolve by merging or rebasing the latest base branch into the PR branch, editing the conflict markers (<<<<<<<, =======, >>>>>>>), committing the resolution, and pushing again.

When resolving a merge conflict, what do the markers <<<<<<<, =======, and >>>>>>> delimit?

<<<<<<< HEAD marks the start of your current branch's version, ======= separates the two versions, and >>>>>>> <branch> marks the end of the incoming branch's version. You edit to keep the desired content and delete all three markers.

What is the recommended format of a conventional Git commit message (subject and body)?

A short imperative subject line (about 50 characters, capitalized, no trailing period), a blank line, then a wrapped body (~72 chars/line) explaining WHAT and WHY (not how). Example subject: "Add user login validation."

In the Conventional Commits specification, what is the message structure and what do types like feat and fix signify?

Structure: type(optional scope): description, e.g., feat(auth): add OAuth login. feat = a new feature (bumps a MINOR version), fix = a bug fix (bumps a PATCH version). A ! or "BREAKING CHANGE:" footer denotes a breaking change (MAJOR). Other types: docs, style, refactor, test, chore.

State three etiquette guidelines for giving good code review feedback.

Be respectful and critique the code, not the person; explain the WHY behind requested changes and suggest concrete improvements; distinguish blocking issues from optional nits (e.g., prefix minor suggestions with "nit:"); acknowledge good work; and ask questions rather than making demands.