🌿 Version Control Strategy Language
6 exercise sets. Master the vocabulary for Git branching debates, code review, history forensics, and release management.
Git Branching Strategy Vocabulary
Trunk-based development, GitFlow, branch naming conventions, long-lived vs. short-lived branches.
Merge vs. Rebase Vocabulary
Merge, rebase, squash, fast-forward, three-way merge — vocabulary for discussing Git history strategies.
Pull Request Review Language
Opening, reviewing, requesting changes, approving, merging PRs — vocabulary for code review conversations.
Git History & Forensics Vocabulary
Bisect, blame, cherry-pick, reflog, amend — vocabulary for navigating and repairing Git history.
Monorepo Strategy Vocabulary
Monorepo vs. polyrepo trade-offs, Nx, Bazel, affected commands, code ownership vocabulary.
Release Tags & Versioning Vocabulary
Semantic versioning, annotated vs. lightweight tags, tag signing, release branch naming.
Frequently Asked Questions
What's the difference between branching strategies like Gitflow and GitHub Flow in these exercises?
The Gitflow model uses distinct branches for features, releases, and hotfixes, offering structured release management. GitHub Flow emphasizes a simpler flow with short-lived feature branches merging directly into `main` after code review – both are simulated to test your understanding of their workflows and impact on collaborative development.
I'm struggling to understand 'conflict resolution' in the context of merging conflicting changes. How does that apply here?
In these exercises, conflict resolution involves identifying differing code versions when two branches are merged. You'll practice using tools like `git mergetool` or manually editing files to resolve discrepancies, ensuring a consistent codebase after integration – it's rarely just 'accepting one change.'
What is the purpose of a 'three-way merge' and why is it important for understanding these exercises?
A three-way merge utilizes the common ancestor (the commit both branches diverged from) to reconcile differences. This method provides a detailed view of what was changed on each branch, allowing you to accurately apply changes while minimizing data loss during integration – crucial for complex scenarios.
How do I use `git cherry-pick` effectively within a scenario where I only need specific commits from another branch?
`git cherry-pick` allows you to select and apply individual commit messages from one branch onto your current branch. However, be aware that it creates duplicate commits – the exercise will likely test if you understand how this impacts history and potential conflicts when combined with other operations.
What's a 'rebase' and why might I use it instead of merging in these exercises?
Rebasing moves your branch's history to point directly to the latest commit on another branch, creating a cleaner linear history. While merging creates a merge commit, rebasing alters the commit IDs, which can be useful for practice but requires careful consideration to avoid disrupting collaboration.
Can I use 'tagging' in these exercises and what is its purpose?
Tags are immutable references to specific commits, often used to mark releases or significant milestones. The exercises might require you to create tags for specific versions of your code, demonstrating how tagging integrates with branching strategies.
What's the significance of using a 'feature branch' in the context of these coding exercises?
A feature branch is a dedicated branch created for developing new features or bug fixes, isolated from the main codebase. The exercise will likely involve creating and merging feature branches to simulate a typical development workflow and test your understanding of branching isolation.
How does 'squashing commits' impact the version control history?
Squashing combines multiple small, related commits into a single commit, simplifying the project's history. The exercises might challenge you to understand when and how to squash commits effectively, often for cleaner release management or reducing unnecessary merge commits.
What is 'git reset --hard' and why should I be cautious about using it during these exercises?
'git reset --hard' forcefully resets your branch to a specified commit, discarding any subsequent changes. It's a powerful command but dangerous if you haven't backed up your work – the exercise will likely test your understanding of its destructive potential and how to avoid accidental data loss.
How do I effectively use `git stash` to temporarily save changes before switching branches?
'git stash' allows you to temporarily shelve uncommitted changes without creating a new branch. The exercises may require you to use `stash` to manage competing changes between branches, demonstrating its utility for workflow interruptions and rapid context switching.