Implementing Multi-Model and Provider Support in Tailor4Job: Handling Merge Conflicts

In this post, I’ll share my experience of adding two new features to my project, Tailor4Job:

1. Support for Multiple Models: Enabling the tool to accept and process multiple AI models simultaneously.
2. Provider Support: Allowing the tool to work with multiple AI providers like Groq and OpenRouter.

These features were developed in parallel branches, which introduced merge conflicts when combining them. Let’s walk through the process.

Features Implemented

1. Multi-Model Support

I added functionality to allow Tailor4Job to accept multiple models via a comma-separated list in the CLI. For example:

python main.py --model "groq,llama3-8b-8192" --output Output

Each model runs its analysis on the input files (resume, cover letter) and generates a separate output file, allowing users to compare results.

2. Provider Support

Tailor4Job now supports multiple AI providers like Groq and OpenRouter. I integrated the APIs for both providers and added CLI options to select the provider:

python main.py --model "google/gemma-2-9b-it:free" --provider "openrouter"

This flexibility lets users switch between providers easily.

The Merge Process and Conflicts

After implementing both features in separate branches, I encountered merge conflicts when merging them into the main branch. Git couldn't perform a fast-forward merge because both branches modified the same files (main.py and utils.py).

Resolving Conflicts

The main conflict was in how the CLI options and API interactions were handled. Using Git’s conflict markers (e.g., <<<<<<< and >>>>>>>), I merged the logic from both branches:

• Combined the logic for multiple models and multiple providers.
• Resolved conflicting code in how files were processed based on the selected model and provider.
• I used the VS CODE's Merge Editor, which helped me track the merge conflicts.

After merging, I thoroughly tested both features to ensure everything worked correctly and also made some changes as necessary to make the both functionalities work.[Note: I think I encountered greater number of Merge Conflicts because both the functionalities were related to each other, the second functionality cannot work without first as before I only had Groq's Model to use, The second model was added while adding another Provider/Model]

Lessons Learned

1. Merge Conflicts Are Inevitable: When working in parallel branches, conflicts will happen. The key is to isolate your changes and keep your commits clear and focused.
2. Testing is Critical: After resolving the conflicts, I ran multiple test cases to ensure that both features worked together seamlessly.
3. Plan for Integration: Next time, I’ll plan better for integrating features before starting parallel work, which would reduce the chances of conflicts.

Final Thoughts

This lab gave me valuable experience in managing Git workflows, especially handling complex merges. I now feel more confident in resolving conflicts and working with multiple branches.

Links

• GitHub Repository
• Issue: Multi-Model Support
• Issue: Provider Support
• Merge Commit for Multi-Model Support
• Merge Commit for Provider Support
• Merge Commit after solving Merge Conflicts