You finished your tests on your branch. Time to bring them into main. This is called merging. Most of the time, Git handles it automatically — no issues. But sometimes two people edited the same line in the same file, and Git says "I don't know which version you want. You decide." This is a merge conflict.
Merge conflicts sound scary. They're not. Once you resolve 2-3 of them, it becomes routine. Let's learn both — clean merges and conflict resolution.
# Step 1: Go to the branch you want to merge INTO
git checkout main
# Step 2: Merge your feature branch
git merge feature/login-tests
# Merge made by the 'ort' strategy.
# LoginTest.java | 25 ++++++++++++++++
# 1 file changed, 25 insertions(+)
# Step 3: Verify — your commits are now in main
git log --oneline
# Both main and feature/login-tests commits appear here
# Step 4: Clean up the branch (optional)
git branch -d feature/login-testsReal example: You changed the login button locator to By.id("login-btn"). Your colleague changed the same locator to By.cssSelector("button.login") on their branch. Git sees two different versions of the same line and doesn't know which one to keep.
# Git tells you there's a conflict
git merge feature/login-tests
# CONFLICT (content): Merge conflict in LoginPage.java
# Automatic merge failed; fix conflicts and then commit the result.
# Check which files have conflicts
git status
# both modified: LoginPage.javaOpen the conflicted file. Git marks the two versions with special markers:
<<<<<<< HEAD
private By loginButton = By.id("login-btn");
=======
private By loginButton = By.cssSelector("button.login");
>>>>>>> feature/login-tests
// HEAD = the branch you're on (main)
// Below ======= = the branch you're merging in// After resolving — you decided CSS selector is better:
private By loginButton = By.cssSelector("button.login");# Stage and commit the resolution
git add LoginPage.java
git commit -m "Resolve conflict: use CSS selector for login button"
# If you want to abort the entire merge and go back:
git merge --abortNever leave conflict markers (<<<<<<, ======, >>>>>>) in your code. They're not comments — they'll cause compilation errors. Always verify the file compiles after resolving.
VS Code has a built-in merge conflict resolver. It shows "Accept Current Change", "Accept Incoming Change", "Accept Both Changes" buttons right above the conflict. Use it — it's faster than manual editing.
Q: How do you resolve a merge conflict?
A: When a merge conflict occurs, Git marks the conflicting sections with <<<<<<, ======, and >>>>>> markers. I open the file in VS Code, which highlights conflicts automatically. I look at both versions, decide which one to keep (or combine them), remove the conflict markers, save the file, run git add to stage the resolved file, and git commit to complete the merge. In our test framework, conflicts usually happen in page objects when two testers change the same locator or method. I also run the tests after resolving to make sure nothing broke.
Key Point: Merge conflicts are normal in team projects. Read both versions, pick the right one, delete the markers, commit. Done.