# GitHub for Earth Science Researchers

By the end of this article you will be able to create a version-controlled analysis repository, track changes to your scripts and small data files, protect sensitive or restricted files from accidental commits, publish your code on GitHub with a license and README, collaborate with coauthors through branches and pull requests, and hand a reviewer a reproducible package of code and metadata. To follow along you need a computer with a terminal (Git Bash on Windows, the built-in Terminal on macOS or Linux), a free GitHub account, and about an hour. No prior software engineering experience is required.

Earth science research now runs on code. Species distribution models, hydrologic sensor processing, remote sensing classification, and geochemical pipelines all produce results through scripts, and major journals increasingly request code availability statements at submission [1]. A spatiotemporal mapping study of soil organic carbon density across Europe, for example, combined 45,616 field observations with stacks of Earth observation layers to produce 30 m resolution maps over two decades, along with per-pixel uncertainty estimates [2]. Work at that scale cannot be reproduced from a folder called "final_v3_FINAL" on a lab hard drive. Version control with Git, hosted on GitHub, is the standard solution, and this article walks through it from first commit to published repository.

## Why Git for Scientists

Git is a distributed version control system. It records a snapshot of every file in a project each time you commit, so you can return to any earlier state, compare versions line by line, and experiment on separate branches without breaking the working copy. GitHub is a hosting platform built on top of Git. It stores your repositories in the cloud, adds collaboration features such as pull requests and issue tracking, and gives your work a public address that journals, reviewers, and collaborators can cite.

For scientists the payoff is concrete:

- Every figure can be traced back to the exact script version and input files that produced it.
- A collaborator at another institution can propose changes without emailing edited copies of your files.
- When a reviewer asks how a result was computed, you send a link instead of a zip archive.
- Mistakes are recoverable. Deleting a block of analysis code three weeks ago is not a disaster, because every commit still holds it.

Git and GitHub were built for software teams, but the same workflow fits research code well. A primer on version control in surgical data science describes four mental models that form the entire basis of Git usage: the repository, the commit, the branch, and the remote [1]. Earth scientists can adopt the same four ideas, because the problems they solve are identical, whether the input is a registry of surgical cases or a decade of stream gauge readings.

## The Four Mental Models

You only need four concepts to use Git competently.

**Repository.** A repository (or repo) is a project folder that Git tracks, plus a hidden `.git` directory inside it that stores the full history. A repo usually holds one analysis: one manuscript's pipeline, one model's code, one dataset's processing scripts.

**Commit.** A commit is a named snapshot of the tracked files at a moment in time. Each commit has a unique identifier (a 40-character hash, usually shortened to 7 characters such as `a3f9c21`), an author, a timestamp, and a message you write. Commits form a chain, so history is a sequence of labeled states you can revisit.

**Branch.** A branch is an independent line of work. The default branch (named `main` on GitHub) holds the stable version of your project. A feature branch lets you develop a new analysis or fix without touching the stable code until it is ready.

**Remote.** A remote is a copy of the repository hosted elsewhere, almost always on GitHub. You push commits to the remote to back them up and share them, and you pull commits from it to receive other people's work.

Everything else in day-to-day Git follows from these four ideas [1].

## A Step-by-Step Walkthrough

This section is a practical, command-level guide for github for earth science researchers. Work through it in order on a sample project.

### Step 1. Install and configure Git

Install Git from your operating system's package manager or from the official installers. On Windows, install Git for Windows, which provides Git Bash. On macOS, `xcode-select, install` provides Git. On Linux, use your distribution's package manager.

Open a terminal and confirm the installation:

```bash
git --version
```

Expected output (the exact number will differ):

```
git version 2.47.0
```

Set your identity, which Git attaches to every commit you make. Use the email address associated with your GitHub account.

```bash
git config --global user.name "Maria Alvarez"
git config --global user.email "malvarez@example.edu"
git config --global init.defaultBranch main
```

The `-global` flag writes these settings to your user-level configuration so they apply to every repository on the machine. Verify with:

```bash
git config --global --list
```

Expected output includes:

```
user.name=Maria Alvarez
user.email=malvarez@example.edu
init.defaultbranch=main
```

### Step 2. Create a repository

Make a project folder and turn it into a repository:

```bash
mkdir soil-carbon-analysis
cd soil-carbon-analysis
git init
```

Expected output:

```
Initialized empty Git repository in /home/maria/soil-carbon-analysis/.git/
```

The `.git` directory now holds the history database. Never edit files inside it directly.

Add a README describing the project. Every repository you ever publish should have one, because it is the first thing a visitor reads on GitHub.

```bash
cat > README.md << 'EOF'
# Soil Carbon Analysis

Scripts for mapping soil organic carbon density from
field observations and Earth observation covariates.

## Contents
- data/ : input tables (not tracked, see .gitignore)
- src/  : processing and modeling scripts
- env/  : environment specification
EOF
```

### Step 3. Learn the edit-stage-commit cycle

![Flow of edit, stage, commit and review steps, with the Git command used at each step.](/article-images/illustrations/github-for-earth-science-researchers-commit-cycle.webp)

The daily workflow in Git is a three-step loop: edit files, stage the changes, commit them [1]. Staging is a deliberate selection step, which is what lets you commit some changes while leaving others out.

Check what Git sees:

```bash
git status
```

Expected output:

```
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)
```

Stage and commit:

```bash
git add README.md
git commit -m "Add README with project overview"
```

Expected output:

```
[main (root-commit) a3f9c21] Add README with project overview
 1 file changed, 9 insertions(+)
 create mode 100644 README.md
```

The message after `-m` should say what changed and why. Write it for the version of yourself in six months. Short, present-tense messages work well: "Add quantile regression forest script", "Fix CRS mismatch in covariate stack", "Remove duplicated sensor QA filter".

View your history at any time:

```bash
git log --oneline
```

Expected output:

```
a3f9c21 Add README with project overview
```

To see exactly what changed before committing, use:

```bash
git diff
```

Red lines starting with `-` are deletions, green lines starting with `+` are additions. To stage a change and then unstage it, use:

```bash
git add README.md
git restore --staged README.md
```

### Step 4. Protect sensitive files before your first commit

In clinical research the rule is absolute: identifiable patient data must never enter a version-controlled repository, and a `.gitignore` file is the standard guard against inadvertent commits [1]. Earth science has an analogous rule. Restricted ecological records (for example precise locations of protected species), licensed imagery you are not permitted to redistribute, confidential contract data, and files containing API keys or credentials must stay out of Git.

Create a `.gitignore` in the repository root before you add anything else:

```bash
cat > .gitignore << 'EOF'
# Raw field data with restricted coordinates
data/raw/
data/*_restricted.csv

# Large model outputs
*.nc
*.tif
outputs/

# Credentials
.env
credentials*.json

# Editor and system clutter
.DS_Store
*.pyc
__pycache__/
EOF
git add .gitignore
git commit -m "Add gitignore for restricted data and large outputs"
```

Patterns in `.gitignore` can name specific files, use wildcards such as `*.tif`, or exclude whole directories such as `data/raw/`. Once a file is ignored, `git status` stops listing it, which removes the temptation to commit it in bulk. The `.gitignore` guard works only if it exists before the sensitive file is added, which is why this step belongs early in every new repository [1].

### Step 5. Connect the repository to GitHub

Create an empty repository named `soil-carbon-analysis` on GitHub through the web interface, leaving it without a README so it stays empty. Then connect your local repo and push:

```bash
git remote add origin git@github.com:malvarez-lab/soil-carbon-analysis.git
git push -u origin main
```

Expected output:

```
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 254 bytes | 254.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:malvarez-lab/soil-carbon-analysis.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
```

Two parameters matter here. `origin` is the conventional name for the primary remote. The URL determines the transport: an `ssh` address (`git@github.com:...`) uses key-based authentication after you upload an SSH public key in your GitHub account settings, while an `https` address (`https://github.com/...`) authenticates with a token or credential helper. Set up SSH once and daily pushes become frictionless. The `-u` flag links your local `main` to `origin/main` so later pushes need only `git push`.

To copy an existing project (yours or someone else's) to a new machine, use:

```bash
git clone git@github.com:malvarez-lab/soil-carbon-analysis.git
```

### Step 6. Branch, develop, and merge

Branches let you try an alternative model specification without destabilizing the working pipeline:

```bash
git switch -c qrf-uncertainty
```

This creates and moves to a branch named `qrf-uncertainty`. Work normally, committing as you go. When the branch is ready, integrate it:

```bash
git switch main
git merge qrf-uncertainty
git push
git branch -d qrf-uncertainty
```

### Step 7. Open a pull request for coauthored work

When collaborators are involved, do not merge your own branch directly. Push the branch to GitHub, open a pull request (a proposal to merge one branch into another, with a discussion thread and a visible diff), and let a coauthor review it. This review step is how research teams catch errors before they reach the main pipeline, and it is the standard collaboration pattern in both open source software and multi-institutional research projects [1].

## Collaborating and Sharing Credit

Research commits rarely belong to one person. A graduate student writes the script, a postdoc refines the statistical treatment, and the principal investigator suggests the framing. GitLab and GitHub support this reality with the `Co-Authored-By:` trailer, a line added to a commit message that credits additional contributors, and empirical work on the OpenStack ecosystem, covering roughly one million commits across 1,804 repositories over nine years, shows that these micro-collaboration mechanisms are actively used and can be studied to understand how distributed teams actually work together [3].

Add a trailer when you commit work that involved others:

```bash
git commit -m "Add cross-validation for depth intervals" -m "Co-Authored-By: J. Chen <jchen@example.edu>"
```

GitHub renders the credited account as a co-author on the commit, which matters for tenure packets, authorship disputes, and honest reporting of who built what. In an analysis of OpenStack contributors, interviews combined with commit-history statistics showed that coordinated contributions to shared changes are a real and measurable part of collaborative practice, not an edge case [3]. Research groups adopting GitHub should treat co-author trailers as part of their authorship policy, decided before the first commit rather than argued about at submission time.

## GitHub and FAIR Earth Science Data

Version-controlling code is half of reproducibility. The other half is data and metadata that other people can find, access, understand, and reuse, which is the FAIR framework: Findable, Accessible, Interoperable, Reusable. Community efforts in Earth and environmental science have produced 11 reporting formats, meaning instructions, templates, and tools for consistently formatting data within a discipline. These span cross-domain metadata such as dataset, location, and sample metadata, file-level guidance including CSV file conventions and terrestrial model data archiving, and domain-specific formats for amplicon abundance tables, leaf-level gas exchange, soil respiration, water and sediment chemistry, and sensor-based hydrologic measurements [4].

The practical connection to GitHub is straightforward. Use the relevant reporting format for your domain when you prepare the [tabular data](/blog/research-skills/tabular-data-what-it-is-and-how-to-analyze-it) that sit alongside your scripts, follow the CSV guidelines for column names and units, and document dataset-level metadata in a machine-readable file inside the repository. When your data follow a recognized community format, a stranger (or a reviewer, or your future self) can parse your files without emailing you [4]. A repository that combines versioned scripts with consistently formatted, well-documented data is the cheapest reproducibility package you can build.

Where should data live? GitHub handles small text-based files well, but it is not a data archive for large binary rasters or long time series. A common and effective pattern is to keep code and small metadata on GitHub, keep large data in an institutional or domain repository, and record in the README exactly which data files and versions the scripts expect. Domain journals and data journals increasingly expect this split, and journal code availability statements can be satisfied by linking the public repository [1].

## Worked Example: Structuring an Earth Science Repository

Consider the structure of a published, reproducible project. A root-system analysis method called STARSEED, which applies the Earth Mover's Distance to compare root system distributions across genotypes and soil moisture treatments, released both code and data publicly on GitHub at `github.com/GatorSense/STARSEED` [5]. That single URL let readers verify every figure in the paper, which is exactly the standard Earth science publishing is moving toward.

A similar layout for a modeling project looks like this in your file tree:

```
soil-carbon-analysis/
├── README.md
├── LICENSE
├── .gitignore
├── env/environment.yml
├── data/metadata.csv
├── src/01_clean_observations.py
├── src/02_build_covariates.py
├── src/03_fit_spacetime_rf.py
├── src/04_predict_and_validate.py
```

The numbered script names encode the execution order. The `environment.yml` file records the software environment (for a conda-managed Python environment) so a reviewer can recreate it:

```yaml
name: soilcarbon
channels:
  - conda-forge
dependencies:
  - python=3.11
  - rasterio
  - scikit-learn
  - pandas
  - matplotlib
```

Commit the environment file and README, keep large rasters out of Git, and tag a release when the manuscript is accepted:

```bash
git tag -a v1.0 -m "Release accompanying accepted manuscript"
git push origin v1.0
```

A tagged release gives the journal and readers a fixed, citable snapshot of the exact code that produced the published figures, which is precisely what reviewer reproducibility requests ask for [1]. The same pattern applies across computational fields, where benchmark studies of deep learning methods for structure prediction establish rigorous evaluation frameworks and make methods comparable only when the underlying code is inspectable [6].

## Key Commands Reference

| Command | What it does | When you use it |
|--|--|--|
| `git init` | Creates a new repository in the current folder | Starting any project |
| `git status` | Shows modified, staged, and untracked files | Constantly, to orient yourself |
| `git add <file>` | Stages a file for the next commit | Every commit cycle |
| `git commit -m "message"` | Records a snapshot with a message | Every meaningful unit of work |
| `git log, oneline` | Lists compact commit history | Reviewing what happened |
| `git diff` | Shows unstaged changes line by line | Before committing |
| `git switch -c <name>` | Creates and moves to a new branch | Starting new work |
| `git merge <branch>` | Integrates a branch into the current one | Finishing a feature |
| `git remote add origin <url>` | Connects local repo to GitHub | Once per repository |
| `git push -u origin main` | Uploads commits and sets tracking | First push, then plain `git push` |
| `git pull` | Downloads and integrates remote commits | Before starting work each day |
| `git clone <url>` | Copies a remote repository locally | New machine, new collaborator |
| `git restore, staged <file>` | Unstages a file | Staged something by accident |
| `git revert <hash>` | Creates a commit that undoes an earlier one | Undoing published changes safely |
| `git reset, soft HEAD~1` | Moves back one commit, keeps changes staged | Undoing an unpushed commit |
| `git tag -a v1.0 -m "msg"` | Marks a named, permanent point in history | Manuscript acceptance, releases |

## Recovering From Mistakes

![A yes or no path through the recovery scenarios: revert pushed commits, reset unpushed ones, revoke credentials or restore a file.](/article-images/illustrations/github-for-earth-science-researchers-recovery-path.webp)

A version control primer for research teams demonstrates three recovery scenarios, and the same scenarios account for most panic in a scientist's first month of Git [1].

**Scenario 1. You committed a file you should not have, and you have not pushed.** Remove it from history while keeping the file on disk:

```bash
git reset --soft HEAD~1
git restore --staged secrets.csv
```

The commit disappears, the file edits remain. If the sensitive file must never be tracked at all, add it to `.gitignore` in the same round of fixes.

**Scenario 2. You committed a bad change that is already pushed.** Do not rewrite public history. Create a new commit that reverses it:

```bash
git revert a3f9c21
git push
```

`git revert` computes the inverse of the named commit and records it, so history stays intact and collaborators stay in sync.

**Scenario 3. You deleted or damaged working code and need an earlier version.** Find the commit you want in `git log`, then restore a file from it:

```bash
git log --oneline src/03_fit_spacetime_rf.py
git restore --source a3f9c21 src/03_fit_spacetime_rf.py
```

The file on disk reverts to that snapshot while the repository history stays unchanged. Because every commit is a complete snapshot, nothing committed is ever truly lost until you delete the repository itself [1].

## Common Mistakes and Limitations

These are the errors that cost earth science researchers the most time, listed with their exact symptoms and fixes.

**Committing large data files.** GitHub warns about files above 50 MB and rejects files above 100 MB. Attempting to push a 2 GB NetCDF produces:

```
remote: error: GH001: Large files detected.
remote: error: File covariates_2020.tif is 412.00 MB; this exceeds GitHub's file size limit of 100.00 MB
```

The fix is to remove the file from the commit before pushing (using the reset workflow above) and to store large data externally, documenting its source in the README.

**Committing credentials.** API keys for cloud computing platforms and data services end up in pushed repositories with alarming regularity. When it happens, deleting the file in a later commit is not enough, because history still contains it. Treat the credential as compromised, revoke and regenerate it, and use `.gitignore` from the start to prevent recurrence [1].

**Waiting too long between commits.** A commit every two weeks bundles dozens of unrelated changes into one snapshot, which defeats the purpose of history. Commit after each unit of work: one script fixed, one figure regenerated, one function refactored.

**Vague commit messages.** "Update code" tells nobody anything. Write messages that name the change and the reason.

**Ignoring the staging step.** Running `git add .` blindly stages everything, including the 400 MB download in your working folder. Inspect `git status` first, stage deliberately, and let `.gitignore` do the standing guard duty [1].

**Treating GitHub as a data archive.** GitHub is excellent for code, small tables, and documentation, and unsuitable as the system of record for large datasets or long-term preservation. Pair your repository with a domain data repository and [persistent identifiers](/knowledge/bioinformatics/persistent-identifiers-in-bioinformatics-selection-criteria-and-implementation-workflow).

**Assuming a clone includes secrets and untracked files.** `git clone` copies tracked, committed content only. If a collaborator clones your repo and the raw sensor tables are missing, that is the `.gitignore` working as designed. Document where those files come from and how to obtain them.

Two limitations deserve honest mention. First, Git has a learning curve measured in days, not hours, and the first merge conflict is universally unpleasant. The investment pays for itself the first time a hard drive fails or a reviewer asks a provenance question. Second, version control documents the code, not the science. A beautifully versioned repository with no README, no environment specification, and no metadata is not reproducible, because reproducibility lives at the intersection of code, data, and documentation described by FAIR practice [4].

## Tips for a Sustainable Workflow

A set of practical github for earth science researchers tips, drawn from what works in research settings:

1. Commit early, commit small. Small commits make messages meaningful and reverts surgical.
2. Pull before you push. If a collaborator pushed overnight, `git pull` first avoids most rejected-push errors.
3. Branch for every distinct analysis. A branch per model variant or manuscript revision keeps `main` always runnable.
4. Write the README on day one. Future you, reviewers, and readers all enter through that file.
5. Record the software environment and commit it. An `environment.yml` or equivalent file turns "works on my machine" into a reproducible instruction.
6. Use pull requests for any change another person will be graded on or will need to defend. Review is cheaper than retraction.
7. Use co-author trailers so commit history matches the real division of labor [3].
8. Adopt a community reporting format for your data tables before writing custom parsers. Eleven formats already cover much of Earth science, from soil respiration to hydrologic sensor data [4].
9. Tag a release at manuscript submission and again at acceptance. Fixed snapshots answer reviewer questions definitively.
10. Never commit data you are not licensed to redistribute, and never commit anything whose disclosure would harm a person, a site, or a species.

One more tip comes straight from practice. A version control primer for surgical research walks through installing a community-developed open-source tool by cloning its repository and following its documentation, illustrating how quickly published GitHub repositories become part of the working toolkit [1]. The habit runs both directions: you will clone other researchers' repositories weekly, so publish yours at the standard you wish to find.

## Frequently Asked Questions

### What is the difference between Git and GitHub?

Git is the version control program that runs on your computer and records snapshots of your project. GitHub is a website that hosts Git repositories online and adds collaboration features such as pull requests, issues, and code review. You use Git constantly and GitHub whenever you want backup, sharing, or collaboration.

### Do I need to learn command-line Git before using GitHub?

No, but it helps. GitHub's desktop application and web editor can carry you through basic commits, and many researchers start that way. Learning the command line unlocks the full edit-stage-commit cycle, branching, and recovery commands, which is where Git becomes genuinely powerful for research work [1].

### Should I put my research data on GitHub?

Small, shareable text files such as metadata, processed summary tables, and environment specifications belong in the repository. Large binary files such as rasters and NetCDF archives, and any restricted or sensitive data, belong in a dedicated data repository with the location documented in your README. Sensitive records must never enter version control at all [1].

### How do I handle large raster or NetCDF files in a GitHub project?

Keep them out of Git. GitHub rejects individual files above 100 MB and warns above 50 MB. Store large files on institutional storage or a data repository, commit a small README entry describing each file, its source, and its version, and if needed provide a small script that downloads and verifies the data.

### How do I undo a bad commit?

If you have not pushed yet, `git reset, soft HEAD~1` steps back one commit while keeping your changes. If you have pushed, use `git revert <hash>` to create a new commit that undoes the old one without rewriting history. All three common recovery situations, including restoring a single file from an earlier snapshot, have straightforward command-level solutions [1].

### How do I give credit to collaborators on individual commits?

Add a `Co-Authored-By:` trailer to the commit message with each contributor's name and email. GitHub displays those accounts as co-authors on the commit. Research on large open source ecosystems shows these micro-collaboration trailers are a real, measurable part of how distributed teams share credit on shared work [3].

### What should I do if I accidentally committed a sensitive file?

Immediately remove it from tracking, add it to `.gitignore`, and revoke or regenerate any credential the file contained, because anything pushed must be treated as exposed. History rewrite tools exist, but credential rotation and prevention through `.gitignore` are the reliable responses [1].

### How do I share my code with journal reviewers?

Push the repository to GitHub, tag a release so the exact version is fixed, and cite that repository or release in your code availability statement, which many journals now request at submission [1]. Include a README, the software environment specification, and either the data or a documented link to where the data are archived.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the difference between Git and GitHub?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Git is the version control program that runs on your computer and records snapshots of your project. GitHub is a website that hosts Git repositories online and adds collaboration features such as pull requests, issues, and code review. You use Git constantly and GitHub whenever you want backup, sharing, or collaboration."
      }
    },
    {
      "@type": "Question",
      "name": "Do I need to learn command-line Git before using GitHub?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No, but it helps. GitHub's desktop application and web editor can carry you through basic commits. Learning the command line unlocks the full edit-stage-commit cycle, branching, and recovery commands, which is where Git becomes genuinely powerful for research work."
      }
    },
    {
      "@type": "Question",
      "name": "Should I put my research data on GitHub?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Small, shareable text files such as metadata, processed summary tables, and environment specifications belong in the repository. Large binary files and any restricted or sensitive data belong in a dedicated data repository with the location documented in your README. Sensitive records must never enter version control at all."
      }
    },
    {
      "@type": "Question",
      "name": "How do I handle large raster or NetCDF files in a GitHub project?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Keep them out of Git. GitHub rejects individual files above 100 MB and warns above 50 MB. Store large files on institutional storage or a data repository, document each file in the README, and provide a small script that downloads and verifies the data if needed."
      }
    },
    {
      "@type": "Question",
      "name": "How do I undo a bad commit?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "If you have not pushed yet, git reset, soft HEAD~1 steps back one commit while keeping your changes. If you have pushed, use git revert with the commit hash to create a new commit that undoes the old one without rewriting history."
      }
    },
    {
      "@type": "Question",
      "name": "How do I give credit to collaborators on individual commits?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Add a Co-Authored-By: trailer to the commit message with each contributor's name and email. GitHub displays those accounts as co-authors on the commit, which helps credit shared work accurately."
      }
    },
    {
      "@type": "Question",
      "name": "What should I do if I accidentally committed a sensitive file?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Remove it from tracking, add it to .gitignore, and revoke or regenerate any credential the file contained, because anything pushed must be treated as exposed. Prevention through .gitignore from the start is the reliable defense."
      }
    },
    {
      "@type": "Question",
      "name": "How do I share my code with journal reviewers?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Push the repository to GitHub, tag a release so the exact version is fixed, and cite that repository in your code availability statement. Include a README, the software environment specification, and a documented link to where the data are archived."
      }
    }
  ]
}
</script>

## Sources

1. [Version Control for Surgical Data Science: A Primer on Git and GitHub.](https://pubmed.ncbi.nlm.nih.gov/42893433/)
2. [Spatiotemporal prediction of soil organic carbon density in Europe (2000-2022) using earth observation and machine learning.](https://pubmed.ncbi.nlm.nih.gov/40677752/)
3. [A mixed-methods analysis of micro-collaborative coding practices in OpenStack.](https://pubmed.ncbi.nlm.nih.gov/35757446/)
4. [Enabling FAIR data in Earth and environmental science with community-centric (meta)data reporting formats.](https://pubmed.ncbi.nlm.nih.gov/36376356/)
5. [Spatial and Texture Analysis of Root System distribution with Earth mover's Distance (STARSEED).](https://pubmed.ncbi.nlm.nih.gov/36604751/)
6. [Benchmarking deep learning methods for Cα atom prediction in cryo-EM density maps.](https://pubmed.ncbi.nlm.nih.gov/42234518/)