Git Workflow for Big Teams: Simplified Guide to Managing Large Projects with Multiple Developers and Ad-Hoc Fixes

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?

How do we at Cheerio manage git?

Branching Strategy

Main Branch: Represents the production code. Code from staging is merged into main only after thorough testing and approval.

Staging Branch: staging represents the release branch. No new features are merged into this branch after the completion of the sprint. Only bug fixes and ad-hoc fixes are allowed.

Development Branch: dev serves as the main development branch. Feature branches are created from dev for ongoing development. Developers regularly merge the latest changes from main into their feature branches to avoid conflicts later.

Feature Development Workflow

When working on new features, developers start by creating branches from the 'dev' branch, naming them consistently like 'feature/feature-name.' To keep things smooth, developers regularly update their branches with the latest changes from 'dev,' preventing big conflicts.

Next, developers request to merge their feature branches back into 'dev' through pull requests. Before the merge, there's a check to ensure the code meets quality standards through a code review. Additionally, an automated process (Continuous Integration or CI) tests the code to make sure it works correctly. This process ensures that everyone's work integrates well together and maintains high-quality code.

Ad-Hoc Fixes and Bug Fixes

For ad-hoc fixes and production bug fixes, developers create hotfix branches from staging.

After fixing, changes are merged back into both main , staging and dev branches.

Sprint Releases

Once all the features are developed and the sprint is complete, a PR is raised from dev to staging. After reviewing merge the branch.

No further changes are pushed to staging except ad-hoc and bug fixes. Perform rigorous testing on the staging branch.

At the end of the sprint, merge the release branch into main for the release. Tag the merge commit with a version number.

Tags and documentations

Use semantic versioning to indicate the significance of changes. Increment major versions for backwards-incompatible changes, minor versions for new features, and patch versions for bug fixes. We use GitHub tags to mark commits with a version number.

Maintain a changelog that includes details about each release and clearly document the changes introduced in each version.

More things to keep in mind

Pull requests serve as a crucial checkpoint, allowing for comprehensive code reviews and automated testing through Continuous Integration. This approach not only upholds code quality standards but also facilitates effective collaboration among developers.

Using clear names and checking each other's work before putting it all together makes sure the code is good. Automated testing also helps check if everything works right.

Git Workflow for Big Teams: Simplified Guide to Managing Large Projects with Multiple Developers and Ad-Hoc Fixes

Comments (1)

More from this blog

How to increase storage of AWS EC2 server without deleting data

How do I handle sprints at Cheerioai.com as CTO?

Get webhooks directly on your localhost

Embrace Feedback for Professional Growth

How do we at Cheerio manage git?

Branching Strategy

Feature Development Workflow

Ad-Hoc Fixes and Bug Fixes

Sprint Releases

Tags and documentations

More things to keep in mind

Command Palette

Comments (1)

More from this blog

How do we at Cheerio manage git?

Branching Strategy

Feature Development Workflow

Ad-Hoc Fixes and Bug Fixes

Sprint Releases

Tags and documentations

More things to keep in mind