Version Control, Git, and GitHub Basics

Class: CSCE-313

Notes:

Remote Collaboration & GitHub

Question 1

On GitHub, what is the primary purpose of a "Fork" compared to a "Clone"?

Options:

• A fork creates a personal copy of a repository on your GitHub account; a clone downloads a repository to your computer.
• Cloning is for open-source; forking is for private projects.
• A fork is used to delete a repository.
• A fork is local; a clone is on the server.

Overall explanation:

• A fork creates a copy of someone else’s repository under your own GitHub account.
• A clone downloads a repository from GitHub (or another Git server) to your local computer.

Question 2

In a professional setting, why is it standard practice to use a Pull Request rather than pushing code directly to the main branch? List at least two benefits this provides to a software engineering team. **See … for more information.

Answer:

1. A Pull Request allows teammates to review the code before it is merged into the main branch.
2. The main branch is usually the production-ready version of the project.

• Using Pull Requests instead of pushing directly to main:
  • Improves code quality
  • Protects project stability
  • Encourages collaboration
  • Provides documented change history

Question 3

Why is it standard practice to run git pull before you begin a new session of coding on a shared repository, and what is actually happening "under the hood"?

Options:

• It performs a git fetch to download remote data, followed by a git merge to synchronize only the branch you are currently working on.
• It scans every branch in the remote repository and automatically updates all of your local branches to match the server exactly.
• It creates a cloud backup of your working directory to ensure no local work is lost if your computer crashes.
• It forces a "hard reset" of your local environment, deleting any uncommitted work to ensure you start from a clean state.

Overall explanation:

• In a shared repository, other team members may have pushed new commits since your last session.
• Running git pull ensures:
  • Your local branch is up to date
  • You are working on the latest version
  • You avoid unnecessary merge conflicts later
  • You don’t accidentally overwrite someone else’s work
• If you don't pull first, you might:
  1. Write code on an outdated version
  2. Try to push
  3. Get rejected
  4. Have to resolve bigger, more complicated conflicts

Question 4

What is "Upstream" in the context of a forked repository?

Options:

• Your personal copy of the project on GitHub
• The original repository from which you created your fork
• The hidden .git folder
• Your local folder on your laptop

Overall explanation:

• When you fork a repository on GitHub, you create your own copy under your account.
• In this setup:
  • Origin → usually refers to your fork
  • Upstream → refers to the original repository you forked from
• You use the upstream remote to:
  • Pull in updates from the original project
  • Keep your fork up to date
  • Avoid falling behind the main project

Question 5

When using rsync for backups, which flag preserves permissions, ownership, and timestamps?

Options:

• -v (verbose)
• -a (archive)
• -r (recursive)
• -z (compress)

Overall explanation:

• The -a flag in rsync stands for archive mode.
  • It preserves:
    • File permissions
    • Ownership
    • Timestamps
    • Symbolic links
    • Recursive directory copying
• -v (verbose)
  • Only prints detailed output. Does not preserve metadata.
• -r (recursive)
  • Copies directories recursively, but does NOT preserve ownership, permissions, or timestamps.
• -z (compress)
  • Compresses data during transfer (useful over networks), but does not preserve metadata.

Conceptual Foundations

Question 6

Explain the fundamental difference between a Centralized Version Control System (like SVN) and a Distributed Version Control System (like Git). In your answer, describe what happens when a developer "clones" a repository in Git versus "checking out" a file in SVN. Answer it in a short essay. **See … for more information.

Answer:
The main difference between a Centralized Version Control System like SVN and a Distributed Version Control System like Git is the location of the project history.

With SVN, there's basically one central server that holds the entire repository. Developers connect to that server to get files and to commit changes. "checking out" a project in SVN means you're downloading the current version of the files, but the full history still mainly lives on the server. If the server goes down you are stuck in your local version. You also need to be connected to it to do any action.

With Git, it works differently. When you "clone" a repository, you're not just downloading the latest version of the files, you're copying the entire repository, including its full commit history, onto your own machine. That means your local copy is basically a complete version of the project including the project history, which also means you can do any git action like commit, branch, etc. without having to connect to the cloud.

Question 7

In Version Control, what is the primary purpose of a "Commit"?

Options:

• To create a permanent snapshot of the project at a specific point in time with a descriptive message.
• To upload your code to a website like GitHub.
• To delete old versions of files to keep the folder clean.
• To save a file so you don't lose progress if the power goes out.

Overall explanation:

• A commit in version control (like Git) records the state of your project at a specific moment.
• When you commit:
  • Git saves a snapshot of your changes
  • It stores them in the repository history
  • You attach a message explaining what you changed
• This allows you to:
  • Track progress over time
  • Revert back to earlier versions if something breaks
  • Understand why changes were made

Question 8

Beyond being a software tool, Git represents a "Distributed" philosophy of version control. Which of the following best describes the relationship between Git and a service like GitHub within this philosophy?

Options:

• Git is the engine that manages local snapshots of a project's entire history, while GitHub acts as a "Remote" peer that facilitates collaboration and centralized backup.
• Git and GitHub are identical in function, but GitHub adds a graphical user interface to Git's underlying database.
• Git is a temporary local buffer for code, whereas GitHub is the only place where the permanent "Master" record of the project's history exists.
• GitHub is the primary version control logic, and Git is simply the interface used to "unlock" GitHub’s features on a local machine.

Overall explanation:

• Git and GitHub are related, but they are not the same thing.
• Git is the actual version control system. It:
  • Tracks changes
  • Stores the entire commit history locally
  • Lets you create branches, commits, merges, etc.
  • Works completely offline
  • It is the core technology — the “engine.”
• GitHub, on the other hand, is a web-based hosting service built around Git. It:
  • Stores remote copies of repositories
  • Allows collaboration through Pull Requests
  • Provides issue tracking and project management tools
  • Acts as a shared remote repository for teams

Question 9

What does the "Snapshots, not Differences" philosophy in Git mean? See … for more information.Links to an external site.

Options:

• Git stores a miniature filesystem of what all your files look like at that moment, rather than just a list of changed lines.
• Git requires you to use images instead of text files.
• Git automatically takes a screenshot of your desktop every time you save.
• Git only takes a "picture" of the code and cannot actually run it.

Overall explanation:

• The "Snapshots, not Differences" philosophy means that every time you make a commit, Git saves the state of your entire project as it exists at that moment.
• Instead of just storing:
  • "Line 5 changed from X to Y"
• Git stores:
  • "Here’s what the whole project looks like right now."
• You can think of each commit as a snapshot of your project’s file system. If a file hasn’t changed, Git doesn’t duplicate it — it just references the previous version to save space.
• This design makes Git:
  • Very fast
  • Reliable
  • Easy to branch and merge

Question 10

Which of these best describes the "Three Trees" or "Three States" of Git?

Options:

• Working Directory, Staging Area (Index), and Repository (HEAD)
• Local, Remote, and Server
• HTML, CSS, and JavaScript
• Root, Branch, and Leaf

Overall explanation:

• The “Three Trees” (or Three States) in Git describe the three main places your files exist during version control:
  1. Working Directory
     • This is your actual project folder on your computer.
     • It contains the files you are actively editing.
  2. Staging Area (Index)
     • This is where you prepare changes before committing.
     • When you run git add, you move changes from the Working Directory to the Staging Area.
  3. Repository (HEAD)
     • This is the committed history stored in Git.
     • When you run git commit, Git takes what’s in the Staging Area and saves it permanently in the repository.

Local Git Operations

Question 11

Which area in Git acts as a technical 'buffer' where changes are grouped before they are permanently recorded?

Options:

• The HEAD
• The Working Directory
• The Git Directory (Repository)
• The Index (Staging Area)

Overall explanation:

• The Staging Area (also called the Index) is the technical “buffer” in Git.
• It sits between:
  • Your Working Directory (where you edit files)
  • The Repository (where commits are permanently stored)
• When you run: git add <file>
  • You move changes into the Staging Area.
  • They are not committed yet — they are just prepared.
• Then when you run: git commit
  • Git takes exactly what is in the Staging Area and records it as a permanent snapshot.

Question 12

When a developer runs the command git commit --amend to fix a typo in their most recent commit message, what is technically happening within the Git database?

Options:

• Git creates a brand-new commit object with a different SHA-1 hash, while the original commit remains in the database as an unreachable ("orphaned") object.
• Git creates a "patch" file that is appended to the original commit, which Git then uses to mask the typo during display.
• Git opens the existing commit object and overwrites the metadata fields (like the message and timestamp) while keeping the same commit ID.
• Git automatically deletes the original commit from the disk and replaces it with a new one to ensure the log remains a single linear string.

Overall explanation:

• In Git, commits are immutable. That means once a commit is created, it cannot be edited or modified directly.
• When you run: git commit --amend
• Git does not edit the existing commit. Instead:
  1. It creates a new commit object
  2. That new commit has:
     • The updated message (or changes)
     • A new timestamp
     • A new SHA-1 hash (because the content changed)
  3. The branch pointer (like main) is updated to point to this new commit
  4. The original commit still exists in the Git database but becomes unreachable (unless referenced elsewhere)
• Because the commit contents changed (even just the message), the hash must change too.

Question 13

What does it mean when a Git repository is in a "Detached HEAD" state? **See … for more information.**Links to an external site.

Options:

• The repository has been corrupted, and the .git folder is missing.
• The connection to the remote server has been lost.
• All files in the working directory have been deleted.
• The HEAD pointer is referencing a specific commit hash directly rather than a named branch.

Overall explanation:

• Normally in Git, HEAD points to a branch, and that branch points to the latest commit.
• Example (normal state):
  • HEAD → main → latest commit
• But in a Detached HEAD state, HEAD is pointing directly to a specific commit instead of a branch:
  • HEAD → commit 1a2b3c4
• This usually happens when you:
  • git checkout <commit-hash>
• Instead of checking out a branch like main.

Question 14

You have modified 5 files, but only want to include 2 of them in your next commit. How do you achieve this?

Options:

• Git does not allow partial commits; you must commit all changes.
• Run git add specifically for the 2 files you want, then git commit
• Delete the other 3 files, commit, then restore them.
• Run git commit -a

Overall explanation:

• Git allows you to control exactly what goes into a commit using the Staging Area.
• If you modified 5 files but only want 2 in the next commit, you simply stage only those 2 files:
  • git add file1 file2
  • git commit -m "Commit message"
• Only the files that were added to the Staging Area will be included in the commit. The other 3 modified files will remain unstaged and uncommitted.
• This is one of Git’s powerful features — you can create clean, focused commits instead of committing everything at once.

Question 15

What is the purpose of the .gitignore file?

Options:

• To specify intentionally untracked files (like build artifacts or API keys) that Git should ignore.
• To list the people who are not allowed to contribute to the project.
• To encrypt sensitive files before pushing them to GitHub.
• To hide specific files from your teammate's view.

Overall explanation:

• The .gitignore file tells Git which files or folders it should not track.
• This is useful for things like:
  • Build artifacts (e.g., dist/, bin/)
  • Dependency folders (e.g., node_modules/)
  • System files (e.g., .DS_Store)
  • Environment files containing secrets (e.g., .env with API keys)

Branching and Merging

Question 16

You have a feature branch that has fallen behind the main branch. You can integrate the new changes from main using either "git merge" or "git rebase".

1. Describe the difference in the resulting commit history for both methods.
2. Why might a project lead prefer the "rebase" workflow over "merge"?

Answer:
If you use git merge, Git creates a new merge commit that ties your feature branch together with main. The history keeps all the original branch structure, so it kind of looks like a tree with branches splitting and joining, and you can see which commits belonged to which branch.

If you use git rebase, Git basically moves your feature branch on top of the latest main commits. It rewrites all commits as if you started your work from the newest version of main. The history ends up looking clean and linear so you lose the branch commit structure and it looks like everything happened in a straight line.

Question 17

When a merge conflict occurs, Git marks the file with specific symbols. Identify what <<<<<<< HEAD, =======, and >>>>>>> [branch-name] signify.

Bonus: After you manually edit the file to resolve the conflict, what is the next Git command you must run to tell Git the conflict is resolved?

Answer:
When a merge conflict happens, Git can't automatically decide which changes to keep, so it marks the file with conflict indicators.

Here’s what the symbols mean:

<<<<<<< HEAD

• This marks the start of your current branch’s changes (the branch you were on when you ran merge). HEAD refers to your current branch.

=======

• This is the separator between the two conflicting sections. Everything above it is your branch’s version, and everything below it is the incoming branch’s version.

>>>>>>> branch-name

• This marks the end of the conflicting section, and shows the name of the branch you were trying to merge in. The code between ======= and this line is the other branch’s changes.

Visually:

<<<<<<< HEAD
your version
=======
their version
>>>>>>> feature-branch

• You manually edit the file to:
  • Remove the conflict markers
  • Keep the correct code (or combine both versions)

Bonus Answer

• After fixing the file, you must run:

  git add <file-name>
  

  • This tells Git:
  • “I’ve resolved the conflict.”

• If you were in the middle of a merge, you then complete it with:

  git commit
  

  • (Usually Git auto-prepares the merge commit message.)

Question 18

Why is it "best practice" to develop new features on a separate branch rather than the main branch?

Options:

• It keeps the main branch stable and allows for independent experimentation.
• Git only allows one person to work on the main branch at a time.
• Branches are required to use the git push command.
• It makes the code run faster.

Overall explanation:

• Developing new features on a separate branch is best practice because it protects the main branch.
• The main branch is usually the stable, production-ready version of the project. If you work directly on it and something breaks, you risk affecting everyone else.
• Using a separate branch lets you:
  • Experiment safely
  • Make mistakes without harming the stable version
  • Test features before merging
  • Open Pull Requests for review
• Once everything works correctly, you merge it back into main.

Question 19

A developer uses git rebase -i HEAD~3 and changes pick to squash for the two most recent commits. What happens?

Options:

• The branch is split into three separate pieces.
• The commits are reordered chronologically.
• The three commits are combined into a single commit with a unified message.
• The two most recent commits are deleted.

Overall explanation:

• You’re telling Git:
  • “Let me interactively edit the last 3 commits.”
• If you change pick to squash for the two most recent commits, Git will:
  • Keep the oldest of the three commits as the base
  • Combine the other two into it
  • Merge all their changes together
  • Let you edit and unify the commit message
• So instead of:
  • Commit A
  • Commit B
  • Commit C
• You end up with:
  • One single combined commit (A+B+C)
• This is often done to clean up messy commit history before pushing.

Question 20

What command would you use to see a list of all branches (both local and remote)?

Options:

• git status
• git branch
• git branch -a
• git branch -v

Overall explanation:

• The command: git branch -a
  • Shows all branches, including:
    • Local branches
    • Remote-tracking branches (like origin/main)
  • The -a stands for “all.”
• git status
  • Shows the current branch and file changes, not all branches.
• git branch
  • Shows only local branches.
• git branch -v
  • Shows local branches with their latest commit message, but not remote branches.