GitLab Branching Structure for Development and Deployment

Branch Naming Rules

1. Create Feature and WIP Branches:

   • Create the feature branch from the current month's version branch.

   • From the feature branch, creat e a WIP (Work In Progress) branch.

   • Make code changes, test, and push commits (add Jira id in commit message) to the WIP branch.

2. Prepare for Merge Requests (MRs):

   • Before creating any MRs:

     • Check out to the feature branch and pull the latest changes from the current month's version branch.

     • Check out to the WIP branch and pull the latest changes from the feature branch.

3. Create and Approve MRs:

   • Create a merge request from WIP to FEATURE.

   • Use the MR title format: WIP to FEATURE: {{Title}} | {{Jira id}} (e.g., "WIP to FEATURE: Added new payment gateway | TASK-5678").

   • IMPORTANT: Its mandatory to add below description and unit test details as applicable

     Open

     

   • Choose the appropriate label for the merge request (MR). If you cannot find a suitable label based on your source and target branches, it might indicate that the merge request is invalid. In such cases, reach out to a reviewer for assistance.

   • Once the above MR is approved and merged, create a merge request from FEATURE to STAGING.

   • Use the MR title format: FEATURE to STAGING: {{Title}} | {{Jira id}}.

   • If there are conflicts during the FEATURE to STAGING merge, follow these steps:

     1. Create a conflict resolution branch from staging (e.g., conflict/resolved/{feature name}).

     2. Check out the newly created conflict branch locally.

     3. Pull the latest changes from the feature branch and resolve conflicts.

     4. Create a merge request from the conflict branch to STAGING with the title format: conflict to STAGING: {{Title}} | {{Jira id}}.

4. Create Deployment Tags (MR Reviewer):

   • After the above MRs are merged, create a deployment tag on GitLab for staging or dev environments:
     GitLab Tags for Eshopbox Client Portal.

5. Deploy to Production:

   • Once testing is complete and the code is ready for deployment to production:

     • Check out to the feature branch and pull the latest changes from the current month's version branch.

   • Create the following merge requests (MRs) with the respective titles:

     1. FEATURE to VERSION: {{Title}} | {{Jira ID}}

     2. VERSION to MASTER: {{Title}} | {{Jira ID}}

     3. VERSION TO STABLE || FEATURE TO STABLE (Deprecated)

Additional Instructions:

• Add QA or PM approval screenshots/ Approval Jira task comment Id, ensuring the EPIC ID is clearly highlighted.

• Delete all related branches, including WIP, FEATURE, BUG, and PATCH.

• Once all MRs are merged, create a deployment tag for production environments (For MR Reviewer):
  GitLab Tags for Eshopbox Client Portal.

Additional Notes:

• Always use the specified MR title format: {{Source branch}} to {{Target branch}}: {{Title}} | {{Jira id}}.

  • Example: "Version to Master: Added fix for OTP issue in login | BUGS-1234".

• Include the corresponding Jira task or bug ID in both the commit messages and the merge request titles to ensure proper tracking and traceability.

Purpose
The following guidelines is implemented to ensure efficient code review processes and high-quality standards. MRs (Merge Requests) that do not adhere to these criteria will be subject to automatic rejection or rejection by the reviewer.

Guidelines:

1. **WIP Merge Requests**:

• Any WIP (Work In Progress) MR exceeding 200 lines will be rejected.

• Weekly submission of MRs (transitioning from WIP to Feature) is mandatory. Multiple submissions within a week are permissible.

• Avoid retaining unmerged WIP changes for over a week.

2. **Submission and Review Timeline**:

• MRs must be moved from WIP to Feature within one week.

• Code reviews should occur during the initial stage (WIP to Feature) rather than waiting until Feature to Staging to avoid last-minute issues.

3. **Review Availability**:

• All reviewers must allocate one hour daily for code review.

• This dedicated time ensures prompt feedback, allowing assignees to address comments and suggestions the following day.

Highlighting common problems. Below are practices to help us overcome challenges:

Handling Large Merge Requests

1. Exceeding 200 Lines:

• If an MR exceeds 200 lines due to additional commits:

• Avoid pushing further commits into the same MR if it already surpasses 200 lines.

• Split the MR into smaller, more manageable parts, ensuring each part is reviewable within the 200-line limit.

• For template changes or urgent requirements that naturally exceed 200 lines, request an exception from the team lead or reviewer.

2. Breaking Down Tasks:

• When requirements necessitate a large amount of code:

• Attempt to break down tasks into smaller, logical units where possible.

• If breaking down tasks does not fulfill requirements effectively, document the reasoning and seek approval for a larger MR.

3. Urgent Requirements:

• For urgent requirements needing immediate deployment:

• Communicate the urgency to the team and prioritise the MR for expedited review.

• Ensure the MR is well-documented to facilitate a quick and thorough review process.

• Reviewers should make themselves available for immediate review to meet the urgent deadline.

4. Team Communication:

• Regularly communicate with the team about ongoing MRs, particularly those needing urgent attention or exceptions.

• Keep the team informed about the status and progress of MRs to ensure smooth collaboration and timely reviews.

Conclusion

By adhering to these guidelines and solutions, we aim to maintain a balance between efficient code reviews and the flexibility needed for large or urgent tasks. Please inform the team lead or project manager if you have any concerns or require further clarification regarding these guidelines.

Read More About Gitlab and Merge Request In Below Document:

Gitlab Help Center

Merge Request