# Git Merge for Researchers: How It Works and How to Use It

A git merge is the operation that combines the changes made on two branches of a version-controlled project into a single branch, recorded as one commit that points back to both parent histories. For researchers, it is the mechanism that lets several people, or one person pursuing two analysis ideas, work in parallel on the same code, pipeline, or manuscript and then recombine that work without overwriting anything.

The situation it solves is familiar in any lab that writes code. One analyst rewrites a plotting script while another adds a statistical test to the same repository. A multi-site study needs each site's processing changes folded back into a shared pipeline. A journal asks for a code availability statement, and the lab must produce one coherent version of the analysis rather than five folders all named final [1]. Git for scientists works the same way Git works for software teams, and it became the default in research because it makes parallel work cheap while keeping a complete, verifiable audit trail across datasets, statistical code, figures, lab notes, and manuscripts [2]. The merge is where that promise becomes real. It is the moment when parallel contributions either combine cleanly or surface their contradictions, and researchers who understand it can collaborate asynchronously, integrate each other's work at any time, and still say exactly which version of the code produced which result [2]. Researchers who do not understand it tend to avoid branches, trade zipped folders by email, and lose work. This article explains what a merge actually does, walks through the commands on a realistic analysis repository, shows how conflicts arise and how to resolve them, and describes the habits that keep merges boring, which is exactly what you want from them.

## Git Merge for Researchers, Explained: The Vocabulary That Makes Merges Legible

Git is a distributed version control system (VCS), a tool that records the full history of changes to a set of files so that any past state can be recovered later. A repository is the project folder plus a hidden .git directory where that history lives. A commit is a named snapshot of the tracked files, stored with a message, an author, a timestamp, and a pointer to the commit that came before it. A branch is a movable label attached to one commit, which is why creating one takes milliseconds. A remote is a copy of the repository on another machine, usually a hosting service such as GitHub, that collaborators use to sync their work. HEAD is the name for whatever commit you currently have checked out, in other words the state of the files sitting in front of you.

Kuo and colleagues, writing a version control primer for surgical research groups, describe four mental models that carry most of daily Git use: the repository, the commit, the branch, and the remote, combined with a daily cycle of editing files, staging them, and committing [1]. Merging is the operation that closes the loop between branches. You branch to isolate work, you commit to record it, and you merge to bring it back together.

One further term matters more than any other for understanding merges: the merge base. When you merge branch B into branch A, Git first finds the common ancestor, the most recent commit that both branches share. Everything that happens next is computed from three versions of each file: the version at the merge base, the version on your current branch, and the version on the branch being merged. This is called a three-way merge, and holding those three versions in mind explains nearly everything about when merges succeed silently and when they stop and ask for help.

| Version | Git's name for it | What it contributes |
|--|--|--|
| The common ancestor | merge base (base) | What the file looked like when the two branches split |
| Your current branch | ours | The changes you made since the split |
| The branch being merged | theirs | The changes the other line of work made since the split |

## Merge Compared With the Commands It Gets Confused With

![Decision path asking whether the branch is shared and whether it is already pushed, leading to merge, rebase, or revert.](/article-images/illustrations/git-merge-for-researchers-merge-or-rebase.webp)

Students often treat merge, rebase, pull, and cherry-pick as interchangeable ways to "get the latest code." They are not, and the differences show up in the history that you will later need to defend in a methods section.

| Term | What it does | Effect on history | Typical use in a research project |
|--|--|--|--|
| git merge | Combines two branches and writes a merge commit with two parents | Preserves both branch histories exactly | Integrating a collaborator's analysis branch or your own finished feature |
| git rebase | Replays your commits on top of another branch | Rewrites your commits with new identifiers | Tidying your own unshared branch before opening a pull request |
| git pull | Fetches new commits from a remote, then merges them into your current branch | Equivalent to a fetch followed by a merge | Updating your local main before starting the day |
| git cherry-pick | Copies one specific commit onto your current branch | Adds one commit without its branch ancestry | Backporting a bug fix to a released pipeline version |
| Squash merge (GitHub) | Combines every commit on a pull request into a single commit on the target branch | Collapses the branch history into one commit | Keeping main readable when a branch accumulated many small commits |

Two of these deserve a warning. First, git pull is not a separate mechanism. It runs fetch, which downloads new commits, and then runs merge on them, so every pull is a merge wearing a different name. Second, rebase rewrites history. The commits come out with new identifiers, which breaks anyone who already built work on top of them. The working rule in collaborative research is simple: merge anything that is shared, rebase only your own branches that nobody else has pulled.

## Why Merging Matters in Scientific Workflows

Reproducibility is the core argument. Ram's widely cited paper on version control in science frames Git as a framework for managing the full suite of research outputs, giving individual researchers the ability to track and compare versions, retrace errors, and explore new approaches in a structured manner while maintaining a complete audit trail [2]. For collaborative efforts, Git and its hosting services let everyone work asynchronously and merge contributions at any time while the complete history is preserved [2]. The merge is the verb behind all of that. Without it, parallel work has no safe way back into a single lineage.

There is also a publishing argument. Major journals now request code availability statements, yet most trainees and faculty receive no formal training in the tools that make those statements true [1]. Kuo and colleagues built their Git and GitHub primer specifically around research workflows such as retrospective registry analysis, multi-institutional collaboration, and reviewer reproducibility requests, and every one of those workflows ends in a merge [1]. When a reviewer asks for the exact code that produced Figure 3, the answer is only clean if the branches that produced it were merged rather than stapled together by hand.

The technical argument comes from how Git compares with older centralized systems. In a controlled transition study at a software research lab, branching in Git measured about 39 times faster than branching in Subversion, merging in Git was described as trivial and automatic while Subversion required a manual, error-prone merging process, and disk use on a large legacy project (Mozilla with the FSFS backend) was up to 30 times lower under Git [3]. Those three properties together are what make the branch-and-merge style of work practical for a research group. You can afford a branch per analysis idea because branches are nearly free, and you can afford to merge them because Git does the integration work for you.

Research software itself now lives in this world. Community pipelines such as EasyAmplicon, an open-source microbiome analysis pipeline, distribute updates and handle user help through their project channels and GitHub presence, which means the pipeline version a paper cites is the product of many merged contributions [4]. The merge concept has even traveled beyond code. The Git Context Controller framework for managing the memory of AI research agents borrows commit, branch, and merge as explicit operations for checkpointing and combining lines of reasoning, which says something about how general the model is [5].

## How a Merge Works, Step by Step

Here is what Git actually does when you run a merge, in order.

1. **Git checks your working tree.** A merge needs a clean state. If you have uncommitted edits, Git will refuse or refuse selectively, so commit or stash your work first.
2. **Git identifies the merge base.** It walks the two branch histories backward until it finds the most recent commit they share. That commit is the reference point for everything else.
3. **Git computes two sets of changes.** It diffs the merge base against your branch (ours) and the merge base against the incoming branch (theirs). Modern Git performs this with its default strategy, called ort in current versions.
4. **Git applies the changes region by region.** Files are compared in blocks of lines called chunks or hunks. Four outcomes are possible per chunk:
   - Changed on your side only: your version is kept.
   - Changed on the incoming side only: their version is taken.
   - Changed identically on both sides: the change is kept once.
   - Changed differently on both sides: this is a conflict, and Git stops.
5. **Git writes the result.** If no conflict occurred, Git creates a merge commit, a commit with two parents, one for each branch tip. The default message looks like "Merge branch 'volcano-plots'". If the incoming branch is simply ahead of yours with no divergence at all, Git takes a shortcut called a fast-forward and just moves your branch label to the newer commit without creating a merge commit. You can force a merge commit even in that case with the no-ff option, which many labs prefer because it keeps the record that a line of work existed.

A micro-example makes the chunk logic concrete. Suppose the merge base contains this line in a script:

```
cutoff <- 0.05
```

If your branch changed it to `cutoff <- 0.01` and the incoming branch never touched it, Git takes your version and moves on. If both branches changed the line to the same value, Git keeps it once. If the branches changed it to different values, Git cannot know which number is scientifically correct, so it hands the decision to you.

One subtlety catches many newcomers. Git does not merge line by line in the way people imagine. It merges in chunks, and edits to neighboring lines can land in the same chunk even when they never touch the same characters. These adjacent-line conflicts are common enough that researchers studying automated conflict resolution treat them as a major category, and they can usually be resolved by simply combining both edits [6]. Knowing this changes the interpretation of a conflict from "someone clobbered my work" to "we both edited the same neighborhood."

## Running a Merge in a Research Repository: A Worked Example

Consider a small lab repository called rna-seq-pipeline with a script, scripts/analysis.R, that subsets a differential expression results table. The main branch currently contains:

```
sig_results <- subset(res, padj < 0.05)
```

A collaborator decides the confirmatory analysis should use a stricter false discovery cutoff. They create a branch, change the line, and merge their work into main, which goes cleanly because nobody else was editing that region. Meanwhile, you have been on your own branch, volcano-plots, adding a fold-change filter to the same line:

```
git switch -c volcano-plots
# edit scripts/analysis.R so the line reads:
# sig_results <- subset(res, padj < 0.05 & abs(log2FoldChange) > 1)
git add scripts/analysis.R
git commit -m "Add fold-change filter to significant results"
```

Now you want to bring your work into main. You update main and merge:

```
git switch main
git pull
git merge volcano-plots
```

Git prints something like:

```
Auto-merging scripts/analysis.R
CONFLICT (content): Merge conflict in scripts/analysis.R
```

and tells you the automatic merge failed and to fix the conflict before committing. Both versions of the line changed since the merge base, and they changed differently, so Git stopped exactly where it should have. Running `git status` lists the file under "both modified," which is Git's way of saying the merge is paused, not broken.

Open the file and you will find the two versions wrapped in conflict markers:

```
<<<<<<< HEAD
sig_results <- subset(res, padj < 0.01)
=======
sig_results <- subset(res, padj < 0.05 & abs(log2FoldChange) > 1)
>>>>>>> volcano-plots
```

Read the markers as a structured question. The block between `<<<<<<< HEAD` and `=======` is the version on the branch you are standing on (main, carrying your collaborator's stricter cutoff). The block between `=======` and `>>>>>>>` is the incoming version (your fold-change filter). Resolving the conflict means replacing this entire block with the code you actually want, markers deleted.

Here is the part that matters for research specifically. Git can tell you that the two versions differ, but it cannot tell you which analysis is right. If the study plan prespecified the 0.01 threshold and the fold-change filter is a sensible restriction on top of it, the resolution combines both intentions:

```
sig_results <- subset(res, padj < 0.01 & abs(log2FoldChange) > 1)
```

That is a scientific decision, and it belongs to the person who understands the analysis, not to the tool. This is why conflict resolution in research repositories should be done by whoever can speak for the analysis, not by whoever happens to be at the keyboard.

Once the file reads the way you want, finish the merge:

```
git add scripts/analysis.R
git commit
```

Git supplies the default merge message. The merge commit now has two parents, and you can see the shape of what happened:

```
git log --graph --oneline --all
```

which prints output along these lines:

```
*   f3a9c21 Merge branch 'volcano-plots'
|\
| * 7b2e4d0 Add fold-change filter to significant results
* | c81aa6f Lower FDR cutoff to 0.01
|/
* 9d0e1b2 Add differential expression script
```

The graph shows the two lines of work diverging from the shared ancestor at the bottom and rejoining at the merge commit on top. That picture is the whole story of a merge, and learning to read it is one of the most useful Git skills a researcher can acquire.

Two auxiliary tools round out daily practice. If a conflict is more than you want to handle in the moment, `git merge, abort` returns the repository to exactly the state it was in before you started, which makes experimenting with merges safe. If you prefer a graphical side-by-side view for resolution, configure one with `git config, global merge.tool vimdiff` (or any supported tool) and launch it with `git mergetool`. You can also ask Git to show the common ancestor inside each conflict, which helps when both sides moved the same code, by setting `git config, global merge.conflictStyle zdiff3`.

## Merge Conflicts in Practice: How Common, How Mechanical

![Worked calculation applying the 87.9 percent and 34.5 percent figures from the conflict resolution study.](/article-images/illustrations/git-merge-for-researchers-conflict-chunks.webp)

Conflicts feel like failures the first few times, but large-scale evidence says they are routine and mostly small. In a study of 10,000 GitHub projects, researchers classified 131,154 real merge conflict resolutions against a small set of language-agnostic resolution patterns and found that 87.9 percent of individual conflicting chunks are mechanically derivable, meaning a simple rule could reproduce what the developer did, while 34.5 percent of complete merges could be derived as a whole [7]. Read those two numbers together. Most conflicts decompose into a handful of small decisions, and most of those decisions are obvious, which is why the practical skill is to work chunk by chunk rather than to panic at the file level.

The same research community has been building tools to help. EditFusion models conflict resolution as a sequence of accept-or-reject decisions on individual developer-authored edits, an approach motivated by the observation that adjacent-line conflicts make up a substantial portion of all conflicts and often follow simple patterns [6]. CHATMERGE takes a two-stage approach, using machine learning to predict a resolution strategy and then a large language model to draft resolutions for conflicts that need complex handling, with experiments showing alignment with historical manual resolutions and performance ahead of previously available tools [8]. On the structured side, tools such as Spork merge abstract syntax trees rather than raw text, which reduces the number of conflicts in the first place, and Spork additionally preserves code formatting better than comparable tools while running faster, properties demonstrated by replaying 1,740 real-world file merges collected from 119 open-source projects [9].

A dose of caution belongs next to that optimism. A careful evaluation of version control merge tools, designed to distinguish correct merges from merely clean ones by running test suites and accounting for the cost of incorrect merges, found that results differ significantly from earlier claims in the literature [10]. The lesson for a research lab is not that automated tools are useless. It is that every automated resolution, whether from a merge tool or a language model, is a suggestion that must be reviewed in the diff and confirmed by rerunning the analysis. In a research setting the stakes are specific: an automated resolution that silently drops your collaborator's filter condition will produce a plausible-looking figure of the wrong thing.

## Testing a Merge Before You Trust It

The single most dangerous misconception about merging is that a conflict-free merge is a correct merge. Git merges text. It has no model of what your code means, so two changes that combine cleanly at the text level can still break the program, a situation software engineers call a semantic conflict. The evaluation work behind modern merge tools exists precisely because clean output and preserved behavior are different properties, and distinguishing them requires actually executing the merged code [10].

For a research repository, verification looks like this:

1. **Integrate early and often.** Merge main into your branch (or rebase it if the branch is private) before you merge back, so you resolve conflicts while they are small.
2. **Rerun the tests.** If the repository has any test scripts, run them after the merge, before the merge commit is pushed.
3. **Rerun a slice of the pipeline.** On a small subset of samples or a toy dataset, execute the merged pipeline end to end and compare key outputs against pre-merge results. Checksums of output tables and visual inspection of figures both work.
4. **Inspect what the merge itself changed.** Running `git show` on a merge commit displays a combined diff that lists only the files whose merged content differs from both parents, which is a fast way to see exactly where the merge made decisions.
5. **Let continuous integration help.** If the repository is hosted with automated checks, treat a failed build after a merge as the signal it is.

The habit of frequent integration is not just folklore. In an analysis of two large continuous integration datasets (TravisTorrent and GHALogs), researchers engineered branch-level features such as feeder-branch count, median feeder lifetime, and merge dynamics, and found that strategies favoring frequent, small integrations achieved higher build success than long-lived branching models. Their best model reached an AUC-ROC of 0.92 on TravisTorrent and 0.78 on GHALogs, and an ablation study showed the branching features complemented, rather than replaced, standard build metrics [11]. Translated into lab practice: short-lived branches merged often produce fewer surprises than a month-long branch merged once, and the state of your branches is itself a signal about the health of your builds.

## Merging on GitHub for Researchers

GitHub is the hosting layer where merges become visible, reviewable, and auditable for a whole team. The core object is the pull request (PR), a proposal to merge one branch into another, wrapped with discussion, line-level review, and automated checks. The person opening the PR pushes their branch, teammates review the diff, and the merge happens through the web interface, which offers three ways to land the work: a standard merge commit that preserves the branch history, a squash merge that compresses the branch into one commit, and a rebase merge that replays the commits without a merge commit. For a shared analysis repository, the standard merge commit is the most transparent choice, because it keeps the record that a line of work existed and was integrated.

The pull request model is what makes multi-institutional research collaboration workable, since each site can work on its own branch and propose merges that site leaders and analysts review before anything enters the shared pipeline [1]. It is also how labs answer reviewer reproducibility requests, by pointing to the merged, tagged state of the repository that produced a result [1].

One change in the collaboration landscape is worth planning for. AI coding agents now submit pull requests to shared repositories, and an analysis of 33,596 agent-authored PRs across 2,807 repositories found that 40.2 percent of repositories contained co-active agent-authored PR pairs under exact temporal overlap, with those pairs accounting for 79.4 percent of all agent PRs, figures that rise to 53.4 percent and 95.0 percent within a one-week window. Cross-agent pairs were rare (0.5 percent of co-active pairs) but encountered significantly higher rates of textual conflict during three-way merge replay. For a research group, the practical reading is that concurrent, overlapping contributions to the same repository are becoming the norm rather than the exception, from humans and agents alike, which puts a premium on small branches, frequent merges, and clear ownership of each analysis file.

Hosting also changes how research software reaches its users. Community pipelines such as EasyAmplicon maintain their tutorials, feedback, and updates through their project channels and GitHub presence, so the merge history of such a project is, in a real sense, the version history of the method your paper used [4].

## Common Mistakes and Limitations

**Committing patient or identifiable data.** The most serious mistake in research version control has nothing to do with merge mechanics. Identifiable patient data must never enter a version-controlled repository, and a .gitignore file listing data directories and sensitive file patterns is the standard guard against inadvertent commits [1]. Understand the limit of that guard: .gitignore only keeps untracked files out of future commits. If sensitive data were already committed, they remain in the repository history until the history is rewritten, and a pushed repository should be treated as disclosed. Data governance policies vary by institution, so confirm your local rules with your data custodian before hosting anything containing human data.

**Letting branches live too long.** A branch that drifts for weeks accumulates conflicts and semantic drift. The evidence on branching strategies and build success favors frequent, small integrations over long-lived branches [11]. A reasonable lab rhythm is to merge or update analysis branches at least every few days.

**Trusting a clean merge.** As covered above, textual success is not behavioral correctness, and the distinction is exactly what merge tool evaluations are designed to test [10]. Always rerun the analysis after a nontrivial merge.

**Merging binary and large data files.** Line-based merging applies to text. For binary files such as BAM, FASTQ, or Excel workbooks, Git cannot merge content at all, so a conflict means you simply choose one version and discard the other. Keep raw data out of the repository and reference it, or use a pointer-based storage system designed for large files, so that the repository contains code, metadata, and small results rather than multi-gigabyte files that can never be merged.

**Starting a merge with uncommitted work.** Git needs a clean working tree to merge safely. Commit or stash your in-progress edits first, or you will spend an afternoon untangling a half-finished state.

**Resolving conflicts by accepting one side wholesale.** Deleting the HEAD block or the incoming block without reading both versions can silently erase a collaborator's change. Read each chunk, decide what the analysis requires, and write the combined version deliberately.

**Rebasing shared branches.** Rebase rewrites commit identifiers. If anyone has built on the branch, their work is orphaned. Rebase your own unpublished branches, merge everything else.

### Misconceptions That Slow Students Down

- **"A conflict means someone did something wrong."** Conflicts are the normal cost of parallel work, and the large-scale study of conflict resolutions shows they are typically small, chunk-level decisions [7].
- **"Merging destroys history."** The opposite is true. A merge commit preserves both parent lineages, and `git log, graph` makes that structure visible forever.
- **"Pull and merge are different things."** A pull is a fetch followed by a merge. If you understand merges, you understand pulls.
- **"No conflict means the results are unchanged."** Semantic conflicts produce clean merges and wrong numbers. Only rerunning the analysis tells you the truth.

## Quick Review

- A merge combines two branches and records a merge commit with two parents, preserving both histories.
- Git merges three ways, comparing both branch tips against their common ancestor, the merge base.
- Changes in different regions combine automatically. Competing changes to the same or neighboring lines stop the merge and request a decision.
- Conflict markers bracket the current branch's version (HEAD) and the incoming version. Resolve by editing the file to its final state, then `git add` and `git commit`.
- `git merge, abort` cancels a conflicted merge safely, which makes practicing merges low-risk.
- A clean merge is not a verified merge. Rerun tests and the pipeline before trusting the result.
- Small, short-lived branches merged frequently produce fewer conflicts and better build outcomes than long-lived branches.

## Frequently Asked Questions

### What does git merge for researchers mean?

It refers to the standard Git merge operation applied to research code, analysis pipelines, and manuscripts rather than commercial software. The interpretation is straightforward: parallel lines of work are combined into one branch through a single commit that records both histories, which is what allows a multi-person project to remain reproducible.

### Is a git merge the same as a pull request?

No. A merge is the core Git operation that combines two branches locally. A pull request is a hosted wrapper around a proposed merge, adding review, discussion, and automated checks before the merge is executed on GitHub.

### Should I merge or rebase in a research project?

Merge anything that is shared and rebase only your own branches that nobody else has pulled. Rebase rewrites commit identifiers, which orphans any collaborator's work built on top of the branch.

### How do I undo a merge in Git?

While a merge is paused on conflicts, run `git merge, abort` to return to the pre-merge state. For a completed merge you have not pushed, reset the branch to ORIG_HEAD. For a merge that has already been pushed and shared, create a new commit that reverts the merge instead of rewriting shared history.

### Why does Git report a conflict when we edited different lines?

Git merges in blocks of lines called chunks, and edits to neighboring lines can fall inside the same chunk even when they never overlap. These adjacent-line conflicts are common and are usually resolved by combining both edits into one block.

### Can Git merge large data files such as FASTQ or BAM?

No. Line-based merging applies to text files only. Binary files are treated as indivisible units, so a conflict forces you to pick one version. Keep large raw data out of the repository, or store it through a pointer-based system designed for large files, and let the repository hold code, metadata, and small derived results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does git merge for researchers mean?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It refers to the standard Git merge operation applied to research code, analysis pipelines, and manuscripts rather than commercial software. Parallel lines of work are combined into one branch through a single commit that records both histories, which is what allows a multi-person project to remain reproducible."
      }
    },
    {
      "@type": "Question",
      "name": "Is a git merge the same as a pull request?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. A merge is the core Git operation that combines two branches locally. A pull request is a hosted wrapper around a proposed merge, adding review, discussion, and automated checks before the merge is executed on GitHub."
      }
    },
    {
      "@type": "Question",
      "name": "Should I merge or rebase in a research project?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Merge anything that is shared and rebase only your own branches that nobody else has pulled. Rebase rewrites commit identifiers, which orphans any collaborator work built on top of the branch."
      }
    },
    {
      "@type": "Question",
      "name": "How do I undo a merge in Git?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "While a merge is paused on conflicts, run git merge, abort to return to the pre-merge state. For a completed merge you have not pushed, reset the branch to ORIG_HEAD. For a merge that has already been pushed and shared, create a new commit that reverts the merge instead of rewriting shared history."
      }
    },
    {
      "@type": "Question",
      "name": "Why does Git report a conflict when we edited different lines?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Git merges in blocks of lines called chunks, and edits to neighboring lines can fall inside the same chunk even when they never overlap. These adjacent-line conflicts are common and are usually resolved by combining both edits into one block."
      }
    },
    {
      "@type": "Question",
      "name": "Can Git merge large data files such as FASTQ or BAM?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Line-based merging applies to text files only. Binary files are treated as indivisible units, so a conflict forces you to pick one version. Keep large raw data out of the repository, or store it through a pointer-based system designed for large files, and let the repository hold code, metadata, and small derived results."
      }
    }
  ]
}
</script>

## Sources

1. [Version Control for Surgical Data Science: A Primer on Git and GitHub.](https://pubmed.ncbi.nlm.nih.gov/42893433/)
2. [Git can facilitate greater reproducibility and increased transparency in science](https://pubmed.ncbi.nlm.nih.gov/23448176/)
3. [A Rapid Transition from Subversion to Git: Time, Space, Branching, Merging, Offline commits & Offline builds and Repository aspects](https://doi.org/10.2174/2666255814666210621121914)
4. [EasyAmplicon: An easy-to-use, open-source, reproducible, and community-based pipeline for amplicon data analysis in microbiome research.](https://pubmed.ncbi.nlm.nih.gov/38868346/)
5. [Git Context Controller: Manage the Context of LLM-based Agents like Git](https://www.semanticscholar.org/paper/1e0f16bbdf17ac5955474fe7ff764a006ae87f38)
6. [EditFusion: Resolving Code Merge Conflicts via Edit Selection](https://doi.org/10.1109/ASE63991.2025.00055)
7. [Towards Semi-Automated Merge Conflict Resolution: Is It Easier Than We Expected?](https://doi.org/10.1145/3661167.3661197)
8. [Git Merge Conflict Resolution Leveraging Strategy Classification and LLM](https://doi.org/10.1109/QRS60937.2023.00031)
9. [Spork: Structured Merge for Java With Formatting Preservation](https://doi.org/10.1109/TSE.2022.3143766)
10. [Evaluation of Version Control Merge Tools](https://doi.org/10.1145/3691620.3695075)
11. [Assessing Impact of the Branching Strategy on Build Success of Software Projects](https://doi.org/10.1109/ACCESS.2026.3742166)