branching_stratergy.md

Git branching strategy for Django project

Git branching strategy for your Django project, with a focus on handling migration conflicts efficiently, with the primary goal to help maintain a well-organized and collaborative development process. Here's a recommended branching strategy for project 'zinfotrek' for Axind :

1. Main Branches:

   • master: This is the primary branch that always reflects the production-ready code. Only merge stable and tested code into this branch. Avoid direct commits to this branch.

   • staging: This is the primary branch that always reflects the staging-ready code. Only merge stable and tested code into this branch. Avoid direct commits to this branch. This branch is used to make sure every user stories works as expected and testing edge cases.

   • dev: This is the development branch where most of the active development takes place. All feature branches should be merged into this branch when they are ready for integration testing.

2. Feature Branches:

   • Create a feature branch for each new feature, bug fix, or task. Name them descriptively, e.g., feat/user-authentication or fix/payment-gateway.

   • Branch off dev when creating a new feature branch.

   • Once the feature is complete, create a pull request (PR) to merge it back into the dev branch. This allows for code review and testing by team members.

   • After the PR is approved and tested, merge it into dev. Ensure the feature branch is deleted after merging.

3. Migration Conflict Handling:

   • Create a separate branch for managing migrations, e.g., migration-management. This branch is dedicated to handling migration conflicts and database schema changes.

   • Developers working on migrations in the *common app should create their own feature branches off the migration-management branch.

   • If migration conflicts arise, address them by coordinating with other developers. Use Django's migration management commands to squash or resolve migration conflicts.

   • Regularly merge changes from the migration-management branch into dev to keep the database schema changes in sync with the rest of the codebase.

4. Release Branches:

   • Create release branches from the staging branch when you are preparing for a new release. Name them, e.g., release/1.0.0.

   • Only bug fixes and minor adjustments should be allowed in the release branch. No new features should be introduced.

   • Once the release is ready for deployment, merge it into master for production.

5. Hotfix Branches:

   • If critical issues are discovered in the production environment, create hotfix branches off the master branch.

   • Once the hotfix is ready, merge it into master and also merge it into staging and develop to ensure the fix is incorporated into future development.

6. Pull Requests and Code Reviews:

   • Ensure that all code changes, including migrations, go through the pull request and code review process. This helps maintain code quality and catch migration conflicts early.

---

Notes

• *common app is used for data migrations. Core App specific data's are hardcoded here as data migrations.