Add GitFlow workflow documentation and diagrams

gitflow-workflow.md

@@ -0,0 +1,141 @@
+# **GitFlow Workflow**
+
+## Overview
+
+GitFlow is a branching model for Git that helps teams manage feature development and release cycles efficiently. It standardizes how branches are structured, making collaboration easier and ensuring a smooth release process.
+
+## Git Repository
+
+🔗 [https://gitea.plp19.com/](https://gitea.plp19.com/)
+
+## Organization Permissions:
+
+✅ Only the HoD can create, modify, and delete organizations.\
+✅ Only the HoD can add teams and grant permissions for organizations. 
+
+## Repository Permissions:
+
+✅ Only the HoD and Leaders can create, modify, and delete repository.\
+✅ Only the HoD and Leaders and Leaders can change settings for  repository.
+
+## Branch Permissions
+
+### ✅ `master` branch: production branch
+
+- Prevent rewriting history.
+- Prevent branch deletion.
+- Prevent changes without a pull request.
+- Limit write access to Leaders.
+
+### ✅  `develop` branch: development branch
+
+- Prevent rewriting history.
+- Prevent branch deletion.
+- Prevent changes without a pull request.
+- Limit write access to Game leaders.
+
+### ✅ Other branches
+
+- Full access for all users in the repository.
+
+## Branch Prefixes
+
+### ✅Bugfix: `bugfix/`
+
+Typically used to fix bugs in a development branch.
+
+### ✅Feature: `feature/`
+
+Used for specific feature development, typically branching from and merging back into the development branch.
+
+### ✅Hotfix: `hotfix/`
+
+Typically used to quickly fix the production branch.
+
+
+# Gitflow
+
+Gitflow is really just an abstract idea of a Git workflow. This means it dictates what kind of branches to set up and how to merge them together. We will touch on the purposes of the branches below.
+
+## 1️⃣ Master Branch
+
+The `master` branch contains the latest updates for the project currently running in the LIVE environment.
+
+Any changes to the `master` branch must be performed through a pull request. Leaders will review and merge the changes accordingly.
+![GitFlow Timeline](images/gitflow-workflow/master-branch-diagram.png)
+
+## 2️⃣ Develop Branch
+
+Develop branch contains the complete history of the project and serves as an integration branch for features.
+
+We will create the SAT (Site Acceptance Test) version on the `develop` branch and tag it with an updated version number. Once approved and deployed to LIVE, we will merge this confirmed version into the `master` branch.
+
+Any changes for the `develop` branch must be performed through pull request. Leaders will review and merge the changes accordingly.
+
+![GitFlow Timeline](images/gitflow-workflow/develop-branch-diagram.png)
+
+## 3️⃣ Feature branches
+
+Each new feature should be developed in its own branch and pushed to the central repository for backup and collaboration. However, instead of branching from the `master` branch, feature branches should originate from the `develop` branch. Once a feature is complete, it should be merged back into the `develop` branch. Features must never interact directly with the `master` branch.
+
+Feature branches are generally created from the latest `develop` branch.
+
+![GitFlow Timeline](images/gitflow-workflow/feature-branch-diagram.png)
+
+## 4️⃣ Bugfix branches
+
+Bugfix branches are used to quickly patch for SAT versions. Bugfix branches are a lot like feature branches that will use `develop` as their parent branch. Once the fix is complete, it should be merged into the `develop` branch.
+
+
+![GitFlow Timeline](images/gitflow-workflow/bugfix-branch-diagram.png)
+
+## 5️⃣ Hotfix branches
+
+Hotfix branches are used to quickly patch production releases. Hotfix branches are a lot like bugfix branches and feature branches except they're based on `master` instead of `develop`. This is the only branch that should fork directly off of `master`. Once a feature is complete, it should be merged into both `master` and `develop`, and `master` should be tagged with an updated version number.
+
+![GitFlow Timeline](images/gitflow-workflow/hotfix-branch-diagram.png)
+
+# Pull request flow
+A pull request is a development process that provides a platform for discussion and review of a completed feature. Its purpose is to notify team members that the feature has been completed and it is open for discussion or modifications. The discussion usually occurs to improve the quality of the code; it is basically a code review process.
+
+## What Needs to Be Done Before Creating a Pull Request?
+1. Commit code in your feature branch. Note that a feature can have any number of commits.
+2. Commits made in the branch only reflect changes on the local machine (i.e. your machine). So, the commits need to be pushed to the remote branch.
+3. Then, you’re ready to rebase your branch. Rebasing is required if any new pull requests were merged after you had taken the feature branch.
+4. After rebasing, any conflicts that arise need to be resolved, and the code needs to be pushed back to the remote branch.
+5. Finally, it’s time to create a pull request.
+
+Note: Pull requests require two distinct branches. There needs to be a difference in the code between the taken branch and source branch.
+
+## Pull Request Process
+
+1. When creating a pull request, you add a brief overview of your feature, select the branch to which the code needs to be merged, and select the assignee who will be reviewing it.
+2. Once it is created, it is open for discussion or modifications.
+3. Sometimes conflicts occur after creating a pull request, and you must resolve these conflicts. 
+4. Usually, the assigned person reviews the code, but it is not mandatory that only the assignee performs the review. Any team member can take part in the review process and give their feedback or discuss potential modifications to the code.
+5. Any feedback or modifications are added in the form of comments near the code line.
+6. The developer resolves comments and replies to the reviewer.
+7. This process continues until all comments are resolved.
+8. Once all discussions are resolved, the code is merged to the branch that was selected when the pull request was created.
+
+Note: Pull requests can be made for any branch. Usually, they are made for the source branch. Sometimes it is okay to close a pull request without merging it. This usually occurs when a feature is dropped.
+
+## Benefits of Pull Requests
+- Use this collaborative platform to discuss potential modifications to the code.
+- Improve code quality.
+- Simplify the process of receiving feedback from the reviewer.
+- Address feedback easily in-line near the relevant code.
+- Provide better stability for the code.
+
+![GitFlow Timeline](images/gitflow-workflow/pull-request-workflow.png)
+
+## What Are Merge Conflicts and When Do They Occur in a Pull Request?
+To better explain what conflicts are, consider a scenario where developer A takes a branch, feature A, from the develop branch. Another developer, developer B, takes a branch, feature B, from the develop branch.
+
+Now both developers work on their respective feature branches. Developer A modifies a line or a block of code in the feature A branch. Developer B also modifies the same block of code that developer A has modified but in the feature B branch.
+
+After completing their features, both developers create pull requests to the develop branch; let’s call them pull request A and pull request B. Then, a reviewer merges A. Once A is merged, a conflict arises in B because the same block of code was modified by both developers.
+
+To resolve the conflict, developer B must rebase the feature B branch by retrieving an update from the develop branch (i.e. the source branch). After retrieving the update, developer B faces code conflicts in their local copy of the branch. Now they must resolve the conflicts and again, commit, and push code to the remote develop branch. Now the code is free of conflicts, so B can be merged by the reviewer.
+
+# **Thanks for reading!**