# How to Undo a Bad Merge in Git Without Losing Scientific Data

Most bad merges in research repositories are discovered within minutes of the merge itself, while the result is still on your own machine. You merged the wrong branch, you resolved a conflict toward the wrong side and quietly dropped a colleague's edits to an analysis script, or you pulled in generated files that buried the changes you cared about. In that most common case, the fix is a single command, because Git records where your branch pointed before the merge in a bookmark called ORIG_HEAD. The first thing to check is `git status`, which tells you whether the merge is still in progress or already committed, followed by `git reflog`, which lists every position your repository has passed through in reverse order. Those two commands tell you which recovery path below applies.

Two facts should steady your hands before you change anything. First, undoing a merge does not erase committed work. Git moves pointers rather than deleting objects, and a commit that drops off every branch stays listed in the reflog for weeks to months under default settings, so almost nothing that was ever committed is truly gone. Second, in a properly configured research repository, a merge cannot touch your irreplaceable data, because raw data does not belong in version control in the first place. Identifiable patient data must never enter a Git repository, and a .gitignore file is the standard tool for keeping data files, large outputs, and scratch directories out of the recorded history [1]. A bad merge threatens scripts, notebooks, configuration files, and committed result tables. It cannot delete the sequencing runs sitting on your backed-up storage that Git never tracked.

Four mental models anchor everything that follows. A repository is a project folder together with the complete history Git maintains inside it. A commit is an immutable snapshot of tracked files that carries a unique identifier called a SHA. A branch is a movable pointer to one commit, not a copy of the files. A remote is another copy of the repository, typically hosted on GitHub, that you push to and pull from. These four concepts, repository, commit, branch, and remote, form the foundation described in a recent primer on version control for surgical data science [1]. Three more terms appear constantly in this article. HEAD is the pointer to your current position in history, usually the tip of your current branch. The working tree is the set of files you actually see and edit on disk. The index, also called the staging area, holds the contents destined for your next commit.

## Why Research Repositories Produce Bad Merges

Major journals now request code availability statements at publication, yet most surgical trainees and faculty receive no formal training in version control, so research groups learn merge mechanics during real analyses rather than before them [1]. Knowing why merges fail makes the recovery options below feel predictable instead of arbitrary.

### The Mechanism of a Merge

A merge is a three-way comparison. Git locates the merge base, the most recent commit shared by both branches, and compares each branch against that base. Changes made on only one side are applied automatically. Where both sides changed the same region, Git reports a conflict and asks you to decide. The result is a merge commit with two parents, recorded in a fixed order. Parent 1 is the commit that sat on your branch before the merge, and parent 2 is the tip of the branch you merged in. That ordering matters later, because reverting a merge requires telling Git which parent counts as your side.

### The Causes, From Most Common to Rarest

1. **Long-lived parallel branches.** An analysis branch that lives for weeks drifts far from main. The longer the separation, the more overlapping edits and the harder the conflict decisions. Merging small and often is the single most effective prevention.
2. **Generated and binary files under version control.** Feature tables, saved R workspaces, alignment files, and variant callsets do not merge line by line. Git either refuses them or produces a conflict you resolve by picking one side, which is how a collaborator's updated results table gets clobbered.
3. **Notebooks with stored outputs.** A Jupyter notebook is a text file whose embedded plot outputs change on every run. Two collaborators who merely viewed the same notebook produce a conflict full of JSON noise that hides the real change.
4. **Multi-institution collaboration.** Workflows for surgical research explicitly include multi-institutional collaboration on shared code [1]. Different sites commit under different conventions and with different .gitignore coverage, so a merge between sites mixes real changes with formatting churn.
5. **Organizational mergers.** The same effect appears at institutional scale. When Finland's National Institute for Health and Welfare began operations in 2009, it was created by merging two established research institutes, and the new department combined social science, laboratory analytics, and prevention groups with long independent traditions [2]. A merged lab inherits codebases written under different assumptions, and the first merge between them is where those assumptions collide.
6. **Merging with a dirty working tree.** Uncommitted edits mixed into a merge make both the conflict resolution and any later abort unreliable.
7. **Resolving conflicts wholesale.** Choosing "accept theirs" on a whole file to make a conflict disappear is the classic way an analysis script loses a colleague's week of work while the merge reports success.
8. **History rewriting on shared branches.** A force push that overwrites a shared main branch is rarer than the causes above but produces the most alarmed email in the lab.

### What a Merge Can and Cannot Destroy

The merge command itself is conservative. It refuses to start if it would overwrite uncommitted changes to tracked files, and it never touches untracked files, which are files in the working tree that Git does not manage. What puts scientific work at risk is the combination of a bad merge with a destructive follow-up. A `git reset, hard` discards uncommitted changes in tracked files. A `git clean` deletes untracked files, and Git keeps no copy of those. Committed history survives almost everything short of garbage collection, because commits stay reachable through the reflog long after they leave a branch. The practical rule is simple. Files that were committed are nearly always recoverable. Files that were never committed are protected by nothing, so they belong outside the repository on backed-up, access-controlled storage.

## The First Ten Minutes: A Diagnostic Sequence

![Decision tree sorting a bad merge into abort, reset, revert or file restore based on whether it is in progress, pushed, or clobbered a file.](/article-images/illustrations/undo-git-merge-research-data-merge-triage.webp)

Run these steps in order and read the output before acting. Each step is safe and changes nothing.

1. `git status`. If you see "You have unmerged paths" or "All conflicts fixed but you are still merging", a merge is in progress and Scenario 1 applies. Note any list of unmerged paths.
2. `git rev-parse -q, verify MERGE_HEAD`. A printed identifier confirms a merge is in progress, silence confirms none is.
3. `git reflog, date=iso`. This lists recent positions of HEAD with labels such as HEAD@{0} for now and HEAD@{1} for the previous position. Find the entry just before the merge and write down its identifier. The reflog is local to your clone, which is why it survives even when a branch pointer has moved badly.
4. `git log, oneline, graph, decorate, all -20`. You should see the merge commit with its two parents and which branch arrived. Confirm that the merge is actually the damage.
5. `git stash list`. Stashes are saved work you may have forgotten, and you want to know about them before any reset.
6. `git branch rescue-20261111`, substituting today's date. This creates a branch pointing at your current position and costs nothing. Make this pointer before running any command described as destructive anywhere in this article. If a recovery goes wrong, the rescue branch is where you return.

## Troubleshooting Table: Match Your Symptom to the Fix

| Symptom | Likely cause | How to confirm | Fix |
|--|--|--|--|
| Conflict markers on screen, you want out of the merge | Merge still in progress | `git status` reports unmerged paths | `git merge, abort` (Scenario 1) |
| Merge committed minutes ago, nothing pushed | Local-only bad merge | `git reflog` shows the merge as the newest entry | `git reset, hard ORIG_HEAD` (Scenario 2) |
| Merge committed, but uncommitted edits must survive | Reset would discard them | `git status` lists modified tracked files | Stash, reset, then pop (Scenario 2) |
| Merge already pushed, colleagues have pulled | Shared history | `git status` shows your branch in sync with origin after the push | `git revert -m 1 <merge-id>` (Scenario 3) |
| Branch contributions missing after a revert | Reverted merge blocks a re-merge | `git log` shows a revert commit above the old merge | Revert the revert, then merge again (Scenario 3) |
| Commits vanished after a reset or checkout | HEAD moved away from them | `git reflog` still lists the commits | `git branch rescue <id>` (Scenario 4) |
| Reflog shows almost nothing | Fresh clone, or garbage collection ran | `git reflog` has few entries | `git fsck, lost-found` (Scenario 4) |
| A script has wrong content after a merge | Conflict resolved toward the wrong side | `git log -p, path/to/script.R` shows the loss | `git restore, source=<good-id>, path/to/script.R` (Scenario 5) |
| Binary file reported as unmerged | Binaries cannot merge | `git status` lists the path as unmerged | Pick a side with `git checkout, ours` or `-theirs` (Scenario 5) |
| Untracked data or intermediates disappeared after cleanup | `git clean` deleted them | `git fsck, lost-found` may find blobs | Restore from external backup, Git kept no copy |

## How to Fix a Bad Git Merge Without Losing Research Data

The six scenarios below cover how to undo a Git merge without losing research data, ordered from the most common situation to the rarest. Each one explains the mechanism first, because knowing what Git is doing turns a frightening command into a routine one.

### Scenario 1: The Merge Is Still in Progress

While a conflicted merge is unresolved, Git holds state in three places, the index, the working tree, and a file called MERGE_HEAD that records the commit being merged in. Abandoning the merge means erasing that state and returning the index and working tree to their pre-merge contents.

`git merge, abort` does exactly that. It reconstructs the pre-merge state and leaves your branch exactly as it was before you typed `git merge`.

**Safety note.** `git merge, abort` can fail to reconstruct uncommitted changes that existed before the merge started, and the Git documentation warns that those changes may be lost in some cases. Commit or stash your work before you begin any merge you might want to abandon.

If you want to keep the files as they currently sit, conflicts and all, and simply stop Git from treating a merge as in progress, use `git merge, quit`. The working tree and index are left as they are and the merge state is forgotten. This is useful when you have already resolved everything by hand and want to commit the result as an ordinary commit.

A related technique prevents bad merges before they happen. Start the merge without committing it, inspect the result, then abort if you dislike what you see:

```
git merge --no-commit --no-ff feature-analysis
git diff --staged
git merge --abort
```

The `-no-commit` flag stops the merge just before the commit is created, and `-no-ff` forces a real merge even when a fast-forward would suffice, so what you inspect is what a merge would actually produce. `git diff, staged` shows every change the merge would introduce. In a research setting this is a rehearsal, and it is the cheapest way to discover that a branch will overwrite the figure script you cared about.

### Scenario 2: The Merge Is Committed but Not Pushed

This is the most common bad merge and the most satisfying fix. Before a merge, rebase, or reset, Git records your branch's previous position in ORIG_HEAD. Resetting the branch back to that bookmark undoes the merge in one step.

```
git reset --hard ORIG_HEAD
git log --oneline -3
```

`git reset, hard ORIG_HEAD` moves the branch pointer back to the pre-merge commit and makes the working tree match it. The merge commit itself is not deleted, it simply falls off the branch and remains visible in `git reflog`, so even this operation is reversible. The same reset undoes an accidental `git pull` that created an unwanted merge commit.

**Safety note.** The `-hard` flag discards uncommitted changes in tracked files. Run `git status` first. If anything is modified or staged, stash it before resetting.

If you have uncommitted edits you want to keep, stash them first, reset, then bring them back:

```
git stash push -m "work in progress before undoing merge"
git reset --hard ORIG_HEAD
git stash pop
```

A stash is a commit-like object that holds uncommitted changes and removes them from the working tree, and `git stash pop` reapplies the most recent one. If the stashed edits conflict with the restored pre-merge files, Git reports the conflict in the working tree and leaves the stash in the list, so nothing is lost while you sort it out.

A gentler variant exists when your uncommitted edits might collide with the reset. `git reset, merge ORIG_HEAD` updates files that differ between the merge commit and the target but aborts itself rather than overwriting files that carry unstaged changes. Use it when `-hard` feels too blunt and stashing is awkward.

If ORIG_HEAD has been overwritten by some later operation, find the pre-merge position in `git reflog` instead and reset to that identifier directly, for example `git reset, hard HEAD@{2}`. Verify the result with `git log, oneline -5` and confirm the merge commit is no longer on the branch.

### Scenario 3: The Merge Is Already on the Shared Remote

Once a merge has been pushed to a remote that colleagues pull from, rewriting history stops being an option. Every commit identifier after the rewrite would change, and every clone built on the old identifiers would break in confusing ways. Multi-institution research depends on exactly this kind of shared repository workflow [1], so the correct tool is revert.

Revert removes nothing. It creates a new commit whose changes are the exact inverse of the commit you name. History keeps its shape, colleagues keep their clones, and the bad merge is recorded as recognized and reversed, which is a far better story for a methods section than a silently rewritten branch.

Find the merge commit and revert it relative to your side:

```
git log --oneline --graph -10
git show <merge-commit-id>
git revert -m 1 <merge-commit-id>
```

The `git show` output begins with a line such as `Merge: a1b2c3d e4f5a6b`. The first identifier is parent 1, your branch before the merge, and the second is parent 2, the branch that came in. The `-m 1` flag tells Git to invert the merge relative to parent 1, which is what "undo the changes this merge brought in" means in practice.

A revert of a merge can itself report conflicts, because the inverse must be applied to a codebase that has kept moving. Resolve them as you would merge conflicts, then run `git revert, continue`. If the revert is going badly, `git revert, abort` returns you to the pre-revert state. When the revert commit is in place, push normally. On GitHub, the same operation is available as a Revert button on any merged pull request, which opens a ready-made revert pull request for the lab to review.

### Redoing the Merge Later

Reverting a merge creates one follow-up obligation. If you later fix the feature branch and merge it again, Git will compare histories and conclude that those changes are already present, because the merge and its inverse both sit in history. The re-merge will silently bring back nothing. The Git project's own documentation describes this exact situation and its solution, which is to revert the revert first, restoring the branch's changes, and then merge the repaired branch properly.

`git revert <revert-commit-id>` creates that second inverse. Then merge the branch as usual. Teams that hit this pattern more than once usually adopt a convention, recording in the revert's commit message which future merge will need the revert of the revert.

### Scenario 4: Commits That Seem to Have Vanished

A reset or a checkout that moves in the wrong direction feels like data loss, but the commits are usually still on your disk. The reflog is a private, local journal of every position HEAD has occupied, updated on every commit, checkout, reset, and merge. It is not transferred by push, pull, fetch, or clone.

Read it with dates and act on the entry before the accident:

```
git reflog --date=iso
git branch rescue-analysis HEAD@{3}
```

`git branch rescue-analysis HEAD@{3}` creates a normal branch pointing at the third-previous position of HEAD, which makes the apparently lost commits reachable again and safe from garbage collection. Inspect with `git log, oneline rescue-analysis`, then either merge the rescue branch or lift individual commits onto your working branch with `git cherry-pick <commit-id>`, which copies a single commit's changes as a new commit.

Under default settings, reflog entries expire after 90 days, entries whose commits are no longer reachable from any branch or tag expire after 30 days, and garbage collection will not prune unreachable objects newer than two weeks. In practice you have a recovery window measured in weeks, not seconds, but it is a window, not a guarantee. Make the rescue branch the same day.

When the reflog itself is unhelpful, for example in a freshly cloned repository that never had the commits, search for dangling commits, which are commits that no reference points to:

```
git fsck --lost-found
```

Git writes any dangling commits it finds into `.git/lost-found/commit`, one file per commit, and you can create a branch from any of them by identifier. Dropped stashes are recovered the same way, because a stash is itself a commit. Find its identifier with `git fsck`, inspect it with `git show`, and branch from it.

**Safety note.** Do not run `git gc`, `git gc, prune=now`, or any command that prunes objects while you are still recovering. Pruning can permanently erase the very commits you are looking for. The reflog also covers only committed work. Files that were never committed are invisible to every command in this section.

### Scenario 5: A Merge Clobbered a Script or a Results File

The merge completed, everyone said the conflicts were resolved, and a week later the analysis script no longer runs. The usual mechanism is a conflict resolved toward the wrong side, so one branch's edits to a file were discarded while the merge reported success. File-level recovery fixes this without touching the rest of the history.

First, list every commit that touched the file and read what changed:

```
git log --oneline -- path/to/analysis.R
git log --oneline --follow -- path/to/analysis.R
git show <commit-id>:path/to/analysis.R
```

The `-follow` option keeps listing through renames. `git show <commit-id>:path` prints the file exactly as it existed at that commit, which lets you compare the version you expected against the version the merge produced. To see the precise difference between a known-good commit and the merge commit for that one file, use `git diff <good-id> <merge-id>, path/to/analysis.R`. During an unresolved conflict, `git log, merge, oneline, path` lists the commits from both sides that touched the file, which tells you whose edit is at stake.

Restore the good version into your working tree, review it, and commit:

```
git restore --source=<good-id> -- path/to/analysis.R
git diff
git add path/to/analysis.R
git commit -m "Restore analysis script lost in merge resolution"
```

`git restore, source` writes the file from the named commit into the working tree without touching anything else, and `git diff` shows exactly what you are about to bring back. The older equivalent, `git checkout <good-id>, path`, also stages the file. If the merge deleted the file outright, the same restore command brings it back from any commit that contained it. The identical workflow recovers a committed results table, a figure script, or a pipeline configuration.

For future merges, remember the division of labor. Committed intermediate results are recoverable this way, but raw data is not in the repository at all, because patient-identifiable files must stay out of version control and .gitignore keeps them out [1]. If a merge appears to have destroyed your data, what it actually destroyed is a pointer, a script, or a results file, and the data itself should still be on your backed-up storage.

**Safety note.** If patient-identifiable data was committed to a repository by mistake, do not attempt to clean it up with history rewriting on your own. Treat it as a reportable incident, involve your institution's data security office, and remember that every clone retains the file even after the history is rewritten.

### Binary Files That Refuse to Merge

Feature tables, alignment files, and saved R workspaces are binary files, and Git cannot merge them line by line. During a merge, Git marks the path as unmerged and stops. You choose which version to keep:

```
git checkout --ours -- results/feature_table.biom
git checkout --theirs -- results/feature_table.biom
git add results/feature_table.biom
```

`-ours` keeps the version on the branch you were on, and `-theirs` keeps the incoming version. If both versions matter, copy one aside before choosing, then reconcile the contents by hand. The durable fix is to stop tracking generated outputs and cover them with .gitignore, so merges only ever negotiate source files.

### Scenario 6: When You Must Rewrite a Branch You Own

Sometimes a bad merge sits on a feature branch that only you use, pushed to your own fork as a backup. There, rewriting is legitimate, because nobody builds on your branch. Undo the merge locally as in Scenario 2, then update the remote copy with a force push that refuses to clobber anyone else's work:

```
git reset --hard ORIG_HEAD
git push --force-with-lease origin feature-analysis
```

`-force-with-lease` overwrites the remote branch only if it still points where your last fetch showed it pointing. If a collaborator or an automated build pushed in the meantime, the push is refused instead of erasing their work. Plain `-force` overwrites unconditionally and should not be used on any branch another person can see.

**Safety note.** Never force push to a shared main branch. On GitHub, repository settings can protect branches so that force pushes and history rewrites are rejected by the server, which turns this entire class of accident into an impossible one.

## Prevention: Merging Without Fear in Scientific Projects

### Before Every Merge

1. Reach a clean state. Commit or stash everything and confirm with `git status` that the working tree is clean. Aborting a merge is only reliably reversible from a clean starting point.
2. Drop a rescue pointer. `git branch backup/pre-merge` takes one second and gives every later command a safe return address.
3. Preview the incoming work. `git log, oneline HEAD..feature-analysis` lists exactly what the merge would bring. For a full rehearsal, run the dry-run merge from Scenario 1 and read `git diff, staged`.
4. Rehearse on a scratch branch. Check out a throwaway branch, merge there, and run a short smoke test of the pipeline. If the merged code breaks the analysis, you learn it without touching main.
5. Merge, then test, then push. Run the smallest analysis that would catch a broken script before the merge reaches the remote.

### Repository Hygiene That Prevents Bad Merges

Commit small and often. The daily edit-stage-commit cycle, in which you edit files, stage the changes, and record a commit, is the dominant workflow described in primers written for research groups [1]. Small commits make conflicts smaller and make every recovery scenario in this article easier, because the good version of any file is never far back.

Work on feature branches and integrate through pull requests. Branches isolate risky work, and a pull request gives a colleague the chance to read a conflict-prone change before it lands on main, which is the collaboration pattern recommended for research teams [1].

Keep data and generated files out of the repository. A .gitignore file listing data directories, large outputs, notebook checkpoints, and scratch folders prevents inadvertent commits and, as a side effect, removes the binary conflicts that make merges dangerous [1]. Raw clinical data belongs in access-controlled, backed-up storage, never in Git.

Make pulls predictable. `git config pull.rebase true` replays your local commits on top of incoming work instead of creating a surprise merge commit, which removes one whole category of accidental merge.

Adopt mature, versioned pipelines where they exist. EasyAmplicon, for example, is an open-source amplicon analysis pipeline that integrates more than 30 cross-platform modules and R packages inside RStudio, is maintained by its authors, and offers user support through its GitHub presence with regular tutorial updates [3]. Pipelines like this give you versioned releases to pin in your methods, instead of a private tangle of scripts whose merge history only one person understands.

### Versioning for Publication and Reproducibility

Tag the exact code state used for each result. `git tag -a v1.0-manuscript -m "Analysis as submitted"` marks a snapshot permanently, and the tag name belongs in your methods or code availability statement. Journals increasingly request code availability at publication [1], and a tag pushed to GitHub with `git push origin v1.0-manuscript` is the artifact that satisfies a reviewer who asks to reproduce a figure. Record the pipeline version alongside it, because a reproducible analysis is defined by both your own commit and the versions of the community tools it depends on [3].

## Common Mistakes and Limitations

- Running `git reset, hard` with a dirty working tree. This is the most common self-inflicted loss in research repositories. Check `git status` and stash first.
- Confusing revert with reset. Revert adds a new, inverse commit and is safe on shared branches. Reset moves a branch pointer and rewrites what others see once pushed. Choosing reset for a pushed merge creates the second emergency.
- Force pushing to a shared branch instead of reverting. This changes every identifier after the rewrite and breaks every colleague's clone.
- Trusting the reflog on a fresh clone. The reflog is local to each clone and starts nearly empty. Commits that existed only on a lost laptop are gone unless they were pushed.
- Treating `git clean` as routine tidying. `git clean -fd` permanently deletes untracked files and directories, and Git has no copy of untracked work. Preview with `git clean -nd` first, and keep data files ignored and backed up rather than sitting untracked in the working tree.
- Committing in a detached HEAD and wandering away. Commits made while HEAD points directly at a commit instead of a branch are easy to lose track of after a checkout. They remain in the reflog, so search there before assuming loss.
- Deleting the `.git` directory to start over. This destroys the reflog, the stashes, and every recovery path in this article in one stroke. Create a fresh clone in a new folder instead if you want a clean start.
- Expecting Git to protect what it never stored. Every command in this article recovers committed objects. Uncommitted, untracked files are outside Git's protection entirely.

One limitation deserves a plain statement. Repository histories differ, so verify the output of each command before running the next, and if a repository contains regulated human data, involve your institution's data security office before sharing it or rewriting its history.

## Frequently Asked Questions

### What is the quickest way to undo a merge I just made?

If the merge is committed but not pushed, `git reset, hard ORIG_HEAD` returns your branch to its pre-merge state after you stash any uncommitted work. If the merge is still showing conflicts, `git merge, abort` cancels it. If it is already pushed, revert the merge commit instead of rewriting history.

### Will undoing a merge delete my scientific data?

Almost never, as long as the work was committed. Git moves pointers rather than erasing objects, and the reflog keeps dropped commits recoverable for weeks. Raw data files should not be in the repository at all, so a merge cannot touch them. The real risk is uncommitted, untracked files, which Git does not protect.

### What is the difference between git revert and git reset?

Revert creates a new commit that inverts an earlier commit and leaves history intact, which makes it safe on shared branches. Reset moves a branch pointer to another commit, which changes history once pushed. Use revert for anything colleagues can see and reset only for local mistakes.

### How do I cancel a merge that is stuck on conflicts?

Run `git merge, abort`, which restores the pre-merge state of the index and working tree. Commit or stash your own edits before starting a merge, because an abort may be unable to reconstruct changes that predated it.

### Can I undo a merge that other people have already pulled?

Yes, with a revert rather than a rewrite. `git revert -m 1 <merge-commit>` adds an inverse commit that colleagues receive through a normal pull. On GitHub, the Revert button on a merged pull request prepares the same operation for review.

### How do I merge the same branch again after reverting it?

Revert the revert first, then merge. Git otherwise considers the branch's changes already present in history, and the new merge would bring back nothing. The Git project documents this revert-of-revert pattern in its own guides.

### How long can I wait before a lost commit is gone for good?

Weeks to months by default. The reflog keeps entries long after a branch pointer moves, and garbage collection waits before pruning unreachable objects, but the window is not infinite. Create a rescue branch from the reflog the same day and the deadline stops mattering.

### How do I keep patient data out of my Git repository?

Store raw data in access-controlled, backed-up storage outside the repository, and list data directories and large outputs in a .gitignore file so they cannot be committed by accident. Commit code, scripts, and small configuration files only.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the quickest way to undo a merge I just made?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "If the merge is committed but not pushed, reset your branch to ORIG_HEAD after stashing any uncommitted work. If the merge is still showing conflicts, abort it to return to the pre-merge state. If it is already pushed, revert the merge commit instead of rewriting history."
      }
    },
    {
      "@type": "Question",
      "name": "Will undoing a merge delete my scientific data?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Almost never, as long as the work was committed. Git moves pointers rather than erasing objects, and the reflog keeps dropped commits recoverable for weeks. Raw data files should not be in the repository at all, so a merge cannot touch them. The real risk is uncommitted, untracked files, which Git does not protect."
      }
    },
    {
      "@type": "Question",
      "name": "What is the difference between git revert and git reset?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Revert creates a new commit that inverts an earlier commit and leaves history intact, which makes it safe on shared branches. Reset moves a branch pointer to another commit, which changes history once pushed. Use revert for anything colleagues can see and reset only for local mistakes."
      }
    },
    {
      "@type": "Question",
      "name": "How do I cancel a merge that is stuck on conflicts?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Abort the merge, which restores the pre-merge state of the index and working tree. Commit or stash your own edits before starting a merge, because an abort may be unable to reconstruct changes that predated it."
      }
    },
    {
      "@type": "Question",
      "name": "Can I undo a merge that other people have already pulled?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, with a revert rather than a rewrite. Reverting the merge commit adds an inverse commit that colleagues receive through a normal pull. On GitHub, the Revert button on a merged pull request prepares the same operation for review."
      }
    },
    {
      "@type": "Question",
      "name": "How do I merge the same branch again after reverting it?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Revert the revert first, then merge. Git otherwise considers the branch's changes already present in history, and the new merge would bring back nothing. The Git project documents this revert-of-revert pattern in its own guides."
      }
    },
    {
      "@type": "Question",
      "name": "How long can I wait before a lost commit is gone for good?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Weeks to months by default. The reflog keeps entries long after a branch pointer moves, and garbage collection waits before pruning unreachable objects, but the window is not infinite. Create a rescue branch from the reflog the same day and the deadline stops mattering."
      }
    },
    {
      "@type": "Question",
      "name": "How do I keep patient data out of my Git repository?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Store raw data in access-controlled, backed-up storage outside the repository, and list data directories and large outputs in a .gitignore file so they cannot be committed by accident. Commit code, scripts, and small configuration files only."
      }
    }
  ]
}
</script>

## Sources

1. [Version Control for Surgical Data Science: A Primer on Git and GitHub.](https://pubmed.ncbi.nlm.nih.gov/42893433/)
2. [Addiction research centres and the nurturing of creativity: the Department of Alcohol, Drugs and Addiction at the National Institute for Health and Welfare in Finland: diverse problems, diverse perspectives.](https://pubmed.ncbi.nlm.nih.gov/21992550/)
3. [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/)