# How to Resolve Merge Conflicts in Git for Research Papers

Most merge conflicts in a research paper repository come from one simple situation. Two coauthors edited the same lines of the same file, usually the methods paragraph, a results table, or the bibliography, and Git cannot decide which version to keep. The first thing to check is always the same. Run `git status` in the repository root. It lists every file in a conflicted state, tells you whether you are mid-merge or mid-rebase, and tells you the exact command needed to finish or cancel the operation. Everything else in this article builds on that output.

Merge conflicts are common in collaborative software work. Empirical studies estimate that 10 to 20 percent of all merges result in conflicts, most often when changes touch the same file region [1]. For a typical paper repository with a handful of contributors, that means you will hit a conflict every few weeks if the team writes actively. The good news is that the overwhelming majority of conflicts are small. Research on large open-source projects found that a significant fraction of conflicts span one or two lines and get resolved with simple strategies that reuse code already present in the merged versions [2]. The same pattern holds for manuscripts. Most conflicts are two authors writing a sentence differently or both adding a reference with the same key.

This guide walks through how to fix merge conflicts in a research repository, explains the causes behind each type, and closes with prevention practices that reduce how often you see them. The commands assume Git from the command line on macOS or Linux, but every command works the same in Git Bash on Windows.

## Why Research Repositories Hit Merge Conflicts

Git is a distributed version control system. Every collaborator has a full copy of the repository history. When two people work on separate branches and then combine their work, Git performs a three-way merge. It compares three snapshots: the common ancestor (called the base), your branch (called ours or HEAD), and the incoming branch (called theirs). Where only one side changed a region, Git applies that change automatically. Where both sides changed the same region differently, Git reports a conflict and asks a human to decide.

For scientists and researchers using Git for manuscripts, code, and data pipelines, the conflict causes fall into a few recurring categories.

**Concurrent edits to the same manuscript lines.** Two authors rewrite the same sentence in `methods.tex`. This is the classic textual conflict and the easiest to resolve.

**Both sides add or edit the bibliography.** Two authors add the same paper under different citation keys, or both reorder a shared `.bib` file. The conflict often looks like a wall of duplicate entries.

**Generated or binary files.** A figure PDF, a large sequencing results table, or a compiled manuscript is committed to the repository and regenerated on both branches. Binary files cannot be merged line by line, so any divergence becomes a conflict.

**Notebooks and analysis scripts.** Jupyter notebooks are stored as JSON. Both authors run cells, which changes output and metadata fields, and the merge machinery sees conflicting JSON even when the actual analysis logic did not change.

**Rebasing instead of merging.** Some developers and researchers rebase branches to keep history linear. Rebasing rewrites commit history, which changes how conflicts appear and how they are recorded. A study of rebase activity in pull requests found that rebasing is widely used and that, in 34.2 percent of rebase scenarios that showed no textual conflict, developers added new changes during the rebase process itself [3]. That hidden editing is one reason rebase conflicts can behave unpredictably.

**Semantic and build conflicts.** Git merges text, not meaning. Two branches can each pass every check on their own and still break when combined, for example when one branch renames a function that another branch calls. These higher-order conflicts escape textual detection entirely and surface only when you build, test, or compile the merged result [4]. A static-analysis study on a large industrial codebase found that such conflicts could be detected in 62 percent of cases before they caused build failures, but only with specialized tooling beyond plain Git [5].

Understanding the cause matters because the fix differs. A textual conflict in a paragraph needs a judgment call about wording. A deleted-file conflict needs a decision about whether the file should exist. A build conflict needs the full pipeline run after resolution. A large survey of Git-based collaborative work describes exactly this spread of conflict types and their different resolution demands in research-style and open-source projects [6].

## A Diagnostic Sequence You Can Follow Every Time

![Decision path asking whether the merge started from the wrong base or you lack time, leading to abort or to resolve files by hand.](/article-images/illustrations/resolve-merge-conflicts-git-research-abort-or-resolve.webp)

When a conflict message appears, work through this sequence in order. It takes under two minutes and prevents most of the mistakes people make under pressure.

1. **Read the message.** Git prints something like `Automatic merge failed, fix conflicts and then commit the result.` The message names the operation in progress, which matters because merges and rebases recover differently.
2. **Run `git status`.** This is your map. It lists files under `Unmerged paths` and distinguishes `both modified`, `both added`, and `deleted by them/us`.
3. **Check for uncommitted work.** If you had unsaved edits when the merge started, stop and sort that out first. Git refuses to start a merge over uncommitted changes for good reason.
4. **Decide to continue or abort.** If the conflict list looks wrong, if you branched from the wrong base, or if you simply do not have time to resolve carefully, run `git merge, abort` (or `git rebase, abort`). Aborting returns the repository to the exact state before the merge attempt. This is always safe and always available.
5. **Resolve files one at a time**, from the smallest to the largest. Small conflicts build confidence and often clarify the larger ones.
6. **Verify the result** before committing. For a paper repository, verification means the document compiles, the figure scripts run, and the tests pass.
7. **Commit or continue.** Use `git commit` for merges or `git rebase, continue` for rebases.

## Troubleshooting Table: Symptom, Cause, Confirmation, Fix

The table below covers the conflict situations you are most likely to encounter in a paper repository, ordered from most to least common.

| Symptom | Likely cause | How to confirm | Fix |
|--|--|--|--|
| `CONFLICT (content): Merge conflict in paper.tex` | Both branches edited the same lines | `git status` shows the file under Unmerged paths, file contains `<<<<<<<` markers | Edit the file, keep the correct text, `git add paper.tex`, `git commit` |
| Conflicts inside `references.bib` | Duplicate citation keys or reordered entries from two branches | Search the merged file for duplicated keys with `grep -c '@'` or check that every `\cite` key resolves | Delete duplicate entries, keep one canonical key per paper, `git add references.bib` |
| `CONFLICT (modify/delete): analysis.py deleted in feature branch` | One branch deleted a file the other branch edited | `git status` labels the file `deleted by them` or `deleted by us` | Decide the file's fate, then `git rm analysis.py` to delete or `git add analysis.py` to keep |
| Conflict markers inside a `.ipynb` notebook | Both branches ran cells, changing JSON output and metadata | Open the notebook as plain text and look for `<<<<<<<` | Resolve as text or rebuild the notebook from a clean copy, then strip outputs before committing |
| `error: Your local changes to the following files would be overwritten by merge` | Uncommitted edits present when the merge started | `git status` shows staged or unstaged modifications | Commit the work or `git stash` it, then merge again |
| `You are not currently on a branch` plus `interactive rebase in progress` | You are mid-rebase and hit a conflict | `git status` states rebase is in progress and shows remaining commits | Fix conflicts, `git add`, then `git rebase, continue`, or `git rebase, abort` |
| `All conflicts fixed but you are still merging` shown in the prompt | Conflicts are staged but the merge commit was never created | `git status` says you are still merging | Run `git commit` with no arguments to create the merge commit |
| No conflict at merge time, but the pipeline fails afterward | Semantic or build conflict between non-overlapping edits | Run the build, tests, or analysis scripts on the merged branch | Diagnose the interaction, edit the affected files, commit normally |

Each row is expanded in the sections that follow, with the mechanism behind the failure and the exact commands.

## Resolving a Textual Conflict Step by Step

This is the core skill for anyone using Git for scientific writing. Suppose you and a coauthor both edited the statistics paragraph in `methods.tex`.

**Step 1. Start the merge and read the failure.**

```
git checkout main
git merge coauthor-edits
```

Git prints `Automatic merge failed` and lists conflicted files.

**Step 2. Inspect the conflict markers.** Open the file. Git has wrapped the contested region:

```
<<<<<<< HEAD
We used a paired t test to compare conditions.
=======
We used a Wilcoxon signed-rank test to compare conditions.
>>>>>>> coauthor-edits
```

The block has three parts. Text between `<<<<<<< HEAD` and `=======` is your version. Text between `=======` and `>>>>>>>` is the incoming version. This text-only view is called unstructured merge, and it is what plain Git does. Research comparing merge strategies shows that tools which understand code structure can report different results from plain textual merge in a meaningful share of conflict scenarios, 24 percent in a large comparison of semistructured and structured merge tools, which is one reason two tools can disagree about whether a conflict exists at all [7].

**Step 3. Decide what the manuscript should say.** This is a scientific decision, not a mechanical one. Look at the analysis code on each branch to see which test was actually run. Often the right resolution combines both sides, for example keeping the correct statistical test and merging in a second author's added citation. Delete all three marker lines when you finish. Marker lines left in a committed file are a classic embarrassment in published repositories, and they will break LaTeX compilation if they land inside the document body.

**Step 4. Stage and commit.**

```
git add methods.tex
git commit
```

Git opens an editor pre-filled with a merge commit message. Saving it completes the merge. On recent Git versions, `git merge, continue` does the same thing.

**Step 5. Verify.** Compile the paper. Run the analysis. A merge commit is a claim that the combination works, and only you can back that claim before anyone else pulls it.

**Safety note on aborting.** `git merge, abort` discards the merge attempt and restores the pre-merge state. It does not touch committed history on either branch, so it is safe. The genuinely destructive commands are `git reset, hard` and `git clean -fd`, which erase uncommitted changes permanently. Never run either while conflicted files contain resolution work you have not saved elsewhere.

## Conflicts in Bibliographies, Figures, and Other Paper-Specific Files

### Bibliography files

Bibliography conflicts deserve their own treatment because they behave differently from prose. When two authors both run a reference manager export, the `.bib` file often gets fully reordered on both branches, and Git reports a conflict across the entire file even though the actual content difference is one added entry. Resolving entry by entry is tedious. A faster approach:

1. Take one side wholesale, for example `git checkout, theirs references.bib`.
2. Manually add the entry the other branch contributed.
3. Verify that every `\cite` or `\parencite` key in the manuscript resolves, using BibTeX or BibLaTeX warnings as the checklist.

The most common underlying cause is the same paper added under two keys, for example `smith2020alignment` on one branch and `SmithEtAl2020` on the other. Both keys compile fine individually, and the duplication only appears as a repeated reference in the rendered bibliography. Prevent this with a shared key convention agreed on before writing starts.

### Binary and generated files

A figure PDF, an image, or a spreadsheet cannot be merged. Git sees two different byte sequences and reports a conflict with no usable markers. Never try to edit the binary by hand. Pick a side with `git checkout, ours figure1.pdf` or `git checkout, theirs figure1.pdf`, then regenerate the figure from its source script if the resolution should reflect both branches' data. The durable fix is to stop committing generated artifacts and commit the scripts and data that produce them instead.

### Jupyter notebooks

Notebook conflicts are the most painful file type in research repositories. A notebook is JSON containing code, outputs, and metadata, and running the notebook rewrites the outputs. Two authors who merely executed the same notebook on different machines produce a JSON conflict even though the analysis logic is identical. Three practices eliminate most of this pain, all established in the data-science community:

- Clear outputs before every commit, so the committed JSON contains only code and inputs.
- Use `jupytext` to pair the notebook with a plain-text script version and commit the script, which merges cleanly.
- When a conflict does appear, resolve the raw JSON carefully or discard one side entirely and re-execute from the other side's inputs.

### Large data files

If your repository tracks sequencing output or tabular results, merges can silently succeed and produce a file that is valid Git output but scientifically wrong, because Git's textual merge simply interleaved lines from two data versions. For any file where line-level interleaving is meaningless, treat a merge of that file as unsafe and always take one side plus a regeneration step. This is the merge-class problem that motivates tools studying conflict structure across languages and file types [1].

## Choosing Resolution Strategies Instead of Guessing

Researchers studying conflict resolution found that developers resolve similar conflicts with similar strategies in the same context. Converting that observation into a habit helps: for each conflict, ask which of the standard strategies applies.

1. **Take ours.** Keep your branch's version. Appropriate when the incoming change is outdated or belongs elsewhere.
2. **Take theirs.** Keep the incoming version. Appropriate when you pulled deliberately to adopt the coauthor's edit.
3. **Union.** Keep both. Appropriate for additive content, such as two authors each adding a paragraph or a reference.
4. **Rewrite the region from scratch.** Appropriate when both edits are stale relative to what the paper now needs.
5. **Regenerate.** Appropriate for outputs, figures, and tables. Resolve the source, then rerun the generator.

Automated research supports the feasibility of pattern-based resolution. A large analysis of 131,154 merge conflict resolutions across 10,000 GitHub projects found that 87.9 percent of individual conflicting chunks could be derived from a small fixed set of language-agnostic resolution patterns, even though only 34.5 percent of complete merges could be resolved automatically end to end [8]. The practical lesson for a research team is that most conflicts resolve with simple, repeatable moves, and the moves are worth agreeing on in advance. A complementary line of work learned resolution rules from developer behavior and could synthesize resolutions for roughly 49 percent of real conflicts using regular-expression-based rules derived from past resolutions [2], which is the same underlying idea behind Git's built-in `rerere` feature described below.

Recent automated tools push further. CHATMERGE uses machine learning to predict a resolution strategy and then applies a large language model to generate the resolution for conflicts needing complex handling [9]. EditFusion models resolution as a sequence of accept-or-reject decisions on individual line-level edits, with an emphasis on adjacent-line conflicts, which its authors found make up a substantial share of all conflicts [10]. These tools are worth watching for GitHub-for-researchers workflows, but none of them replaces reading the conflict. In a paper repository, the conflict resolution is a scientific statement, and you are the one who has to defend it at review.

## Conflicts During Rebase

Rebasing replays your commits one at a time on top of another branch. Each replayed commit can conflict, and a single logical change can therefore produce several sequential conflicts. The state is more fragile than a merge because the repository sits in a detached-head state partway through.

**Recognize the state.** `git status` will report something like `interactive rebase in progress` and `You are currently rebasing branch 'feature-x' on 'main'`.

**Resolve and continue.** Fix each conflicted file, `git add` it, then run `git rebase, continue`. Git replays the next commit.

**Escape hatch.** `git rebase, abort` at any point restores your branch to exactly where it was before the rebase began. Use it without hesitation if the sequence of conflicts becomes confusing.

**Safety note on rebasing shared branches.** Rebasing rewrites commit history. If coauthors have already pulled the branch you rebase, their histories and yours diverge in ways that force a force push, and force pushes can destroy collaborators' work. Restrict rebasing to branches only you have worked on. Rebase-based merging also hides integration activity from the repository's public history, which is why studies of merge conflicts that rely only on public data can miss a substantial portion of real integration events [11]. The practical consequence for a research team is simple: if you rebase, document it in the team's workflow so nobody is surprised by a rewritten history.

Rebase adds one subtle hazard. Because the process rewrites commits, it is easy to accidentally introduce edits while resolving, and those edits get silently folded into a rewritten commit. The finding that developers add new changes in over a third of non-conflict rebase scenarios shows this is not hypothetical. After any rebase that touched manuscript files, diff the result against what you expected before pushing.

## Semantic and Build Conflicts That Git Cannot See

The most dangerous conflicts in a research repository produce no conflict markers at all. Two branches each change different lines, Git merges cleanly, and the combined result is wrong. The literature calls these higher-order, build, or test conflicts, and a characterization study across 208 open-source repositories that manually inspected 538 conflicts confirmed they are harder to detect and resolve than textual conflicts, precisely because existing tooling focuses on text [4].

Concrete examples from research work:

- Branch A renames a function in `analysis.py`. Branch B adds a new plot that calls the old name. The merge is clean, and the pipeline fails at runtime.
- Branch A changes a data-cleaning threshold. Branch B adds a downstream statistics table computed from the cleaned data. Both are correct alone, and the merged numbers are subtly inconsistent.
- Branch A updates a dependency in `environment.yml`. Branch B adds code relying on the old version. The merge installs cleanly and fails later.

**The fix is procedural, not technical.** Treat running the full pipeline as part of the merge, not as an afterthought. Before committing the merge (or immediately after, on a scratch branch), run the build, the tests, and ideally a fast version of the analysis. Build-conflict research on 451 open-source Java projects found 239 build conflicts, most caused by declarations removed or renamed by one developer while another still referenced them, and most resolved by updating or reintroducing the missing reference [12]. That same pattern covers most research-pipeline equivalents: a renamed function, a moved file, a changed column name in a results table. Tooling research continues to expand automated support for these cases, including hybrid example-based and rule-based resolvers for build conflicts [13], but detection during your own merge remains the cheapest intervention.

## Using git mergetool and git rerere

### A three-pane merge editor

Plain text editing works, but a three-way view makes complex conflicts far easier. Configure a merge tool once:

```
git config --global merge.tool vimdiff
```

Then, during a conflict:

```
git mergetool
```

The tool shows the base, your version, and their version side by side, which makes the combination decision visible instead of imaginary. VS Code, and most editors with Git integration, provide equivalent three-way views and will open them automatically when you open a conflicted file.

### rerere, repeated resolution without repetition

Git includes a feature called rerere, short for reuse recorded resolution. When enabled, Git records how you resolved a conflict and automatically applies the same resolution the next time it sees the identical conflict.

```
git config --global rerere.enabled true
```

This is genuinely useful in research workflows with long-lived branches, repeated rebases, or merge queues, because you often resolve the same conflict more than once while a feature branch matures. The research literature validates the underlying idea, showing that learned resolutions can automatically cover about half of real conflicts [2]. rerere is the conservative, fully local version of that idea. One caution: rerere replays past decisions automatically, so if your earlier resolution was wrong, the automation will faithfully repeat the mistake. Check the resolution with `git diff` when rerere fires rather than accepting it blind.

## Preventing Merge Conflicts in a Research Team

Prevention beats resolution. Prediction research shows that merge conflicts can be anticipated with usable accuracy, with classifiers reaching f1-scores between 0.95 and 0.97 for identifying safe merge scenarios across large samples of GitHub repositories [14], and systematic reviews confirm a growing body of prediction methods [15]. But for a research group, you do not need a classifier. You need working agreements that shrink the surface where conflicts arise.

**Merge small and often.** The longer a branch lives, the more the main branch moves underneath it, and the bigger the eventual conflict. Encourage coauthors to merge into the shared branch at least daily during intense writing periods.

**Own sections of the manuscript.** The strongest predictor of conflicts is concurrent edits to the same region. A study of 66 real-world software systems found that conflict risk concentrates around specific contributor roles, and that when two particular developers worked the same source branch, the chance of a merge conflict reached 32.31 percent [16]. The research analog is direct. If two people must touch the methods section, agree on who owns which paragraphs, or coordinate through a shared scratch branch before touching `main`.

**Do not commit generated files.** Figures, compiled PDFs, notebook outputs, and large result tables belong in a build step or in data storage referenced by the repository, not in Git. Every generated file in the repository is a file that conflicts meaninglessly.

**Standardize formatting.** Autoformatting tools applied by one author and not another create wholesale file churn that drowns real edits. Agree on a formatter and a line-ending convention, and let the tool, not a human, produce formatting commits.

**Use pull requests even for a two-person paper team.** GitHub for researchers works best when every integration passes through a reviewable pull request. The pull request shows the diff before it merges, which converts a surprise conflict into a visible one, and the review itself catches semantic problems that Git cannot. Empirical work on merge conflicts in Git-based collaborative projects documents how coordination practices around shared repositories shape conflict frequency and severity [6].

**Keep the pipeline green.** A continuous integration job that compiles the paper and runs a smoke-test of the analysis turns build conflicts from a discovery during submission week into a same-day fix. Higher-order conflicts escape individual branch testing [5], so the integration check is the only reliable tripwire.

## Common Mistakes and Limitations

**Committing conflict markers.** If you stage a file without actually removing `<<<<<<<`, `=======`, and `>>>>>>>` lines, Git accepts it happily. The symptom appears later as a broken LaTeX build or visible garbage in the PDF. Always grep the repository for markers before committing a resolution: `git grep -n '<<<<<<<'`.

**Resolving by blind side-picking.** `git checkout, ours` and `git checkout, theirs` are legitimate commands, but using them without reading the conflict throws away one author's work silently. Read the conflict, make the call, then pick.

**Treating a clean merge as a correct merge.** Git guarantees textual consistency, nothing more. Semantic and build conflicts pass clean through the merger [4]. The merged branch must be built and run before anyone trusts it.

**Rebasing shared branches.** Rewriting history that coauthors have already pulled forces force pushes and creates confusing duplicate commits. Keep rebase private.

**Mixing formatting churn with content edits.** A commit that both reflows the entire bibliography and adds three references makes every future merge conflict enormous. Separate mechanical changes from substantive ones.

**Fixing the wrong direction during a rebase.** In a rebase, the meaning of ours and theirs is reversed relative to a merge, because you are replaying your commits onto the other branch. This reversal causes many wrong-side resolutions. Read `git status` output carefully and, when in doubt, abort and re-approach with a merge instead.

**Ignoring the reflog when something goes wrong.** If a resolution destroys work, `git reflog` shows recent head positions and `git reset, hard <sha>` can recover committed state. Uncommitted changes, however, are generally unrecoverable, which is the reason for every warning above about committing or stashing before risky operations.

One general limitation applies across all of this. Every collaboration, journal, and repository has its own constraints, and the practices here need adapting to your team's size and to funder or publisher requirements for reproducibility and data sharing.

## Frequently Asked Questions

### What does it mean when Git says automatic merge failed?

It means Git could not combine your branch with the incoming branch without a human decision, usually because both branches changed the same lines of the same file. Run `git status` to see the conflicted files, edit each one to remove the `<<<<<<<`, `=======`, and `>>>>>>>` markers, stage the files with `git add`, and finish with `git commit`.

### Should I use git merge, abort or fix the conflict myself?

Use `git merge, abort` whenever the merge went wrong, started from the wrong base, or you lack time to resolve carefully. It restores the exact pre-merge state with no risk. Fix conflicts by hand only when you have read them and understand what the merged result should say.

### How do I resolve a conflict in my bibliography file?

Take one side with `git checkout, theirs references.bib` (or `-ours`), then manually add the entries the other side contributed, and verify that every citation key in the manuscript resolves during compilation. The usual cause is the same reference added under two different keys, so deduplicate as you go.

### What is git rerere and is it useful for research repositories?

rerere records how you resolved each conflict and automatically replays that resolution the next time the identical conflict appears. It is useful for long-lived feature branches and repeated rebases, and it is enabled with `git config, global rerere.enabled true`. Check its automatic resolutions with `git diff`, since it will faithfully repeat a past mistake.

### Can a merge conflict corrupt my data or results?

Git will not corrupt committed history, because any conflicted state is recoverable with `git merge, abort` or `git rebase, abort`. The real risk is a merge that completes cleanly but produces scientifically wrong content, especially with large data files or non-overlapping code changes, so always run your analysis on the merged branch before trusting it.

### Why did a conflict appear during rebase instead of merge?

A rebase replays each of your commits individually on top of the other branch, so one logical change can conflict several times, and the roles of ours and theirs are reversed compared to a merge. Resolve each conflict, `git add` the files, and run `git rebase, continue`, or escape with `git rebase, abort` at any point.

### How do two coauthors avoid merge conflicts when writing one paper?

Merge small changes frequently, agree on who owns which manuscript sections, avoid committing generated files and notebook outputs, standardize formatting, and route changes through pull requests so conflicts appear before the merge rather than during it. Coordination about who touches what is the single most effective measure.

### What is a semantic or build conflict and why does Git not catch it?

A semantic conflict occurs when two branches change different lines that interact badly, such as one branch renaming a function the other branch calls. Git merges text without understanding meaning, so the merge succeeds with no conflict markers and the failure only appears when you build, test, or run the analysis. Running the full pipeline after every merge is the reliable defense.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does it mean when Git says automatic merge failed?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It means Git could not combine your branch with the incoming branch without a human decision, usually because both branches changed the same lines of the same file. Run git status to see the conflicted files, edit each one to remove the conflict markers, stage the files with git add, and finish with git commit."
      }
    },
    {
      "@type": "Question",
      "name": "Should I use git merge, abort or fix the conflict myself?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use git merge, abort whenever the merge went wrong, started from the wrong base, or you lack time to resolve carefully. It restores the exact pre-merge state with no risk. Fix conflicts by hand only when you have read them and understand what the merged result should say."
      }
    },
    {
      "@type": "Question",
      "name": "How do I resolve a conflict in my bibliography file?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Take one side with git checkout, theirs references.bib (or, ours), then manually add the entries the other side contributed, and verify that every citation key in the manuscript resolves during compilation. The usual cause is the same reference added under two different keys, so deduplicate as you go."
      }
    },
    {
      "@type": "Question",
      "name": "What is git rerere and is it useful for research repositories?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "rerere records how you resolved each conflict and automatically replays that resolution the next time the identical conflict appears. It is useful for long-lived feature branches and repeated rebases, and it is enabled with git config, global rerere.enabled true. Check its automatic resolutions with git diff, since it will faithfully repeat a past mistake."
      }
    },
    {
      "@type": "Question",
      "name": "Can a merge conflict corrupt my data or results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Git will not corrupt committed history, because any conflicted state is recoverable with git merge, abort or git rebase, abort. The real risk is a merge that completes cleanly but produces scientifically wrong content, especially with large data files or non-overlapping code changes, so always run your analysis on the merged branch before trusting it."
      }
    },
    {
      "@type": "Question",
      "name": "Why did a conflict appear during rebase instead of merge?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A rebase replays each of your commits individually on top of the other branch, so one logical change can conflict several times, and the roles of ours and theirs are reversed compared to a merge. Resolve each conflict, git add the files, and run git rebase, continue, or escape with git rebase, abort at any point."
      }
    },
    {
      "@type": "Question",
      "name": "How do two coauthors avoid merge conflicts when writing one paper?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Merge small changes frequently, agree on who owns which manuscript sections, avoid committing generated files and notebook outputs, standardize formatting, and route changes through pull requests so conflicts appear before the merge rather than during it. Coordination about who touches what is the single most effective measure."
      }
    },
    {
      "@type": "Question",
      "name": "What is a semantic or build conflict and why does Git not catch it?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A semantic conflict occurs when two branches change different lines that interact badly, such as one branch renaming a function the other branch calls. Git merges text without understanding meaning, so the merge succeeds with no conflict markers and the failure only appears when you build, test, or run the analysis. Running the full pipeline after every merge is the reliable defense."
      }
    }
  ]
}
</script>

## Sources

1. [Merge Nature: a tool to support research about merge conflicts](https://doi.org/10.5753/vem.2022.226216)
2. [Almost Rerere: Learning to Resolve Conflicts in Distributed Projects](https://doi.org/10.1109/TSE.2022.3215289)
3. [Understanding Merge Conflicts and Resolutions in Git Rebases](https://doi.org/10.1109/ISSRE5003.2020.00016)
4. [A Characterization Study of Merge Conflicts in Java Projects](https://doi.org/10.1145/3546944)
5. [Detecting Higher-Order Merge Conflicts in Large Software Projects](https://doi.org/10.1109/icst46399.2020.00043)
6. [An Analysis of Merge Conflicts and Resolutions in Git-Based Open Source Projects](https://doi.org/10.1007/s10606-018-9323-3)
7. [The Impact of Structure on Software Merging: Semistructured Versus Structured Merge](https://doi.org/10.1109/ASE.2019.00097)
8. [Towards Semi-Automated Merge Conflict Resolution: Is It Easier Than We Expected?](https://doi.org/10.1145/3661167.3661197)
9. [Git Merge Conflict Resolution Leveraging Strategy Classification and LLM](https://doi.org/10.1109/QRS60937.2023.00031)
10. [EditFusion: Resolving Code Merge Conflicts via Edit Selection](https://doi.org/10.1109/ASE63991.2025.00055)
11. [The Private Life of Merge Conflicts](https://doi.org/10.1145/3555228.3555240)
12. [Build conflicts in the wild](https://doi.org/10.1002/smr.2441)
13. [Combining Example-Based and Rule-Based Program Transformations to Resolve Build Conflicts](https://doi.org/10.1145/3793302.3793347)
14. [Predicting Merge Conflicts in Collaborative Software Development](https://doi.org/10.1109/ESEM.2019.8870173)
15. [On the Prediction of Software Merge Conflicts: A Systematic Review and Meta-analysis](https://doi.org/10.1145/3592813.3592931)
16. [Predicting merge conflicts considering social and technical assets](https://doi.org/10.1007/s10664-023-10395-8)