Handling merges and resolving conflicts effectively is key to maintaining a clean and stable codebase. This document outlines the process for merging branches and resolving conflicts when they arise, ensuring smooth collaboration among team members.

• Keep branches up-to-date: Before merging a feature branch into main or develop, make sure your branch is up-to-date with the target branch by regularly merging or rebasing from it.
• Small, frequent merges: Avoid large or long-lived branches by merging small, completed features frequently. This reduces the likelihood of conflicts and simplifies the merge process.
• Test before merging: Ensure that all tests pass and no breaking changes are introduced before merging. Use continuous integration (CI) to automate these checks.

Follow these steps to merge a branch:

1. Update your feature branch:

   • Before merging your branch into the target branch (main or develop), first update your branch by running:

     git fetch
     git pull origin <target-branch>

2. Resolve any conflicts (if they arise) during the update (see the next section for conflict resolution).

3. Run Tests:

   • Ensure that the application builds successfully and that all tests pass.

     ./gradlew test

4. Merge the Branch:

   • If there are no conflicts, and all tests pass, proceed with the merge:

     git checkout <target-branch>
     git merge <your-branch>

5. Push the Changes:

   • Push the changes to the remote repository:

     git push origin <target-branch>

6. Delete the Feature Branch (Optional):

   • Once the branch is merged, you can delete the feature branch locally and remotely:

     git branch -d <your-branch>
     git push origin --delete <your-branch>

---

Conflicts occur when multiple branches modify the same lines of code or files. Here's how to handle conflicts when they arise:

1. Identify the Conflict:

   • Git will notify you about the files with conflicts during the merge or rebase process. The conflict markers look like this:

     <<<<<<< HEAD
     Your changes
     =======
     Changes from the other branch
     >>>>>>> branch-name

2. Manually Resolve the Conflict:

   • Open the conflicting file(s) and decide which changes to keep. You can:
     • Keep your changes by removing the other branch's lines.
     • Keep the other branch's changes by removing your lines.
     • Combine both changes by manually editing the file.
   • Remove the conflict markers <<<<<<<, =======, and >>>>>>> after you make your choice.

3. Stage the Resolved Files:

   • After resolving conflicts, stage the changes using:

     git add <file-name>

4. Continue the Merge or Rebase:

   • After staging the resolved files, continue the process:
     • For a merge:

       git commit

     • For a rebase:

       git rebase --continue

5. Run Tests:

   • Ensure everything is working correctly by running tests again before completing the merge:

     ./gradlew test

6. Push Changes:

   • Once conflicts are resolved and all tests pass, push the changes:

     git push origin <target-branch>

---

For complex merges, where multiple conflicts or significant changes are involved:

1. Communicate Early:

   • If you know your merge is likely to result in significant conflicts, communicate with the team early. Consider scheduling a call or using a designated Slack/Discord channel to resolve the conflicts collaboratively.

2. Use GitHub Discussions:

   • If a conflict spans multiple files or involves business logic changes, use GitHub Discussions or pull request comments to discuss the conflict resolution approach. Be sure to document the resolution clearly.

3. Document the Resolution:

   • After completing the merge, describe the conflict resolution process in the pull request description. This helps others understand the decisions that were made.

---

• GitHub Conflict Resolution Tool: GitHub provides an in-browser tool to resolve conflicts when merging pull requests. It is useful for simple conflicts and allows you to make quick fixes directly from the pull request.

• Rebasing vs Merging: Rebasing keeps your commit history cleaner by replaying changes on top of the target branch. Merging retains the original commit history. Use rebasing when you want a linear history, but merge when you want to preserve context of branch merges.

  • To rebase:

    git fetch
    git checkout <your-branch>
    git rebase <target-branch>

• Use Git Log: Use git log --graph --oneline --decorate to visualize the branch history and understand where conflicts are likely to occur.

• Automated CI Checks: Before merging any branch, ensure CI pipelines are green to catch potential issues early.

---

By following these steps, you can handle merges and resolve conflicts efficiently, ensuring minimal disruption to the project. Good communication and regularly updating your branch with the target branch will prevent conflicts from becoming overwhelming.