Welcome to the definitive resource for effective Git teamwork! In the world of modern software development, collaboration is essential, and understanding Git's workflow is essential. This post offers a detailed road map for navigating Git's intricacies, guaranteeing a seamless experience with collaborative development. Let's explore useful tactics and ideas to improve harmony and productivity in your team's Git workflow.

Version Control Structure

1. Repository Initialization: Each microservice is allocated a dedicated private repository.

2. Access Management:

• Team members are granted write permissions for specific repositories (microservices) as required. Read access is available upon request.

• Protection is applied to main, staging, production and Hotfixes branches, permitting only the admin to merge pull requests.

3. Branching Strategy within Repositories: Within each repository, distinct branches are established:

• Main: Deployable in the development environment.

• Staging: Ready for deployment in the quality assurance (QA) environment, reflecting code rather than configurations.

• Production: Deployable in the production environment, representing code rather than configurations.

• Hotfixes: Synchronized with the production branch, dedicated for urgent fixes.

4. Developer Branches: All team members maintain individual branches labeled as "Dev-DeveloperName."

5. Collaboration Testing Branch: Developers can create a temporary branch named “Dev-testing-Dev1-Dev2” whenever there is a need to test their work collaboratively or merge conflict resolution and recovery .

This temporary branch merges changes from the individual branches of two developers (Dev1 and Dev2).

Once the testing is completed, and the changes have been validated, the Dev-testing-Dev1-Dev2 branch is promptly deleted.

6. Commit Convention: Commits are required to reference the associated Jira ticket number, labeled either as fixBug-ticketNumber or Feature-ticketNumber. Completed tickets are pushed to the developer branch within the remote repository.

7. Deployment Readiness and Pull Requests:

• Upon readiness for deployment, developers push their work to their branches and initiate a pull request to the main branch.

• Admin review is required before merging. In the event of simultaneous pull requests, a Conflict Resolution Strategy is employed (as described below).

8. Deployment Preparation:

• The Main branch should be prepared for deployment in the development environment. Once the team leader determines it's time for QA release, a pull request is initiated from the main branch to the staging branch.

9. Automation and Configuration Handling:

• Cloning of the repository from the staging branch is followed by the execution of scripts to modify configuration files (e.g., app settings, ocelot). Similar steps are replicated for the live environment.

10. Hotfix Procedure:

• A dedicated HotFixes branch, synchronized with the production branch, is utilized for urgent fixes. Once fixes are performed, they're pushed to the HotFixes branch, followed by a pull request from HotFixes to Production.

Conflict Resolution Strategy:

1. Merge Coordinator Role: The admin responsible for overseeing merges and managing the merge queue.

2. Merge Queue: Conflicting or overlapping pull requests are placed in a merge queue, overseen by the Merge Coordinator.

3. Priority Assignment: The team leader assigns priority levels or urgency indicators (high, medium, low) to pull requests when entering them into the merge queue.

4. Queue Management by Coordinator: The Merge Coordinator evaluates priority levels and urgency, merging pull requests accordingly. Developers are informed about queue status and anticipated merge timelines.

5. Conflict Resolution Meetings: Periodic meetings are conducted to address persistent conflicts. Developers present their cases, discussing impacts and collaboratively deciding on the merge order or resolution strategies.

6. Communication and Transparency: Maintaining clear communication regarding the merge queue's status, priorities, and potential delays ensures developers' awareness of the process and decision rationale.

7. Documentation of Decisions: Record-keeping of conflict resolution meeting decisions and the underlying reasoning aids in comprehending past conflicts and guiding future resolutions.