# Git Flow ## Git Branching Strategy Derived from this one https://nvie.com/posts/a-successful-git-branching-model/ ![git flow](https://i.imgur.com/cRsT3Nk.png) 1. Initial commit in the repo `master` branch. 2. `develop` branched from master 3. Feature branches For every feature that needs to be worked on, the dev branches from `develop` and works on it in a separate feature branch. 4. Multiple features can be worked on at the same time in their own branches. If the features are inter dependent on each other, it can be done in the same branch. 6. When the dev finishes the work on the feature, they raise a Pull/Merge Request to merge their changes back into `develop`. All the code review and automated testing happens at this step. The review includes things like: 1. business logic 2. coding style (does the code follow all the pre set conventions for writing code.) 3. is the code performant? 4. any other things that need to be reviewed 6. After all the features are developed, a branch is created from `develop` named `staging`. This branch contains your testable code. The code in this branch can be deployed at a separate QA server for the QA to test if the things are working properly together. The QA also files bugs at this stage. 7. Any bugs that were found are fixed in their own branches. For any bug that the dev needs to work on, he branches from `staging`, works on the bug, raises a Pull/Merge Request against `staging` branch. The reviewer reviews the fix, merges it into `staging`. 8. All the bugs are now fixed and merged. The `staging` branch now contains the code that needs to be delivered. `master` always contains production ready code, so if anything isnt working, fix it in staging and then merge it to master 9. Since we fixed the bugs, we need to update the `develop` branch so that its up to date. For that we merge `staging` back into `develop`. 10. Create a Pull/Merge Request against `master` to merge the ready code into `master`. Review it one last time to see if everything is okay. 11. This is the release step. Create a git tag with the release name. eg: if I am releasing version 2.3 I'll create a tag called `v2.3.0`. This creates a bookmark which you'll be able to go back to very easily if you have to rollback to a previous release. * If a bug is found in the prod build, you create a branch in staging, merge into master and create a new release 13. The cycle repeats. For every subsequent cycle, apart from using the existing `develop` and `staging` branches, everything else remains the same. --- ## Testing #### Automated Testing Every dev writes unit tests for every feature they work on. All the Unit Tests are kept as part of the code within the same repo. This may require some additional configuration to get it working properly. All the tests that are written need to pass for every Merge Request that is raised. If any of the test cases fail, the dev needs to fix their code to make sure that tests pass. Sometimes you'll also need to update the tests themselves if the underlying logic was changed. #### QA The QA is responsible for e2e testing. For any bugs that the QA finds, the QA needs to file it as a separate ticket and, if possible, assign it to a dev for it to be worked on. --- ## Git Hooks To ensure that the code is written properly, a pre-commit hook can be used. This will run every time a commit is being made. This includes (but not limited to): * Formatting * Linting * Unit Testing * other stuff you want to check before the dev commits --- ## Naming Convention * Feature Branches: `feat/<feature_short_code>-<issue_tracking_id>` eg: `feat/ums-23` * BugFixes: `bug/<feature_short_code>-<tracking_ID>` eg: `bug/ums-459` * releases: `release/<version_number>` its recommended to use a stable version scheme that allows you to reason about the version easily. * `release/2021-10-31b`: beta build for 31st Oct 2021 * `release/v2.3.13`: version 2.3.3 major version:2, minor: 3, patch: 13. Check out semver here: https://semver.org/ Read more here: https://stackoverflow.com/a/6065944/4371354 --- ## CI/CD For CI/CD, you can use GitLab runners or BitBucket Pipelines or Github Actions to do CI/CD. The main reason to do it via the repo platform is that you wont need to do extra config to get the code inside the CI system. The main things a CI/CD is responsible for would be: * testing the code * deploying the code #### Testing the code Configure the pipeline to run tests every time a Pull/Merge Request is created. This basically will check if all the unit tests pass and will let you know which ones have failed without you needing to pull and run the code locally. You could also integrate E2E testing here as well if needed but it'll require more configuration #### Deployment Configure the pipeline to deploy the code to server for `develop` and `staging` branches automatically whenever the code is merged. This way you dont need to worry about deploying it yourself. Also increases visibility if anything goes wrong. To deploy the code on production, make sure that it isnt deploying the code automatically. You should create the tag and deploy it yourself (can later move this step to the pipeline as well, but still keep it manual if you want to deploy).