# Git for Earth Science Researchers Most Git trouble in earth science projects traces back to one cause: the repository is being used to store data it was never designed to hold. A Git repository permanently keeps every version of every file ever committed, so a single `git add data/` that sweeps in a folder of NetCDF files can turn a lean project into a multi-gigabyte archive that takes hours to clone and refuses to push. The first thing to check whenever Git misbehaves is therefore the same, whatever the symptom. Open a terminal in the project folder, run `git status`, and read the entire output. Git reports its own state more honestly than any other tool in the research stack, and the fix for most failures is written in that output. Git for earth science researchers fails in predictable ways, and the fixes are just as predictable once the underlying model is clear. This guide covers how Git actually works, the causes of failure in order from most common to rarest, how to fix each one, a short diagnostic sequence, and the prevention habits that keep a research repository healthy. Every command shown is standard Git or GitHub practice and behaves the same on macOS, Windows, and Linux. ## Why Git for Earth Science Researchers Runs into Trouble Earth science projects have a shape that generic software tutorials rarely match. A single study can combine satellite records, field campaign measurements, numerical model output, and a manuscript, developed across institutions and countries, and expected to stay reproducible for years because environmental questions are revisited as new observations arrive. Large Earth observation programs show the pattern clearly. In the Hindu Kush Himalaya, the SERVIR program applies Earth observation products to disaster risk reduction and resilience across a region whose headwaters feed ten major rivers supplying water to millions of people [1]. NASA's Earth Information System takes a complementary approach, bringing process-based numerical models, NASA satellite observations, and analysis workflows together in one cloud environment under an open-source science framework, with teams that cut across the traditional Earth science disciplines [2]. Both models of research depend on code, configurations, and workflows that many people develop, share, and reuse over long periods. That is the job Git was built for. Git is a distributed version control system: every collaborator holds a complete copy of the project's history, and changes are recorded as immutable, checksummed snapshots. GitHub for researchers adds a shared online home for those copies plus review and discussion tools. The mismatch is data volume. A climate model ensemble or a season of Sentinel-2 scenes does not belong in the same history as the scripts that process it, and most Git failures in this field are that mismatch expressing itself in one way or another. ## How Git Works: The Model Behind Every Error Message Git for scientists follows the same mechanics as Git for software teams, and every error message describes some part of this model, so it pays to know the four places a file version can live. 1. **Working directory.** The files as you see and edit them. 2. **Staging area (index).** Changes marked for the next commit with `git add`. 3. **Local repository.** The committed history, stored in the hidden `.git` folder inside the project. 4. **Remote.** Another copy of the repository, usually hosted on GitHub, that you sync with. A commit is a full snapshot of the staged content plus metadata: author, timestamp, message, and a pointer to its parent commit or commits. Each commit is identified by a short checksum called its SHA, for example `9c41f2e`. A branch is nothing more than a movable label pointing at one commit, and HEAD is Git's record of where you are right now, normally the tip of the current branch. Cloning a repository copies the entire history rather than only the latest files. Every collaborator can therefore commit offline and push later, a property field teams with intermittent connectivity should not underestimate. `git push` and `git pull` move commits between your repository and a remote, and nothing else. Read errors with that in mind. A rejected push (a non-fast-forward error) means the remote contains commits your copy lacks. A merge conflict means two branches changed the same lines and no automatic rule can choose between them. A bloated `.git` folder means large files entered the history, because Git keeps every version of every file forever by design so that any past state can be restored exactly. The staging area exists so you can compose a commit deliberately: `git diff` shows uncommitted edits in the working directory, and `git diff, staged` shows exactly what the next commit would capture. ## Common Causes of Git Failure, From Most Frequent to Rarest The sections below cover the causes in the order they typically appear in earth science workflows. Each one explains the mechanism, the symptom, a quick way to confirm it, and how to fix it. A condensed table appears later for emergencies. ### 1. Large Data Files Committed to the Repository ![Comparison of plain Git, Git LFS, and a data repository by what they store, size limits, and clone cost.](/article-images/illustrations/git-for-earth-science-researchers-data-storage-options.webp) Symptom: pushes stall or time out, clones grow to gigabytes, and GitHub refuses the push with a message that a file exceeds its size limit. GitHub warns about individual files above 50 MB and rejects those above 100 MB. Mechanism: Git stores a complete copy of every version of every file in the history. Text files compress and diff well. Binary scientific formats such as NetCDF, GeoTIFF, and HDF5 do not, so each new version of a 2 GB model output adds roughly 2 GB to the repository forever, and every clone downloads all of it. The "commit everything, it is a backup" habit fails here precisely because Git is not a backup system, it is a history system. Confirm with `git count-objects -vH`, which reports the size of the local object store, and `du -sh .git` for the total. To find the offenders, run: ``` git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectsize) %(rest)' | sort -k2 -nr | head -15 ``` This lists the largest stored objects with their paths. Fix before the fact: keep data out of Git. Add patterns to `.gitignore` (`*.nc`, `*.tif`, `outputs/`), and untrack files already added without deleting them from disk with `git rm, cached -r data/`. Store data by reference instead: archive the dataset in a disciplinary or institutional repository, then commit a small checksum file so the exact bytes can be verified years later: ``` sha256sum data/scene_20230105.nc > data/scene_20230105.nc.sha256 ``` (macOS uses `shasum -a 256` for the same job.) Tools built for data versioning, such as Data Version Control (DVC) or git-annex, track large files in a separate store while Git keeps lightweight metadata. Fix for the few files that must travel with the code: Git Large File Storage (Git LFS) replaces the file in the repository with a pointer and stores the object on a dedicated server: ``` git lfs install git lfs track "*.gpkg" git add .gitattributes ``` After that, add and commit the tracked files normally. Hosting plans cap LFS storage and bandwidth at modest free allowances, so check the quota before pointing LFS at a model output archive. If you track shapefiles, track every sidecar together (`.shp`, `.shx`, `.dbf`, `.prj`), because a shapefile missing its companions will not open. Fix after the fact: if large files are already in shared history, they can only be removed by rewriting history. Install `git filter-repo` (available through pip), run it on a fresh clone, and strip the offending paths: ``` git filter-repo --path data/model_run_v1.nc --invert-paths ``` The tool removes the remote as a safety measure, so re-add it, coordinate with the team, and push the rewritten history with `git push, force` once everyone has saved local work. The BFG Repo-Cleaner is a simpler alternative for stripping blobs above a size threshold. Follow the rewrite with `git gc` to compact the local store. Safety note: history rewrites change the checksum of every subsequent commit, so schedule them, announce them, and expect every collaborator to re-clone afterward. ### 2. Authentication Failures on Push and Clone Symptom: `Authentication failed for 'https://github.com/...'`, a message that password authentication was removed, or `Permission denied (publickey)`. Mechanism: Git talks to GitHub over HTTPS or SSH. HTTPS expects a personal access token (PAT), a revocable string that acts as a password, because GitHub stopped accepting account passwords for Git operations in 2021. SSH expects a key pair registered with your account. Credential managers cache tokens, and a stale cached token produces failures that look like a GitHub outage. Confirm: run `git remote -v`. A URL starting with `https://` uses token authentication, and one starting with `git@` uses SSH. Test the SSH path with `ssh -T git@github.com`. Fix over HTTPS: create a token under Settings, Developer settings, Personal access tokens on GitHub, give it repository read and write scope, and paste it at the password prompt. The credential manager (Git Credential Manager on Windows, the keychain helper on macOS) stores it for next time. If a previously working setup starts failing, the stored token is stale: update it in the credential manager rather than retrying the same password. Fix over SSH: generate a key pair with `ssh-keygen -t ed25519 -C "you@institution.edu"`, copy the contents of `~/.ssh/id_ed25519.pub` into the SSH keys section of your GitHub account, verify with `ssh -T git@github.com`, and switch an existing repository with `git remote set-url origin git@github.com:labname/project.git`. Safety note: tokens and private keys are credentials. Never commit them to a repository, and revoke any token that appears in a log, a screenshot, or a commit history immediately. GitHub's push protection blocks many accidental secret uploads before they land. ### 3. Rejected Pushes and Divergent Branches ![Decision path from a rejected push through fetch and status checks to rebase, token refresh, or history rewrite.](/article-images/illustrations/git-for-earth-science-researchers-push-rejected-triage.webp) Symptom: `! [rejected] main -> main (fetch first)` or a note that the tip of your branch is behind its remote counterpart. Mechanism: a push is only accepted when it adds commits on top of what the remote already has. A colleague pushed while you were working, so your branch and the remote branch have diverged, and Git refuses to guess for you. Recent Git versions stop a plain `git pull` on divergent branches and ask how to reconcile them. Confirm: `git fetch` downloads the remote state without touching your files. Then `git status` reports how many commits you are ahead and behind, and `git log, oneline HEAD..origin/main` lists exactly what the remote has that you lack. Fix: commit or stash (`git stash`) your uncommitted work first, then run `git pull, rebase`, which replays your local commits on top of the fetched ones, and push. To make that the permanent default, run `git config, global pull.rebase true`. Rebasing rewrites the checksums of your unpushed commits, which is harmless because nobody else has them yet, and dangerous once they are shared, which is the subject of cause 7 below. ### 4. Merge Conflicts in Shared Files Symptom: after a merge or pull, Git prints `CONFLICT (content): Merge conflict in ...` and the named files contain marker lines. Mechanism: Git merges branches with a three-way comparison against their common ancestor. When both branches changed the same lines, no rule can decide which version is correct, so Git writes both into the file and asks a human: ``` <<<<<<< HEAD bias_corr = 0.31 ======= bias_corr = 0.33 >>>>>>> recalibrate-albedo ``` Confirm: `git status` lists each conflicted file as "both modified". Fix: open every listed file, choose or combine the alternatives, delete the marker lines, then `git add` each resolved file and commit to conclude the merge. `git mergetool` opens a graphical three-pane resolver if you prefer one. To back out of the whole merge and return to the pre-merge state, run `git merge, abort`. Nothing is lost by aborting, because Git recorded the starting state. Notebook caveat: conflicts inside `.ipynb` files are painful because the file is JSON that includes outputs. Strip outputs before committing with nbstripout, or pair notebooks with plain scripts using jupytext so diffs stay readable. Prevention is cheaper than resolution: pull before you start work, keep branches short-lived, and agree within the team on who owns which files. ### 5. Line Endings and Filename Case Across Operating Systems Symptom: a file you never touched shows every line as modified, or a data file that exists on a laptop is "missing" on the computing cluster. Mechanism: Windows ends text lines with CRLF, macOS and Linux with LF. Without a shared policy, each operating system rewrites line endings on checkout and commit, producing phantom whole-file diffs. Filename case is the second trap: NTFS on Windows and the default macOS filesystem ignore case, so `Data.csv` and `data.csv` are the same file, while Linux, which runs most high-performance computing clusters, treats them as two. A repository containing both will clone cleanly on a laptop and break on the cluster. Confirm: `git config core.autocrlf` shows the local line ending policy, and `git diff` on a phantom change shows every line replaced. `git ls-files` reveals case collisions. Fix: commit a `.gitattributes` file so the policy travels with the repository: ``` * text=auto *.py text eol=lf *.ipynb text eol=lf ``` Then run `git add, renormalize .` once, commit, and push, so every collaborator's checkout converges. Set the personal default with `git config, global core.autocrlf true` on Windows and `input` on macOS and Linux. For case collisions, pick one canonical name and rename with `git mv`, passing through a temporary name if your filesystem ignores case. ### 6. Detached HEAD and Other Checkout Surprises Symptom: `git status` prints `HEAD detached at 9c41f2e`, and commits made afterward seem to vanish when you switch back to a branch. Mechanism: HEAD normally labels the tip of the current branch, so new commits advance the branch. Checking out a tag or a raw commit hash detaches HEAD, and new commits then belong to no branch. Switching away leaves them unreachable by any branch name, which feels like data loss but is recoverable. Confirm: `git status` and `git log, oneline -5` show where HEAD sits and what it points to. Fix while still detached: if the work is worth keeping, run `git switch -c rescue-work` to create a branch at the current commit. Fix after switching away: `git reflog` lists the recent positions of HEAD with their hashes, and `git switch -c rescue-work 9c41f2e` restores the work. Safety note: commits unreachable from any branch are kept in the reflog for roughly 90 days by default and are then removed by garbage collection, so rescue them promptly, and do not run `git gc, prune=now` while trying to recover anything. Detached HEAD itself is not an error. Inspecting an old version of the code to see how a figure was made is a legitimate use, as long as you do not build new work there. ### 7. Rewritten History and Force-Push Fallout Symptom: after you push, collaborators report missing commits, their pushes are rejected, or commit hashes they have never seen appear in the log. Mechanism: `git commit, amend`, `git rebase`, and history filters replace commits with new ones carrying different checksums. The remote sees a history that removes commits it already has, so it rejects the push as a non-fast-forward. `git push, force` overrides that refusal and makes the remote match your copy exactly, silently erasing any commits that arrived in the meantime. Confirm: compare `git log, oneline -5` with a collaborator. If the hashes diverge below your rewrite point, the histories differ. Fix for the team: collaborators run `git pull, rebase` so their local work replays on top of the rewritten history, or re-clone if the tangle is worse than the work. Fix for the pusher: use `git push, force-with-lease`, which refuses to overwrite a remote that moved beyond what you last fetched, closing the window where you clobber a colleague's fresh push. Safety note: force pushing a shared branch is the most destructive ordinary action in Git. Protect `main` and release branches on GitHub with branch protection rules that reject force pushes outright, and confine history rewriting to private feature branches where nobody else holds a copy. ### 8. Notebooks, Environments, and Submodules That Drift Symptom: diffs thousands of lines long after a notebook is rerun, results that differ between laptops, or empty tool directories after a fresh clone. Mechanism: three separate habits produce these failures. A `.ipynb` file is JSON containing code, outputs, and metadata, so rerunning it changes thousands of lines even when the code is untouched. An unpinned environment lets dependency versions float, so two machines run different code from the same repository. A submodule is a pinned reference to another repository at a specific commit, and cloning does not fetch its contents automatically. Confirm: `git diff, stat` dominated by `.ipynb` files points to notebook noise, `git diff environment.yml` shows version drift, and `git submodule status` flags submodules that are missing or not at the recorded commit. Fix: strip notebook outputs before committing (nbstripout, enforced automatically with a pre-commit hook), or pair notebooks with scripts using jupytext. Commit an environment specification, `environment.yml` for conda or a `requirements.txt` with pinned versions, and put the recreate command in the README. For submodules, run `git submodule update, init, recursive` after cloning, and commit the pointer update whenever the child repository advances. This is the discipline that makes shared computing environments work across a whole team rather than on one lucky laptop. ## A Short Diagnostic Sequence for Any Git Failure 1. Run `git status` and read every line, including the hints Git prints after the summary. 2. Read the full error text from the failed command, not just the first line. The phrases "fetch first", "non-fast-forward", "both modified", and "detached HEAD" each map to one cause above. 3. Locate yourself in the model: `git log, oneline -5` shows your recent commits, `git branch -vv` shows branches and their tracking state, `git remote -v` shows where pushes go, and `git blame filename` shows which commit last touched each line. 4. Fetch and re-check: `git fetch, all, prune` updates your view of the remote without touching your files, then `git status` reports ahead and behind counts. 5. If the repository feels slow or heavy, run `git count-objects -vH` and look for committed data files. 6. Classify the failure as authentication, synchronization, conflict, size, history, or checkout, and apply the matching fix. 7. Pause before any command that rewrites or deletes. If a command contains the words force, hard, clean, or filter, re-read the safety note next to it first. ## Troubleshooting Reference: Symptom, Cause, Confirmation, Fix | Symptom | Likely cause | How to confirm | Fix | |--|--|--|--| | Push fails with "Authentication failed" over HTTPS | Password authentication removed, stale cached token | `git remote -v` shows an `https://` URL | Create a personal access token, paste it at the prompt, update the credential manager | | `Permission denied (publickey)` | SSH key missing or unregistered | `ssh -T git@github.com` fails | `ssh-keygen -t ed25519`, add the public key to your account, retest | | Push rejected, "fetch first" or non-fast-forward | Remote contains commits your clone lacks | `git fetch`, then `git status` shows "behind" | `git pull, rebase`, resolve, push | | Files contain `<<<<<<<` markers | Merge conflict from simultaneous edits | `git status` lists files as "both modified" | Edit out the markers, `git add`, commit, or `git merge, abort` | | Push stalls, or GitHub rejects a file for exceeding the size limit | Data files entered the history | `git count-objects -vH`, `du -sh .git` | Untrack with `git rm, cached`, adopt Git LFS or a data repository, purge history with `git filter-repo` | | `fatal: not a git repository` | Command run outside a repository | `pwd` and `ls -a` show no `.git` folder | `cd` into the project, or `git clone` / `git init` | | `HEAD detached at 9c41f2e` | A tag or commit was checked out directly | `git status`, `git branch` | `git switch -c rescue-work` to keep the work, or `git switch main` to return | | Every line of an untouched file shows modified | Line ending conversion (CRLF vs LF) | `git diff` replaces the whole file, `git config core.autocrlf` | Commit a `.gitattributes`, run `git add, renormalize .` | | `You have not concluded your merge` | A merge was interrupted | `git status` shows merge state | Resolve conflicts and commit, or `git merge, abort` | | Collaborators see missing commits after your push | History was rewritten and force pushed | Commit hashes differ between clones in `git log` | Team runs `git pull, rebase`, pusher uses `-force-with-lease` only on private branches | | A file exists on a laptop but not on the cluster | Filename case collision | `git ls-files` shows two names differing only in case | Rename to one canonical case with `git mv` | ## GitHub for Researchers: What the Hosting Layer Adds Git runs entirely on your machine. GitHub for researchers adds the shared layer that turns version control into a collaboration system, and the features map directly onto research practice. A pull request proposes a set of commits for review before they merge. In a research context this is code review for analysis: a co-author reads the script that produced a figure before the figure enters the manuscript. Issues track tasks and bugs, from "recalibrate the bias correction" to "the 2019 site visit data has duplicated rows". GitHub Actions runs defined workflows on every push, which makes a smoke test, a code lint, or a notebook execution check automatic rather than aspirational. Releases and tags mark exact states of the code, and branch protection rules can require review and forbid force pushes on `main`. This hosting layer is what shared research platforms build on. NASA's Earth Information System, developed to accelerate sea-level change science in an open-source science framework, provides a common cloud computing environment where process models, satellite observations, and analysis workflows live together, using NASA's Science Managed Cloud Environment and the Multi-Mission Algorithm and Analysis Platform, with a JupyterHub as the primary interface for teams to co-develop and share model configurations and workflows [2]. Every one of those shared artifacts is version-controlled underneath, which is what makes the environment auditable and recoverable when a component changes. Long-lived regional programs benefit the same way. Programs such as SERVIR build on a decade of applied Earth observation experience in the Hindu Kush Himalaya, delivering products for risk reduction and resilience in a region where environmental and social pressures interact [1], and continuity of staff is never guaranteed. A repository with a readable commit history preserves the reasoning behind past decisions, which is institutional memory that survives personnel changes. The human layer matters as much as the technical one. Earth observation and geo-information technologies now reach far beyond specialists, with more uses and users and with benefits and challenges that differ across groups [3]. Onboarding the whole team rather than only the most enthusiastic coder is part of the infrastructure, and workshops and disciplinary conferences remain the venues where these practices spread between groups. ## Common Mistakes and Limitations - **Committing credentials.** Access tokens for NASA Earthdata, cloud provider keys, and database passwords end up in notebooks and configuration files. Safety note: if a secret is ever committed, revoke it first and clean the history second, because public repositories are scraped by automated clients within minutes. - **Committing outputs instead of inputs and code.** A repository of figures and result tables cannot be audited or extended. Commit the code, the parameters, and the checksums, and regenerate the outputs. - **Adding `.gitignore` too late.** The pattern list is cheapest on day one. Removing a gigabyte of data from an existing history requires rewriting every commit, which is disruptive to a team. - **One giant commit before submission.** A single "final version" commit throws away the history that would let you answer which change produced which result. Commit small and often. - **Treating GitHub as an archive.** A hosting account is not a preservation repository. Archive release snapshots with a service that mints a DOI, and deposit the underlying data in a disciplinary repository. - **Assuming Git tracks data provenance.** Git versions code and small text reliably. The provenance of a 40 GB model run lives in your [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) plan, your checksums, and your environment files, not in the commit log. - **Rewriting shared history casually.** Amend and rebase are for commits nobody else has. Once a branch is shared, add a corrective commit with `git revert` instead. - **One limitation to state plainly.** Every research group runs a different stack, and agency, journal, or funder data policies override general advice, so confirm any workflow described here against your own data management plan before adopting it. ## Prevention: Habits That Keep a Research Repository Healthy The solutions below cost minutes when adopted at the start of a project and days when adopted after a failure. 1. **Start every project the same way.** `git init`, then add a README, a `.gitignore` (GitHub publishes templates per language), an environment specification, and a license. Two minutes now prevents most of the table above. 2. **Decide the data policy on day one.** Write down what belongs in Git (code, small text files, checksums), what belongs in Git LFS (the handful of binaries that must travel with the code), and what lives in a data repository (everything else). Record the decision in the README. 3. **Commit small and often, with messages that say why.** "Increase albedo bias correction to 0.33 after May 2023 validation" answers a question two years later. "Fixes" does not. 4. **Branch per analysis, merge through pull requests.** Feature branches isolate experiments, pull requests create a review record, and protected branches stop accidents on `main`. 5. **Pull before you push, daily.** `git pull, rebase` keeps your work on top of the team's, and small frequent syncs make conflicts rare and tiny. 6. **Tag releases and make them citable.** `git tag -a v1.0.0 -m "Results for the journal submission"` marks the exact code behind a paper, and archiving that tagged snapshot through a service such as Zenodo mints a DOI you can cite in the methods section. A `CITATION.cff` file lets GitHub display the citation directly on the repository page. 7. **Automate the boring checks.** A pre-commit hook can block large files, strip notebook outputs, and detect committed secrets, and a GitHub Actions workflow can run a smoke test on every push so breakage is caught before a co-author finds it. 8. **Use `git bisect` when a result changes unexpectedly.** It binary-searches the history between a known good and a known bad commit so you can find the exact change that altered a number, which is faster than any amount of staring at diffs. 9. **Back up beyond the hosting service.** `git bundle create project-backup.bundle, all` writes the entire repository to a single file you can copy to an external drive, which suits field sites with intermittent connectivity. 10. **Onboard every team member.** A one-hour session covering clone, branch, commit, pull, push, and pull request prevents the majority of the failures in this article, and it spreads practice across the group rather than concentrating it in one person. ## Frequently Asked Questions ### Do earth scientists really need Git if they mostly work with data? Yes. Even data-heavy projects depend on scripts, notebooks, model configurations, and manuscripts that change constantly, and Git tracks those changes cleanly. The data itself belongs in a data repository, with Git managing the code that processes it. ### What is the difference between Git, GitHub, and GitLab? Git is the version control program that runs on your own computer. GitHub and GitLab are hosting services that store a remote copy of repositories and add collaboration features such as pull requests and issues. The Git commands are identical on all of them. ### Why does GitHub reject my password when I push? GitHub no longer accepts account passwords for Git operations over HTTPS. Create a personal access token or set up an SSH key, and let your credential manager store it. ### Should I commit NetCDF or GeoTIFF files to Git? Usually no. Git keeps a full copy of every version of every file, so large binary data files bloat the repository quickly. Keep data in a data repository, or use Git LFS for the few files that must travel with the code. ### How do I undo a commit I just made? If you have not pushed it, run `git reset, soft HEAD~1` to undo the commit while keeping the changes staged. If the commit is already on a shared branch, run `git revert` with the commit hash to add a corrective commit without rewriting history. ### How do I fix a merge conflict? Open each file listed by `git status`, edit out the conflict markers, keep the lines you want, then `git add` the resolved files and commit. To back out entirely, run `git merge, abort`. ### How do I contribute to a colleague's repository without breaking it? Clone or fork the repository, create a feature branch, commit your changes there, and open a pull request so the owner can review before merging. Never commit directly to the main branch of a shared project. ### How do I make my code citable in a paper? Tag a release, archive the tagged snapshot with a service that assigns a DOI such as Zenodo, and cite that DOI in your methods section. ## Further Reading - [PHARMACOGNOSTICAL AND PHYTOCHEMICAL RESEARCH STUDY OF ROOT PART OF BAL (TENDER) AND VRIDDHA (BOLT) MOOLAK (Raphanus Sativus Linn.)](https://doi.org/10.46607/iamj03p5042021) - [Perspectives for rare earth elements as feed additive in livestock - A review.](https://pubmed.ncbi.nlm.nih.gov/31480174/) ## Sources 1. [Earth Observation Science and Applications for Risk Reduction and Enhanced Resilience in Hindu Kush Himalaya Region: A Decade of Experience From SERVIR. Edited by Birendra Bajracharya, Rajesh Bahadur Thapa, and Mir A. Matin](https://doi.org/10.1659/mrd.mm273.1) 2. [NASA’s Earth Information System: Sea-Level Change](https://doi.org/10.1109/OCEANS47191.2022.9977250) 3. [Gender Integration in Earth Observation and Geo-information Technology Applications: Correlation and Connections](https://doi.org/10.1007/978-3-030-73569-2_15)