How to deal with hotfixes when using typical git flow #48437
Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
git branch, dev, release and hotfix workflows
Body
Hi there,
Our team is struggling to figure out a simple process for managing
dev
andmain
(prod) branches - specifically around hot fixes.dev
andmain
branchesCurrently this is how we've been working:
When
dev
is ready we rebase and merge ontomain
. Somain
would mirrordev
on every release.Creating hotfixes
We recently had a bug in
main
that needed an immediate fix. So we did the following:Basically we created a branch
hotfix-a
off of themain
branch, made the fix and then merged it (using rebase so we didn't have a merge commit) into bothmain
anddev
. This way both branches have the fix.However when we did this the commit hash on
dev
andmain
are different.main
commit hash is6c52..
anddev
commit hash is85b1...
.What this means is that
dev
andmain
have now diverged. What's the best way to deal with this if we want to maintain a linear commit history? Because I know we can mergedev
intomain
to realign them but we would prefer a linear commit history.Any ideas on best practices here?
Beta Was this translation helpful? Give feedback.
All reactions