Retreating After Four Git Conflicts on a Feature Branch: The Reality of Git Operations with AI
What This Article Covers
While working on a feature branch, I encountered Git conflicts four times in a row. I tried to resolve them with AI assistance, but ultimately decided to abandon the branch and start over. This article records how that happened and the lessons I drew from it.
What a Git Conflict Is
For readers who are not familiar with the technical background, here is a brief explanation.
Git is a tool for recording the history of file changes. It supports working on multiple changes in parallel. When two separate changes modify the same section of the same file, Git cannot determine which change is correct. This is a conflict.
An analogy: imagine two people edited the same paragraph of the same document separately. One produced a version with the paragraph deleted; the other produced a version with something added to it. A person has to decide which version to keep. That is what resolving a conflict looks like.
How Four Conflicts Accumulated
At one point, I was working on a large change to the site’s navigation structure on a feature branch. The scope of the changes was wide enough that I spread the work across multiple days.
The first conflict happened because a separate change made on the main branch had touched the same file as the feature branch. I reviewed both changes with AI and decided which to keep, and resolved it.
The second conflict occurred during that resolution process. A file AI modified while resolving the first conflict collided with another change. Resolving one conflict had created a new one.
The third and fourth conflicts followed the same pattern. Each resolution introduced a new source of collision, and the cycle repeated.
What Happened When AI Helped with Resolution
AI helped with each resolution step. However, changes AI made to resolve a conflict sometimes broke the consistency of another file.
AI reviews file contents and proposes changes, but it does not have a complete picture of all dependencies across every file. The result was that resolving one conflict created conditions for another one in a different place.
Why I Decided to Retreat
After the fourth conflict, I decided to stop working on the branch.
Three reasons led to that decision.
-
There was no sign the conflict chain would end. A conflict appearing each time I resolved one was a signal that the feature branch had drifted too far from main.
-
The cost of determining what was correct had increased. Early on, I could judge at the level of “this line in this file.” After the changes accumulated, it became unclear what state any given file should be in.
-
Starting over was faster. I understood what the changes needed to accomplish. Abandoning the branch and rebuilding from a fresh start would cost less total time than continuing to resolve conflicts.
I discarded the branch, created a new feature branch from main, and made the changes in smaller increments.
The Lesson
Do not keep a branch alive too long.
The longer a feature branch diverges from main, the wider the gap becomes. Every change merged into main during that time is a potential source of conflict when the feature branch eventually needs to reconcile with it.
The same applies when working with AI. AI makes changes quickly, which means many files can be touched in a short time. That also means the conditions for a collision with other changes can form quickly.
Three practices I took from this experience: keep changes small, keep feature branches short-lived, and regularly bring in changes from the main branch.
Summary
- A Git conflict is a collision that occurs when two separate changes modify the same section of a file
- Keeping a feature branch separated from main for too long increases the risk of chained conflicts
- AI can introduce a new conflict while resolving an existing one
- Abandoning a branch and starting over can be faster than continuing to resolve conflicts
- Small changes, short-lived branches, and regular syncing with main help prevent the problem