Resolving NitroX Merge Conflicts
If your team is using NitroX, and more than one team member is working on the same project, creating the Test Steps and components it’s possible that you may encounter merge conflicts if use create the same FACT component. We would highly recommend that you commit often with small changes so that Git works in your favour rather than waiting to make your commit perfect, it’s better to work in small chunks and keep committing your work to minimise these issues occurring.
If you do encounter a merge conflict with NitroX we recommend you use the following steps to help you resolve the conflicts where two users have created the same component and encountered a merge conflict on the pull request. In this example, I’m merging the main branch into my feature branch change2.
Using a tool like Github, once the pull request is created and in conflict, select the Resolve Conflicts button on the pull request screen.
Above: Snapshot of Branch Conflict.
With NitroX, depending on the size of your commit and pull request you may only have 1 file affected, you may have multiple files but the key point to remember is that depending on the merging strategy you need to be consistent and consider the impact of the change decide to:
- Keep your branch’s changes: could this impact existing test
- Keep only the other branch’s changes: you’ll need to update your branch’s files
- Make a branch new change incorporating changes from both: consider the two previous two points.
Delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes you want in the final merge. In most cases, it’s advisable to Keep only the other branch’s changes and update your branch to prevent issues in files that aren’t in conflict. In the example below, I will accept the changes from main and update my files paying particular attention to the FACT component and Test Case files created.
In the following example, I have several conflicts and I’ve decided to keep the Keep only the other branch’s changes so I’ll manually remove the conflicts.
Above: Snapshot of Branch’s changes.
Once you’ve resolved all the conflicts in the file, click Mark as resolved.
Above: Snapshot of Resolved Conflicts.
If you have more than one merge conflict in your file, scroll down to the next set of conflict markers and repeat the previous steps to resolve your merge conflict.
Once you’ve resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your feature branch.
Above: Snapshot of Commit merge.
Once the merge is confirmed, pull the latest changes from the remote branch and check your test is working as expected. Then commit your changes and merge to the main.
We understand that this could become quite complicated and we are working to enhance the product to improve this user experience and assist you in working with source control repositories.
- Provar Automation
- Installing Provar Automation
- Updating Provar Automation
- Using Provar Automation
- API testing
- Behavior-driven development
- Creating and importing projects
- Creating test cases
- Custom table mapping
- Functions
- Debugging tests
- Defining a namespace prefix on a connection
- Defining proxy settings
- Environment management
- Exporting test cases into a PDF
- Exporting test projects
- Override auto-retry for Test Step
- Managing test steps
- Namespace org testing
- NitroX
- Provar desktop
- Provar Test Builder
- Refresh and Recompile
- Reintroduction of CLI license Check
- Reload Org Cache
- Reporting
- Running tests
- Searching Provar with find usages
- Secrets management and encryption
- Setup and teardown test cases
- Tags and Service Level Agreements (SLAs)
- Test cycles
- Test plans
- Testing browser options
- Tooltip testing
- Using the Test Palette
- Using custom APIs
- Callable tests
- Data-driven testing
- Page objects
- Block locator strategies
- Introduction to XPaths
- Creating an XPath
- JavaScript locator support
- Label locator strategies
- Maintaining page objects
- Mapping non-Salesforce fields
- Page object operations
- ProvarX™
- Refresh and reselect field locators in Test Builder
- Using Java method annotations for custom objects
- Applications testing
- DevOps
- Introduction to test scheduling
- Apache Ant
- Configuration for Sending Emails via the Automation Command Line Interface
- Continuous integration
- AutoRABIT Salesforce DevOps in Provar Test
- Azure DevOps
- Running a Provar CI Task in Azure DevOps Pipelines
- Configuring the Automation secrets password in Microsoft Azure Pipelines
- Parallel Execution in Microsoft Azure Pipelines Using Multiple build.xml Files
- Parallel Execution in Microsoft Azure Pipelines using Targets
- Parallel execution in Microsoft Azure Pipelines using Test Plans
- Bitbucket Pipelines
- CircleCI
- Copado
- Docker
- Flosum
- Gearset DevOps CI/CD
- GitHub Actions
- Integrating GitHub Actions CI to Run Automation CI Task
- Remote Trigger in GitHub Actions
- Parameterization using Environment Variables in GitHub Actions
- Parallel Execution in GitHub Actions using Multiple build.xml Files
- Parallel Execution in GitHub Actions using Targets
- Parallel Execution in GitHub Actions using Test Plan
- Parallel Execution in GitHub Actions using Job Matrix
- GitLab Continuous Integration
- Travis CI
- Jenkins
- Execution Environment Security Configuration
- Provar Jenkins Plugin
- Parallel Execution
- Running Provar on Linux
- Reporting
- Salesforce DX
- Git
- Team Foundation Server
- Version control
- Provar Automation trial guide and extensions
- Salesforce Testing
- Provar Manager
- Best Practices
- Troubleshooting
- Release Notes