Git conflicts in Object Repository are ruining my life

[fmcclure]

Hey everyone, I’m really hoping someone can help me out because I am at my wits’ end with Katalon Studio and Git. I’m pretty new to automation, and my team recently started using Git for version control so we could work together on our test cases. But literally every single time I pull the latest changes from the main branch, my Object Repository gets completely wrecked with merge conflicts.

Here is what I’ve been doing:

1. I create a new test case and capture some objects using the Web Recorder or Spy Web.

2. Katalon automatically saves them into the Object Repository folder.

3. My teammate does the exact same thing on their machine for a different page.

4. When I try to do a git pull or merge their branch into mine, Git throws a massive tantrum about conflicts in .rs files or the object_repository.properties file.

I tried opening those conflicting .rs files in a text editor to manually fix the <<<<<<< HEAD and >>>>>>> lines, but the XML/JSON inside looks like ancient hieroglyphics to me. I accidentally deleted a bracket once, and it completely corrupted the object, making Katalon crash when I opened the project! Right now, my only “fix” is to completely delete my local project, re-clone it from Git, and manually recreate all my objects from scratch. It is taking me hours and killing my productivity. What am I doing wrong? Is there a way to make Git and Katalon stop fighting?

[Falak]

The issue you are experiencing stems from how Katalon Studio manages web objects. Every time you spy or record an object, Katalon generates a .rs (Repository Object) file containing XML metadata. Furthermore, it dynamically updates internal files like object_repository.properties to track these objects.

When multiple automation engineers record objects simultaneously, Git tries to merge these autogenerated XML files and properties lines sequentially. Because the internal IDs, positions, or properties change rapidly, standard Git text-merging algorithms fail, resulting in corrupted object metadata.

The Professional Solution

To resolve and prevent this in an enterprise environment, you need a three-pronged approach: Git Architecture Optimization, Strict Team Workflows, and an Automation Exclusion Strategy.

1. Implement a Robust .gitignore

Many conflicts occur in non-essential, dynamically generated local files. Ensure your root project folder has a .gitignore file that excludes user-specific and temporary Katalon files.

Add the following to your .gitignore:

Plaintext

.groovy/
.settings/
bin/
Libs/
output/
report/
Reports/
Test Cases/.trash/
Object Repository/.trash/
.classpath
.project
html_report/

(Note: Do not ignore the entire Object Repository, just the .trash folders and user-specific configurations).

2. Adopt a Modular Object Repository Hierarchy

Instead of saving all objects into the root of the Object Repository, enforce a strict Page Object Model (POM) folder structure.

• If Developer A is working on the Login page, they only touch Object Repository/Page_Login/.

• If Developer B is working on the Dashboard, they only touch Object Repository/Page_Dashboard/.

Because Git isolates file tracking by directory pathing, separate folders drastically reduce the footprint of conflicting lines.

3. Leverage Katalon’s Native “Clean Up”

Before pushing your code, always use Katalon’s built-in cleanup to ensure no orphaned or temporary objects are tracking in your workspace. Go to Project > Clean… from the top menu to refresh the project’s internal metadata state cleanly before committing to Git.

[qurzunta.kaab]

• Implement .gitignore: Prevent Git from tracking local user files, temporary caches, and .trash folders by adding a robust .gitignore file to your root directory.

• Enforce Page Object Model (POM): Stop saving everything in the root Object Repository. Organize objects into isolated page folders (e.g., Page_Login/, Page_Dashboard/). This ensures teammates rarely modify the same directory.

• Run Project Clean: Before committing or pulling changes, go to Project > Clean… in Katalon Studio to force the IDE to rebuild its internal .properties files cleanly.

• Never Merge XML Manually: If an .rs file has a Git conflict, do not edit it with a text editor. Use Git to discard your local object version (git checkout -- <file>) and simply re-spy the element to avoid syntax corruption.

Custom Keyword: Object Repair & Validation Helper

This custom keyword dynamically validates your test objects at runtime. If a Git conflict has corrupted an object’s underlying XML structure, this keyword catches the error, prevents Katalon from crashing, and safely alerts your team.

Create a new keyword file under Keywords (e.g., com.utils.git.ObjectFixer.groovy):

Groovy

package com.utils.git

import com.kms.katalon.core.annotation.Keyword
import com.kms.katalon.core.testobject.ObjectRepository
import com.kms.katalon.core.testobject.TestObject
import com.kms.katalon.core.util.KeywordUtil

public class ObjectFixer {

    /**
     * Verifies if an object is valid or corrupted by Git merge conflicts.
     * If broken, it catches the error safely instead of crashing the execution.
     * * @param objectId The Object Repository path (e.g., 'Object Repository/Page_Home/btn_Login')
     * @return TestObject if healthy, null if corrupted
     */
    @Keyword
    public static TestObject verifyAndRepairObject(String objectId) {
        try {
            TestObject tObj = ObjectRepository.findTestObject(objectId)
            if (tObj == null) {
                KeywordUtil.markWarning("Object ID '${objectId}' is completely missing. Check your Git merge.")
                return null
            }
            // Access properties to trigger XML parsing validation
            tObj.getProperties() 
            return tObj
            
        } catch (Exception e) {
            KeywordUtil.markWarning("GIT CORRUPTION DETECTED: The metadata for '${objectId}' is broken. Reason: " + e.getMessage())
            return null
        }
    }
}

How to implement it in your Test Scripts:

Groovy

import com.utils.git.ObjectFixer
import com.kms.katalon.core.testobject.TestObject
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI

// Safely resolve the object before interacting with it
TestObject loginBtn = ObjectFixer.verifyAndRepairObject('Object Repository/Page_Login/btn_Submit')

if (loginBtn != null) {
    WebUI.click(loginBtn)
} else {
    KeywordUtil.markFailed("Test failed safely: Target element was corrupted by a Git conflict.")
}

[cdietrich]

Which version control is best to use ?

[arvind.choudhary]

YOu are not alone, we all have gone through this during out initial days. so chill.
What you’re experiencing is one of the most common growing pains when multiple engineers work on the same Katalon project.

Why it happens

Every object in Katalon is stored as an .rs XML file inside the Object Repository. Git doesn’t understand Katalon objects—it only sees text files.

So when:

• You create or modify an object
• Your teammate creates or modifies an object
• Both changes touch the same file or folder metadata

Git attempts to merge XML content and can generate conflicts.

The object_repository.properties file is especially notorious because Katalon updates it frequently, making it a hotspot for merge conflicts.

For your situation, I would recommend you focus on these four actions immediately:

1. Pull latest changes before starting work.
2. Use feature branches instead of working directly on main.
3. Organize objects by page/module ownership.
4. Use a proper Git merge tool instead of editing .rs files manually.

[arvind.choudhary]

@cdietrich

Which version control is best to use ?

For Katalon projects Git is still the best version control system.

[kazurayam]

@fmcclure

Here is what I’ve been doing:

1. I create a new test case and capture some objects using the Web Recorder or Spy Web.

2. Katalon automatically saves them into the Object Repository folder.

I suspect that you and your co-worker saved the test objects into immediately under the root Object Repository folder. Don’t do that! If you and your co-worker save the generated test objects into a single folder (e.g, the root Object Repository), then you will get a lot of conflicts.

You should save them into some designated sub folder. Before you start the Web Recorder, you should plan out in which sub folder you want to save the test objects. The sub folders could be named like Object Repository/Page_Login/ or Object Repository/Page_Dashborder/, as @Falak and others suggest. And when you let the Web Recorder to save the generated test objects, you should explicitly select the destination sub folder, like :

Or, after you generate test objects and saved into a temp folder, you can move a test object from a folder into another manually.

You should explicitly manage in which subfolder you want to save the test objects. Don’t expect the tools to manage the location automagically; the tools would never do that.

[depapp]

hi @fmcclure

first thing: stop putting everything in the root of Object Repository. Make subfolders like Object Repository/Page_Login/ and Object Repository/Page_Dashboard/. When you and your teammate work in different folders, Git conflicts basically disappear because you are not touching the same files. Just pick the right folder in Spy/Recorder before you save.

that object_repository.properties file is super annoying because Katalon keeps rewriting it and it conflicts all the time. Before you commit, run Project > Clean, then pull, then push. Get in the habit of pulling before you start working and before you push.

if you do get a conflict on an .rs file, do not try to edit the XML yourself. Just throw away your local copy with git checkout --theirs "Object Repository/path/to/object.rs" and re-spy the element. Takes 30 seconds instead of the hours you are probably spending now

[kazurayam]

@depapp

that object_repository.properties file is super annoying because Katalon keeps rewriting it and it conflicts all the time.

@depapp

I don’t know what object_repository.properties file is. I have never seen such file in the /settings folder of my Katalon projects. Where is it?

[depapp]

ah you’re right mr @kazurayam, my bad. there’s no object_repository.properties file in Katalon. i think i mixed it up with the Selenium way of storing locators in a .properties file. each object in Katalon is just its own .rs file. ignore that bit

[ebauch]

i guess true for all!

[ckutch]

well structed!

[Monty_Bagati]

While the above may help you , you will still face your original problem and there is no escape. Here is what you can do

always create a branch before you start work ( rebase , if only you are working)
checkout that branch

instead of git pull , Always do git pull --rebase (only on your branc)
do your work
then git merrge into main

if more members are working on the same branch , never rebase , just do
git pull
do yopur work
git push

[cdare]

i thought i was alone

[tdenesik]

you need to build standaard way so you dont get stuck.

[kruecker]

working on it complex thing to sort

[vmuller]

well defined!