In a large project with multiple developers, effective Git management is crucial for streamlined collaboration. A well-organized Git process ensures developers can work concurrently on various features, minimizing conflicts and enhancing productivity. Proper version control allows for easy tracking of changes, facilitates seamless integration of new features, and ensures a stable production environment. Additionally, efficient Git practices are essential for promptly addressing and fixing ad-hoc issues and bugs in the production environment, ultimately contributing to the overall success and reliability of the big project.

How do we at Cheerio manage git?

Branching Strategy

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

2. 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.

3. 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.