A practical Git workflow to verify whether feature commits are already included in a target branch—avoiding unnecessary cherry-picks and confusion in complex histories.

Cherry-pick-check-report.md

Cherry-Pick Check Report

I ran into a situation where I needed to verify whether a feature branch (J27910_fix) had already been included in a release branch (2616).

At first glance, the history looked messy — multiple merges, unrelated commits, and overlapping changes from other tickets. This made it unclear whether my work (tagged with J27910) had already been merged or if I needed to cherry-pick it manually.

Instead of guessing or risking duplicate changes, I decided to validate it properly using Git.

---

The Problem

The main question was:

Are there any J27910 commits in J27910_fix that are NOT yet in 2616?

This is a common issue in large repositories where:

• branches are frequently merged from main
• feature branches are not cleanly isolated
• commit history includes unrelated work

A simple git log A..B can easily mislead if the direction is wrong.

---

Approach

Step 1 — Verify the target branch

git branch -a | grep -i "BPO/2026"

Confirmed that origin/branches/BPO/2026/2616 exists.

---

Step 2 — Check for missing commits

git log origin/dev/SAW/J27910_fix \
  --not origin/branches/BPO/2026/2616 \
  --pretty=format:"%h | %ad | %s" \
  --date=iso \
  --grep="J27910"

Result: no output

This indicates that there are no J27910 commits missing from 2616.

---

Step 3 — Cross-check both sides

To avoid false assumptions, I listed commits on both branches.

# From J27910_fix
git log origin/dev/SAW/J27910_fix \
  --pretty=format:"%h | %ad | %s" --date=iso --grep="J27910"

# From 2616
git log origin/branches/BPO/2026/2616 \
  --pretty=format:"%h | %ad | %s" --date=iso --grep="J27910"

Result showed that all expected commits exist — and interestingly, 2616 contains two additional J27910 commits.

---

Step 4 — Validate commit presence

git branch -r --contains 684a01e3
git branch -r --contains 0db47255

Both commits are confirmed in:

• origin/branches/BPO/2026/2616
• origin/main

---

Final Result

No cherry-pick is required.

All J27910 commits from the feature branch are already included in 2616. In fact, the release branch is slightly ahead.

---

Key Insight

The confusion came from using the wrong comparison direction earlier.

In Git:

• A..B → what B has that A doesn’t
• --not → explicitly excludes commits already reachable

Using the wrong direction can completely flip your interpretation.

---

Alternative Approach (If Commits Were Missing)

If missing commits had been found, here are safe options:

Option 1 — Cherry-pick specific commits

Best when you only need selected changes.

git checkout branches/BPO/2026/2616
git cherry-pick <commit1> <commit2>

---

Option 2 — Cherry-pick a range

git cherry-pick <oldest>^..<latest>

Only works if commits are sequential.

---

Option 3 — Merge the branch

git merge origin/dev/SAW/J27910_fix

Safer when:

• the branch is clean
• you want all changes

---

Practical Takeaways

• Always verify direction when comparing branches
• Don’t rely on raw git log without filtering
• Use --grep when commits follow a ticket pattern
• Cross-check results — especially in repositories with heavy merges

---

Closing Note

Git can look confusing when history gets complex, but with the right commands, it becomes very predictable.

The key is not to trust assumptions — always verify using the graph and commit filters.