Git Flow

Understand the SemVer Components in Simple Way

  • MAJOR Version: Incremented for incompatible changes.

  • MINOR Version: Incremented for backward-compatible new features.

  • PATCH Version: Incremented for backward-compatible bug fixes.

SemVer

Branching Strategy Based on Versioning

Create a branch based on the requirements shown in the image below.

gitbranching

scenario 1 - Develop to Release

scenarior1

Steps

Merge Process

  1. Test the develop branch locally before merging it into release.

  2. Create a merge request to merge into the develop branch.

  3. To resolve conflicts, a maintainer role is required.

  4. Locally checkout (switch to) the develop branch and pull from release.

  5. Resolve any conflicts (ensuring that the code remains functional and bug-free).

  6. Test locally to ensure all functionality works, then push changes to the remote develop branch.

  7. Merge changes into the release branch for Testing.

  8. Once the pipeline completes successfully, checkout (switch to) the develop branch and pull from release to incorporate the merge commit. This prevents conflicts in future merges from release.

scenario 2 - Bugfix to Release and Develop

  • Purpose: Address specific bugs or issues.

  • Naming: it should be like bugfix/#<issue_no>/<developer_name>.

  • Versioning: Bug fixes typically lead to a PATCH increment.

scenario2

Steps

  1. While testing, if any bugs are found, create a bugfix branch from the release branch.

  2. Fix the bug and test it thoroughly.

  3. Create a merge request to merge the bugfix branch into the release branch (do not delete the bugfix branch).

  4. Resolve any conflicts locally, ensuring that the code remains functional and bug-free.

  5. Merge the bugfix branch into the release branch.

  6. Once the pipeline completes successfully, checkout (switch to) the bugfix branch and pull from release to incorporate the version bump commit. This prevents conflicts in future merges.

  7. Checkout the bugfix branch and pull from develop to update the bugfix branch with the latest changes from develop.

  8. If conflicts arise while pulling from develop, resolve them and then merge the bugfix branch into develop, ensuring that it works correctly.

scenario 3 - Release to Master and develop

  • Purpose: Contains the latest stable release.

  • Versioning: Updates when a new version is released. ( now we are doing manually (Version Bump) )

scenaroi3

Steps

  1. Once the release branch is working fine, obtain permission from higher authority to merge into production/live.

  2. Verify that old version code does not negatively impact live users by thoroughly testing all functionalities.

  3. Create a merge request to merge release into master.

  4. A maintainer role is needed to resolve conflicts.

  5. Checkout to the release branch and pull from master. Resolve any conflicts locally, ensuring that both new and existing features work correctly.

  6. Merge the release branch into master once the pipeline is successful. Pull the latest code into the develop branch, test it, and push to the remote repository.

scenario 4 - Hotfix to master and Develop

  • Purpose: Quickly address urgent issues that need to be resolved in the current release.

  • Naming: Named hotfix/#<issue_no>/<developer_name>.

  • Versioning: These typically increment the PATCH version. Merged into both main and develop or release branches as necessary.

scenario4

Steps

  1. If a bug arises from master, immediately create a hotfix branch from master.

  2. Fix the issue and test it locally, ensuring that the fix does not affect existing code.

  3. Create a merge request to merge the hotfix branch into master. Resolve any conflicts and test it again.

  4. Merge the hotfix branch into master (do not delete the hotfix branch). Once the pipeline is successful, pull the latest code from master and develop, resolving any conflicts.

  5. Merge the hotfix branch into develop. After the merge, delete the hotfix branch.

scenario 5 - Feature to Develop Branch

  • Purpose: Develop new features or improvements.

  • Naming: Typically named something like feature/#<issue_no>/<developer_name>.

  • Versioning: Bug fixes typically lead to a MINOR increment.

scenario5

Steps

  1. Before starting feature implementation, discuss with all relevant teams (Android, Web, Backend) to understand how the feature may impact their work.

  2. Once the feature is complete, test it locally thoroughly. Compare the implementation across Android and Web to ensure consistency and that it works on both ends.

  3. Create a merge request to merge the feature into the develop branch.

  4. Update the code by pulling the latest changes from develop, resolve any conflicts locally, and retest to ensure that everything works correctly.

  5. Merge the feature into the develop branch.

  6. After merging, delete the feature branch.

scenario 6 - Bugfix to Develop Branch

  • Purpose: Address specific bugs or issues.

  • Naming: it should be like bugfix/#<issue_no>/<developer_name>.

  • Versioning: Bug fixes typically lead to a PATCH increment.

scenario6

Steps

  1. If a bug arises during new feature implementation due to an old feature, create a bugfix branch from develop.

  2. Discuss the bug with all relevant teams (Android, Web, Backend) to ensure the fix will not impact other functionalities.

  3. Fix the issue in the bugfix branch, test it thoroughly, and cross-check with other teams.

  4. Once the code is working fine, pull the latest updates from develop.

  5. Resolve any conflicts, test the code again, and then merge the bugfix branch into develop.

  6. After merging, delete the bugfix branch.