← All topics
🧰 Core Tech Refresher

Git Workflow

Rebase vs merge, cherry-pick, when each is appropriate.

Merge preserves full history including the branch structure (a merge commit with two parents); rebase replays your commits on top of the target branch, producing linear history but rewriting commit hashes — never rebase commits that have already been pushed and could be in someone else's history.

Cherry-pick applies one specific commit from elsewhere onto your current branch — useful for hotfixes that need to land on both a release branch and main.

A reasonable position to state out loud: feature branches rebase onto main before opening a PR (clean, linear history for review), and the merge into main itself uses a merge commit or squash-merge depending on team convention.

Flashcards (2)

What's the practical risk of rebasing commits that have already been pushed/shared?
tap to reveal answer
Rebase rewrites commit hashes; anyone who already pulled the old commits will get diverged history and confusing conflicts when they next pull — the rule of thumb is never rebase what's already public/shared.
What is git cherry-pick for?
tap to reveal answer
Applying one specific commit from another branch onto your current branch — typical use: a hotfix commit needs to land on both a release branch and main without merging everything else.