Cherry-Pick Is Cross-Database INSERT…SELECT
Sometimes you don’t want to merge an entire branch. You want one specific commit from another branch — one fix, one change, one feature — without bringing everything else along for the ride.
DBAs do this all the time. You’ve got a stored procedure fix in dev, but the full dev branch has 20 other changes that aren’t ready for production. You don’t deploy the whole branch. You extract just the fix you need.
In SQL Server, that’s INSERT...SELECT across databases — pulling specific rows from one database into another. In git, that’s cherry-pick.
How Cherry-Pick Works
Cherry-pick copies a single commit from one branch and applies it to your current branch. The original commit stays where it is. You get a new commit on your branch with the same changes but a different SHA.
|
1 2 3 4 5 6 7 8 |
# You're on main and need a hotfix from dev git switch main # Find the commit you want git log --oneline dev # Cherry-pick that specific commit git cherry-pick a1b2c3d |
That’s it. The changes from commit a1b2c3d are now applied to main as a new commit. Everything else on the dev branch stays on the dev branch.
The DBA Analogy
|
1 2 3 4 5 6 7 8 9 |
/* Cherry-pick is this — targeted cross-database extraction */ INSERT INTO [Production].[dbo].[StoredProcedures] ([SchemaName], [ProcName], [Definition]) SELECT [SchemaName], [ProcName], [Definition] FROM [Development].[dbo].[StoredProcedures] WHERE [ProcName] = N'usp_CalculateShipping'; |
You’re not copying the entire Development database. You’re selecting exactly the rows (commits) you need and inserting them into Production (your current branch).
Cherry-Picking Multiple Commits
Need more than one commit? You can cherry-pick a range:
|
1 2 3 4 5 |
# Cherry-pick three specific commits git cherry-pick a1b2c3d b2c3d4e c3d4e5f # Cherry-pick a range (exclusive start, inclusive end) git cherry-pick a1b2c3d..c3d4e5f |
When Cherry-Pick Gets Complicated
Cherry-pick can hit conflicts — just like merge conflicts. If the commit you’re picking depends on changes that don’t exist in your current branch, git can’t apply it cleanly.
|
1 2 |
CONFLICT (content): Merge conflict in src/procedures/usp_CalculateShipping.sql error: could not apply a1b2c3d... Fix shipping calculation |
When this happens:
|
1 2 3 4 5 6 7 8 9 |
# See what's conflicted git status # Fix the conflicts in your editor, then: git add . git cherry-pick --continue # Or abort if it's too messy git cherry-pick --abort |
This is the same problem you’d hit trying to INSERT...SELECT a row that has a foreign key dependency on a row that doesn’t exist in the target database. The data doesn’t stand alone — it has dependencies.
The Risks of Cherry-Picking
Cherry-pick is useful, but it creates a specific problem: duplicate changes.
When you cherry-pick a commit, the original still exists on the source branch. Later, when you merge that branch, git might see the same change applied twice. Modern git is usually smart enough to handle this, but it can cause confusing conflicts.
It’s like inserting a row via INSERT...SELECT and then later doing a full database restore from the source. Now you have the same data from two different paths, and you need to reconcile duplicates.
Best practice: Cherry-pick for hotfixes and emergencies. For planned work, prefer merging the whole branch when it’s ready.
The Hotfix Workflow
Here’s the most common cherry-pick scenario for DBAs working with SSDT or other database projects:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# Critical bug found in production # The fix is already committed on the dev branch # 1. Switch to main (or your release branch) git switch main # 2. Find the fix commit git log --oneline dev --grep="Fix shipping" # 3. Cherry-pick it git cherry-pick a1b2c3d # 4. Tag the hotfix git tag -a hotfix-shipping-20260506 -m "Emergency fix for shipping calc" # 5. Push git push origin main --tags |
Notice how we combined cherry-pick (Post 8) with tags (Post 7)? The concepts build on each other.
Cherry-Pick vs. Merge vs. Rebase
Merge: Combine entire branch histories. Use for planned integration of completed features.
Rebase: Replay your commits on a new base. Use for keeping your branch up to date.
Cherry-pick: Copy a specific commit. Use for emergency hotfixes or extracting one change from a larger body of work.
Each one is a different type of data movement, just like INSERT...SELECT, database restore, and log shipping are all different ways to move data between SQL Server instances — each appropriate for different scenarios.
Try This Yourself
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# Create two branches git switch -c branch-a echo "fix A" > fix.sql && git add . && git commit -m "Important fix" echo "feature A" > feature.sql && git add . && git commit -m "Unfinished feature" # Switch to a different branch git switch main # Cherry-pick just the fix (first commit on branch-a) git log --oneline branch-a git cherry-pick <SHA-of-important-fix> # Verify: fix.sql is here, feature.sql is not ls |
The One Sentence to Remember
Cherry-pick is INSERT...SELECT across branches — extract exactly the commits you need without merging everything else.
Previously: Tags Are Database Snapshots You Can Name
Next up: Git for SSDT Projects: Where It All Comes Together