Examius
🌍 Git & Version Control · flashcards
Git & Version Control Remote Repositories and Collaboration Flashcards
51 question-and-answer cards covering Remote Repositories and Collaboration as it is examined in Git & Version Control. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.
24 sample cards from the Remote Repositories and Collaboration deck
Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.
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.
What this deck covers
The Remote Repositories and Collaboration deck follows the Git & Version Control Remote Repositories and Collaboration syllabus — 5 chapters and 20 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 10.2 cards per chapter.
Answers are written to be recallable, not just readable — averaging about 211 characters, which is long enough to carry the reasoning and short enough to say out loud.
A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.
Remote Repositories and Collaboration flashcards FAQ
How many Remote Repositories and Collaboration flashcards are in this Git & Version Control deck?
51 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.
Are these Git & Version Control flashcards free?
Yes. The preview here is free to read with no signup, and the full 51-card deck is free inside the Examius app.
What do the Remote Repositories and Collaboration cards cover?
They follow the Git & Version Control Remote Repositories and Collaboration syllabus — 5 chapters and 20 topics — so the questions track what is actually examinable.
How should I use these flashcards?
Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.