---
title: "Comment by Shyam Mittal on \"Git Workflow for Big Teams: Simplified Guide to Managing Large Projects with Multiple Developers and Ad-Hoc Fixes\" | Hashnode"
description: "It’s elaborate and seems efficient. One scenario - say we have three features merged in dev and testing is done and it gets merged to staging. After bug fixing"
url: "https://hashnode.com/posts/git-workflow-for-big-teams-simplified/658c726f71077cb66cbf5212/comment/65d6bf96de715f184c7ab8cf"
---

[Discussion](https://hashnode.com/posts/git-workflow-for-big-teams-simplified/658c726f71077cb66cbf5212)

Comment [Git Workflow for Big Teams: Simplified Guide to Managing Large Projects with Multiple Developers and Ad-Hoc Fixes](https://hashnode.com/posts/git-workflow-for-big-teams-simplified/658c726f71077cb66cbf5212)

[Shyam Mittal](https://hashnode.com/@codekage01)

[Feb 22, 2024](https://hashnode.com/posts/git-workflow-for-big-teams-simplified/658c726f71077cb66cbf5212/comment/65d6bf96de715f184c7ab8cf)

It’s elaborate and seems efficient.

One scenario - say we have three features merged in dev and testing is done and it gets merged to staging. After bug fixing on staging we want to park feature 1 which was merged in start due to some issue from backend or business side and we want to park this feature from this release so now how fast can we park it with above strategy?