main              -> versi berikutnya, aktif dikembangkan
release/2.8       -> versi stabil terbaru
release/2.7       -> versi enterprise customer lama
release/2.6       -> versi regulated customer dengan SLA extended support

Commit mana yang harus di-cherry-pick?

Bad hotfix = local patch success + version coverage failure

Same patch intent ≠ same commit object

# tag yang mengandung commit fix, jika fix sudah ada
 git tag --contains <fix-sha>

# branch yang mengandung commit fix
 git branch -r --contains <fix-sha>

# apakah branch release tertentu sudah punya patch yang equivalent?
 git cherry -v origin/release/2.7 origin/main

contains commit    -> object identity masuk history
contains behavior  -> patch equivalent atau manual fix mungkin sudah ada

# Search berdasarkan code text
 git log -S 'oldBuggyCondition' --all -- path/to/file
 git log -G 'regexThatMatchesFix' --all -- path/to/file

# Compare patch equivalence
 git cherry -v origin/release/2.7 origin/main

# Compare file state
 git diff origin/release/2.7..origin/main -- path/to/file

Pilih origin patch berdasarkan risk containment, bukan ego history cleanliness.

[ ] Commit atomic?
[ ] Tidak mencampur refactor besar + bug fix?
[ ] Test terkait ikut dalam commit atau tersedia di branch target?
[ ] Tidak bergantung pada commit lain yang belum ada?
[ ] Tidak memakai API/config/schema baru yang absen di target?
[ ] Tidak mengubah generated files tanpa generator compatible?
[ ] Tidak membawa feature behavior yang tidak boleh ada di release lama?
[ ] Tidak mengandung migration irreversible?
[ ] Tidak mengubah public contract tanpa release note?
[ ] Aman untuk customer-specific customization?

# Lihat patch intent
 git show --stat --patch <fix-sha>

# Terapkan sebagian secara manual atau patch-scoped
 git checkout release/2.7
 git checkout <fix-sha>^ -- path/to/test
 # atau edit manual sesuai branch lama

Commit A: refactor validation API
Commit B: add helper validateStatus()
Commit C: fix production bug using validateStatus()

compile fails: validateStatus() missing

# Lihat file yang disentuh commit fix
 git show --name-only --oneline <fix-sha>

# Lihat commit sebelumnya pada file terkait
 git log --oneline --decorate -- path/to/file

# Lihat patch secara lengkap
 git show --patch <fix-sha>

# Cari fungsi/symbol yang diperkenalkan
 git log -S 'validateStatus' --all -- path/to/file

# Lihat range sejak branch release berpisah dari main
 git merge-base origin/main origin/release/2.7
 git log --oneline $(git merge-base origin/main origin/release/2.7)..origin/main -- path/to/file

minimal code change + maximal behavioral confidence

fix bug + modernize module + rename variables + update dependencies + change tests massively

Jika perubahan tidak diperlukan untuk memperbaiki bug, jangan masukkan ke backport.

# 1. Update local refs
 git fetch origin --prune --tags

# 2. Buat branch backport dari target release
 git switch -c backport/2.7/JIRA-123-payment-timeout origin/release/2.7

# 3. Cherry-pick dengan metadata original
 git cherry-pick -x <fix-sha>

# 4. Jika conflict, resolve sebagai domain decision
 git status
 git diff
 git diff --staged
 git add <resolved-files>
 git cherry-pick --continue

# 5. Jalankan test target branch
 ./gradlew test
 ./gradlew integrationTest

# 6. Verifikasi patch boundary
 git show --stat --patch HEAD

# 7. Push branch PR
 git push -u origin backport/2.7/JIRA-123-payment-timeout

(cherry picked from commit <sha>)

# 1. Ambil hotfix commit dari release branch
 git fetch origin --prune --tags
 git log --oneline origin/release/2.7 -n 20

# 2. Buat branch forward-port ke main
 git switch -c forward-port/JIRA-123-payment-timeout origin/main

# 3. Cherry-pick hotfix
 git cherry-pick -x <hotfix-sha-on-release-2.7>

# 4. Resolve conflict jika main sudah berubah
 git status
 git diff
 git add <resolved-files>
 git cherry-pick --continue

# 5. Verifikasi tidak duplicate dengan fix lain di main
 git log --oneline -S 'core fix symbol' origin/main..HEAD
 git range-diff origin/main...HEAD@{1} origin/main...HEAD || true

# 6. Test main-level behavior
 ./gradlew test

# 7. PR ke main
 git push -u origin forward-port/JIRA-123-payment-timeout

Hotfix tanpa forward-port = future regression seed

Branch sudah aman karena bug tidak ada / code path tidak ada / fix already present.

Tidak sempat dicek.

H27   -> release/2.7 hotfix object
H27'  -> main forward-port object
H27'' -> release/2.8 backport object

fix(payment): prevent timeout retry storm

Production release 2.7 can repeatedly retry timeout responses when the gateway
returns HTTP 504 after authorization capture. The retry loop increases queue
pressure and can duplicate downstream reconciliation work.

This patch makes timeout retry idempotent for the affected transaction state.
It intentionally avoids the newer RetryPolicy abstraction from main because
release/2.7 does not contain the dependency chain safely.

Backport-of: abc1234 fix(payment): prevent timeout retry storm
Incident: INC-2026-0712
Issue: PAY-1842
Release-line: 2.7.x
Risk: low; behavior scoped to timeout retry path
Test: PaymentTimeoutRetryTest

(cherry picked from commit abc1234...)

 git cherry-pick -x <fix-sha>
 # conflict
 git status
 git diff
 git diff --ours -- path/to/file
 git diff --theirs -- path/to/file
 git diff --base -- path/to/file

Commit M3 = refactor + bug fix

1. Buat commit baru di main yang mengekstrak minimal bug fix jika masih memungkinkan.
2. Manual backport hanya behavior fix ke release branch.
3. Catat bahwa release branch menerima equivalent patch, bukan identical patch.

minimize disclosure + maximize coverage + preserve evidence

[ ] Identifikasi semua supported release lines.
[ ] Tentukan apakah private security branch diperlukan.
[ ] Hindari commit message yang membocorkan exploit detail sebelum disclosure.
[ ] Patch main dan release branches sesuai disclosure plan.
[ ] Tag release secara immutable.
[ ] Simpan evidence test dan approval.
[ ] Update advisory/release note saat waktu disclosure tiba.
[ ] Rotate secret jika kasusnya leak, jangan hanya rewrite history.

Public commit message can be discreet.
Private incident record must be complete.

main:        V205__add_retry_policy.sql
release/2.7: V144__fix_payment_index.sql

Create branch-specific migration with target line numbering.
Document semantic relation to original fix.

[ ] Default value branch lama sama?
[ ] Environment variable tersedia di deployment target?
[ ] Secret/config store sudah diupdate?
[ ] Rollback config aman?
[ ] Monitoring menangkap perubahan behavior?
[ ] Config name tidak berubah antara main dan release lama?

CI green on main does not prove backport safety.

main has fix A
release/2.7 has manual fix B
later release/2.7 merges/cherry-picks A
now behavior changes again or code becomes redundant

# Apakah patch dari main sudah equivalent dengan branch target?
 git cherry -v origin/release/2.7 origin/main

# Cari symbol atau text fix
 git log -S 'newGuardCondition' origin/release/2.7 -- path/to/file
 git log -S 'newGuardCondition' origin/main -- path/to/file

# Compare functional area
 git diff origin/release/2.7..origin/main -- path/to/file

Equivalent-to: <main-fix-sha>

## Backport Summary

Target release line: `release/2.7`
Original fix: `<sha>` / PR `#1234`
Incident/issue: `INC-...` / `JIRA-...`

## Why this release line is affected

- [ ] Code path exists in this branch
- [ ] Version is still supported
- [ ] Customer/environment affected

## Patch Strategy

- [ ] Clean cherry-pick
- [ ] Cherry-pick with conflict resolution
- [ ] Manual equivalent backport
- [ ] No-op with explanation

## Dependency Check

- [ ] No missing API dependency
- [ ] No schema dependency
- [ ] No config dependency
- [ ] No feature flag dependency
- [ ] No test harness dependency

## Verification

- [ ] Regression test added/updated
- [ ] Unit test green
- [ ] Integration test green
- [ ] Artifact smoke test green
- [ ] Release notes updated

## Notes

Explain any divergence from original patch.

hotfix/2.7/INC-1842-payment-timeout
backport/2.7/PAY-1842-payment-timeout
forward-port/main/INC-1842-payment-timeout

fix-bug
urgent
patch
my-hotfix
release-fix

 git switch release/2.7
 git pull --ff-only origin release/2.7
 git tag -a v2.7.15 -m "Release 2.7.15"
 git push origin v2.7.15

 git tag -s v2.7.15 -m "Release 2.7.15"
 git tag -v v2.7.15

A release tag is historical evidence, not a mutable pointer to “latest good”.

 git revert <bad-hotfix-sha>

Hotfix H27 merged to release/2.7
  -> forward-port to release/2.8? pending
  -> forward-port to main? pending
  -> release note? pending
  -> regression test on main? pending

needs-forward-port-main
needs-backport-2.8
needs-backport-2.7
backport-complete
no-op-documented

Patch compiles but bug still exists.

 git show --stat --patch <sha>
 git branch -r --contains <sha>
 git log --oneline --decorate --ancestry-path <base>..<sha>

Release branch changes behavior beyond bug fix.

Bug fixed in old production branch, returns in next major/minor release.

Branch doesn't contain SHA, but bug is already fixed manually.

Different machines build different artifacts from same version.

mkdir git-hotfix-lab
cd git-hotfix-lab
git init

mkdir src
echo 'retry=3' > src/payment.conf
git add .
git commit -m 'init payment config'

git switch -c release/1.0

git switch main
echo 'retry=3
idempotent=false' > src/payment.conf
git add .
git commit -m 'payment: add idempotency config'

echo 'retry=1
idempotent=true' > src/payment.conf
git add .
git commit -m 'fix(payment): prevent retry storm'

git switch -c backport/1.0/retry-storm release/1.0
git cherry-pick -x main

echo 'retry=1' > src/payment.conf
git add src/payment.conf
git cherry-pick --continue

git log --oneline --decorate --all --graph
git show --stat --patch HEAD

Backport can be semantically equivalent without being textually identical.

[ ] Incident/issue ID exists.
[ ] Affected version matrix complete.
[ ] Patch origin chosen intentionally.
[ ] Original commit inspected.
[ ] Dependency chain inspected.
[ ] Target branch is updated.
[ ] Branch name encodes target release line.

[ ] Use `cherry-pick -x` for direct cherry-pick.
[ ] Resolve conflict as domain decision.
[ ] Avoid unrelated refactor.
[ ] Keep patch minimal.
[ ] Add/adjust regression test.
[ ] Record divergence from original patch.

[ ] CI green on target branch.
[ ] Release owner reviewed.
[ ] Security/compliance reviewed if needed.
[ ] Release notes updated.
[ ] Forward-port/backport follow-up tracked.

[ ] New patch release tag created.
[ ] Artifact built from tag.
[ ] Runtime metadata includes version + SHA.
[ ] Deployment evidence recorded.
[ ] Matrix closed with status for each branch.

Invariant 1: Every hotfix has a version coverage matrix.
Invariant 2: Every release-first fix has explicit forward-port tracking.
Invariant 3: Every backport is verified on the target branch.
Invariant 4: Every public release fix creates a new release identity.
Invariant 5: Every manual equivalent patch records its original semantic source.
Invariant 6: No release tag is moved after publication.
Invariant 7: No conflict is resolved purely textually when domain behavior is at stake.