# How to Use the RStudio Git Pane for Reproducible Research By the end of this guide you will be able to create an RStudio project under Git version control, stage and commit changes entirely from the Git pane, connect that project to GitHub, synchronize with remote collaborators, read every file status symbol the pane shows you, and diagnose the errors that stop most first-time users. Everything runs from buttons and menus, though the guide points out when a single terminal command solves a problem faster. You need three things installed before you start: 1. R, version 4.0 or later, from CRAN 2. RStudio Desktop, the free open source edition, from the Posit download page 3. Git, from the Git project website at git-scm.com, plus a free account at github.com You do not need any prior command-line experience. Every step below was written against RStudio Desktop on Windows, macOS, and Linux, and the Git behavior it describes comes from the Git project's own documentation and Posit's RStudio documentation. ## Why Git Matters for Reproducible Research A Git repository records a snapshot, called a commit, of every file in your project each time you ask it to. Each commit stores who made the change, when, what changed, and why, if you write a good commit message. Six months later you can return to the exact version of `analysis.R` that produced a figure in a submitted manuscript, even if the file has been edited fifty times since. For a working scientist this replaces three failure-prone habits: files named `analysis_final.R`, `analysis_final2.R`, and `analysis_FINAL_reviewed.R`, zipped folders emailed to yourself, and commented-out code blocks kept "just in case." Git for scientists is essentially a [lab notebook](/knowledge/molecular-biology/lab-notebook) for code. It gives you a complete, timestamped, reversible history of the analysis, which is what a methods reviewer, a collaborator, or your own future self needs when a result is questioned. GitHub for researchers adds two things on top of that history. First, it stores a copy of the repository in the cloud, so a laptop failure does not destroy the record. Second, it makes the repository shareable, so collaborators can review changes, file issues on bugs, and download the exact code behind a publication. Journals that require code availability expect a repository link, and a public GitHub repository satisfies that expectation in a form reviewers can actually inspect. None of this requires the command line. The RStudio Git pane covers the daily work of committing, viewing history, and synchronizing. The command line becomes useful for the rarer operations, and this guide marks those moments explicitly. ## Install Git and Confirm RStudio Can See It RStudio does not include Git. It drives whatever Git installation it finds on your computer, so install Git first. 1. Download the installer for your operating system from git-scm.com. On Windows, accept the default options in the Git for Windows installer. On macOS, installing Git through the Xcode command line developer tools or Homebrew both work. On Linux, install the `git` package with your distribution's package manager. 2. Open a terminal. In RStudio you can use the Terminal tab next to the Console, or any system terminal, and type: ``` git --version ``` Expected output looks like this, with the exact version number varying by platform: ``` git version 2.43.0 ``` 3. Open RStudio, go to Tools, then Global Options, then Git/SVN. The "Git executable" field should already point to your Git installation. On Windows this is typically `C:/Program Files/Git/bin/git.exe`. Also confirm the checkbox "Enable version control interface for RStudio projects" is checked. It is checked by default. 4. Restart RStudio so it picks up a fresh installation. If the Git/SVN options page shows an empty executable path, browse to the `git` or `git.exe` binary manually, click Apply, and restart. ## Configure Your Name and Email Once Every commit records an author name and email. Configure these once, globally, and never think about it again. In the RStudio Terminal tab run: ``` git config --global user.name "Your Name" git config --global user.email "you@example.com" git config --global init.defaultBranch main git config --global --list ``` The last command prints your configuration so you can verify it: ``` user.name=Your Name user.email=you@example.com init.defaultBranch=main ``` Use the email attached to your GitHub account. GitHub links commits to your profile by matching this email, so commits you author show up with your avatar and count toward your contribution record. If you prefer to stay inside R, the usethis package does the same thing: ```r install.packages("usethis") usethis::use_git_config(user.name = "Your Name", user.email = "you@example.com") ``` The `init.defaultBranch main` line names the first branch `main` instead of the older default `master`. GitHub uses `main` for new repositories, so matching the two names avoids a small but frequent source of confusion on your first push. ## Create an RStudio Project Under Version Control RStudio's Git pane only appears inside an RStudio project, so start there. An RStudio project is simply a folder with an `.Rproj` file that RStudio uses to set the working directory, isolate settings, and remember which files belong to which analysis. Posit's own workflow guidance treats projects as the basic unit of work, and Git treats that same folder as the repository. To create a new project with Git already initialized: 1. Go to File, then New Project, then New Directory, then New Project. 2. Name the directory, for example `rna-seq-analysis`, and choose where it lives on disk. 3. Check the box labeled "Create a git repository." 4. Click Create Project. RStudio builds the folder, runs `git init` inside it, and the Git pane appears in the upper right pane group, in the same tab strip as Environment and History. For a project that already exists, open it, then go to Tools, then Project Options, then Git/SVN. Set "Version control system" to Git, accept the prompt to initialize the repository, and restart RStudio. Behind the scenes this runs `git init` in the project folder and creates a hidden `.git` directory that stores the entire history. You never edit that directory by hand. If you delete it, you delete your history. One structural habit pays off permanently: keep the project self-contained. The R scripts, the `.Rproj` file, and preferably the raw data all live inside the one repository folder. Analyses that reach into folders three levels above the project break the moment anyone else clones the repository, and they break reproducibility even for you on a new machine. ## The Git Pane, Element by Element The Git pane has four parts. Knowing what each does removes most of the intimidation. **The file list** dominates the pane. Each row shows a file, a status flag, and a checkbox. The status flag uses the same letters that the `git status` command prints, and Posit's interface maps them directly: | Status symbol | Meaning | What you usually do | |--|--|--| | `M` (yellow) | Modified, not yet staged | Review the diff, then check the box to stage | | `A` (green) | Newly added, staged, not yet committed | Write a commit message and commit | | `D` (red) | Deleted from disk | Stage the deletion so the history records it | | `??` (grey) | Untracked, Git has never seen this file | Decide whether to track it or add it to `.gitignore` | | `R` | Renamed | Stage it | | Checkbox checked | File is staged for the next commit | Press Commit | Staging deserves one clear explanation, because it confuses everyone at first. Staging means "this change goes into my next commit." You can modify five files, stage only two of them, and commit just those two as one logical unit. The checkbox column is the staging area. An unchecked modified file and a checked modified file look almost identical in the list, which trips up new users, so check the box deliberately and immediately before committing. **The toolbar buttons** do the work. Diff opens a window showing exactly which lines changed. Commit opens the same window with a message box. History shows every past commit for the project. Pull and Push synchronize with GitHub. The dropdown at the top left of the pane shows and switches the current branch. **The Diff view** colors removed lines red and added lines green, one change per block. Read it before every commit. This thirty-second review catches stray `print()` calls, hardcoded file paths, and accidental edits before they enter the permanent record. **The History pane** lists commits newest first, each with its message, author, date, and a short identifier called a SHA, such as `a3f9c21`. Clicking a commit shows the full diff of that snapshot. The History pane is the answer to "which version of the code produced this figure?" ## RStudio Git Pane Tutorial: A Step-by-Step Daily Workflow ![Five steps from saving scripts through reviewing the diff, staging files, committing with a message, and checking the History pane.](/article-images/illustrations/rstudio-git-pane-tutorial-daily-loop.webp) This is the loop you will repeat hundreds of times. It takes under a minute once familiar. **Step 1. Save and refresh.** Save your edited scripts with Ctrl+S or Cmd+S. The Git pane does not always refresh instantly, so click into the file list or press the Refresh button to update the status flags. Modified files show `M`, new files show `??`. **Step 2. Review the changes.** Select a file and click Diff. Read the red and green blocks. If you see a debugging line you do not want to keep, delete it in the editor, save, and refresh. If a file should never be tracked at all, right-click it and choose Ignore, which adds it to `.gitignore` automatically. **Step 3. Stage.** Check the box next to each file you want in this commit. Related changes belong together: a script change and the `Makefile` edit it requires make one commit, while an unrelated README fix deserves its own. **Step 4. Commit.** Press Commit. Type a message in the box at the top right of the commit window. The first line is the subject. Keep it under roughly 50 characters, written in the imperative, describing why the change was made rather than restating the diff. Git itself enforces a hard 72-character wrapping limit on commit message bodies, a convention documented in the Pro Git book, and short imperative subjects remain the norm across major open source projects. Good subjects: ``` Add batch effect check to DESeq2 pipeline Fix sample ID mismatch in metadata join ``` Poor subjects: ``` updates fix stuff final changes before meeting ``` Click Commit. The staged rows vanish from the list, the History pane gains one entry, and the working directory is clean again. **Step 5. Verify in History.** Open the History tab. Your newest commit sits at the top with its message, your name, the timestamp, and its SHA. Click it to confirm the diff contains what you intended. This is the check that the commit did what you thought, and it costs five seconds. ### What the underlying commands would look like The pane runs these commands for you. Seeing them once helps when you read documentation or debug in the terminal: ``` git status git add analysis.R git commit -m "Add batch effect check to DESeq2 pipeline" git log ``` Expected output of `git status` before committing: ``` On branch main Changes not staged for commit: modified: analysis.R Untracked files: figures/fig1_batch_effect.png no changes added to commit ``` Expected output of `git log` after a few commits: ``` commit a3f9c21e8b4d2f6a1c9e0d7b5f3a8c2e1d4b6f9a Author: Your Name Date: Mon Nov 9 14:22:03 2026 -0500 Fix sample ID mismatch in metadata join ``` ## Tell Git What to Ignore With .gitignore Not every file belongs in version control. A file named `.gitignore` in the project root lists patterns Git should never track. When you create a project through RStudio with Git enabled, RStudio writes a starter `.gitignore` for you. Open it and make sure it includes at minimum: ``` .Rproj.user .Rhistory .RData .Rproj .DS_Store ``` Each line matters: - `.Rhistory` and `.RData` hold your interactive session's command history and workspace. They change constantly, carry no reproducibility value, and bloat the history. Committing them is the single most common R-specific mistake. - `.Rproj.user` stores RStudio's personal UI state for you, which is meaningless to collaborators. - `.DS_Store` is a macOS Finder artifact. Decide deliberately about data files. Small, static reference files that the analysis needs, such as a lookup table, can be committed. Large raw sequencing files, multi-gigabyte fastq or BAM files, belong in dedicated storage, and GitHub enforces a hard limit of 100 MB per file, with repositories recommended to stay well under 5 GB total, per GitHub's documentation. Committing a 2 GB BAM file once means every collaborator downloads it forever, because history keeps every version. A reasonable middle path for a data analysis repository looks like this: ``` .Rproj.user .Rhistory .RData .DS_Store output/ *.png !figures/README.md data/raw/ ``` This ignores generated outputs, image files, and raw data, while the `!` line, an exception pattern, keeps a README inside the figures folder. When you ignore the raw data, document in the README exactly where it came from and how it was obtained, so the pipeline remains reproducible from an external source. The right-click Ignore shortcut in the Git pane writes these lines for you. You can also use the usethis helper: ```r usethis::use_git_ignore("output/") ``` ## Connect the Project to GitHub GitHub for researchers functions as the shared, backed-up, public-facing home of the repository. Connecting takes about five minutes. ### Create the repository on GitHub 1. Log in to GitHub and click the plus icon, then New repository. 2. Name it to match your project folder, for example `rna-seq-analysis`. 3. Choose public or private. Public repositories are visible to everyone and suit published or shareable code. Private repositories are free for individual use and suit work in progress. 4. Do not initialize with a README, because your local project already has content. Click Create repository. GitHub shows you a page of setup commands. You can ignore most of it, because the steps below cover it. ### Authenticate with a personal access token GitHub no longer accepts account passwords for Git operations. It requires either a personal access token or an SSH key, and for a first setup the token is simpler. GitHub announced this change in 2021, and every current tutorial hits it, so learn it now rather than discovering it mid-error. 1. On GitHub, go to Settings, then Developer settings, then Personal access tokens, and generate a new token. Give it the `repo` scope so it can read and write your repositories, and give it a sensible expiration. 2. Copy the token immediately. GitHub shows it once. 3. Back in RStudio, when you next Push or Pull, RStudio may prompt for a username and password. Enter your GitHub username and paste the token as the password. 4. Better still, install Git Credential Manager, which ships with Git for Windows and with Homebrew's Git formula, and authorize GitHub once through its browser prompt. After that, RStudio's Push and Pull buttons work silently. ### Link and push your local project In the RStudio Terminal tab, inside your project: ``` git remote add origin https://github.com/yourusername/rna-seq-analysis.git git push -u origin main ``` The `remote add` line registers the GitHub copy under the nickname `origin`, the conventional name for the primary remote. The `push -u` line uploads your commits and, with the `-u` flag, links your local `main` branch to `origin/main` so that every future Push and Pull works with one click and no arguments. Expected output: ``` Enumerating objects: 12, done. Counting objects: 100% (12/12), done. Writing objects: 100% (5/5), 1.23 KiB, done. To https://github.com/yourusername/rna-seq-analysis.git * [new branch] main -> main branch 'main' set up to track 'origin/main'. ``` Open the repository page on GitHub and refresh. Your scripts, `.gitignore`, and `.Rproj` file should appear. The usethis package compresses all of this, including the remote setup, into two functions: ```r usethis::use_git() # initialize the repository if not already done usethis::use_github() # create the GitHub repo and push ``` ### Clone an existing GitHub repository instead When joining a collaborator's project, or starting a new machine, you clone rather than create: 1. On the GitHub repository page, click the green Code button and copy the HTTPS URL. 2. In RStudio, go to File, then New Project, then Version Control, then Git. 3. Paste the repository URL, choose a parent directory, and click Create Project. RStudio runs the equivalent of `git clone`, downloads the full history, opens the project, and the Git pane appears already connected. Expected terminal equivalent and output: ``` git clone https://github.com/yourusername/rna-seq-analysis.git ``` ``` Cloning into 'rna-seq-analysis'... remote: Enumerating objects: 24, done. Receiving objects: 100% (24/24), done. ``` ## Push, Pull, Branches, and the Sync Rhythm Once a remote exists, the Git pane shows two arrows with counters next to the branch dropdown. A blue upward arrow with a number means you have that many commits that exist only locally and need pushing. A red or yellow downward arrow means the remote has commits you have not pulled. Numbers appearing there is your cue to synchronize. Adopt a simple rhythm that prevents almost all sync trouble: Pull at the start of a work session, commit your work in small units, and Push at the end. When two machines or two collaborators both push, the second push is rejected until the first person's work is pulled in. This is normal and recoverable, not data loss. ### Branches from the dropdown A branch is an independent line of history. Use one whenever you try something that might not work out, such as a new normalization method, while keeping `main` stable and correct. 1. Click the branch dropdown in the Git pane. 2. Type a new branch name, for example `alternative-normalization`, and click Create. 3. All commits you make now land on that branch. `main` stays untouched. 4. Switch back at any time through the same dropdown. RStudio reloads the files as they were on the branch you select. When the experiment succeeds, merge it. The Git pane has no merge button, so this is one of the moments the terminal earns its keep: ``` git checkout main git merge alternative-normalization git push ``` If instead the experiment failed, delete the branch through the dropdown's "Delete Branches" option and nothing on `main` ever changed. That ability to abandon a failed line of work with zero cleanup is the core reason branches improve reproducible research practice. ### Resolving a merge conflict A conflict happens when two branches change the same lines and Git cannot choose. After a pull or merge, Git writes both versions into the file with markers: ``` <<<<<<< HEAD filter_severity <- c("moderate", "severe") ======= filter_severity <- c("mild", "moderate", "severe") >>>>>>> alternative-normalization ``` Open the file in the RStudio source editor, edit until only the correct version of the block remains, and delete all three marker lines beginning with `<`, `=`, and `>`. Save, stage the file in the Git pane, and commit. The commit window will already be pre-filled with a merge message. Conflicts in plain text analysis code are usually this easy. Binary files such as `.RData` or Excel workbooks cannot be merged line by line, which is one more reason to keep derivable outputs out of the repository and regenerate them from scripts. ## Exact Error Messages and Their Fixes ![Decision path for a rejected push: pull first, resolve conflicts if histories diverged, then push again, never force push.](/article-images/illustrations/rstudio-git-pane-tutorial-push-rejected.webp) These are the errors you will actually hit, with the wording Git prints and the fix. **"*** Please tell me who you are" followed by "fatal: unable to auto-detect email address."** You committed before configuring your name and email. Run the `git config, global` commands from the configuration section, then commit again. Commits already made with a wrong identity can be corrected, but the simplest path when it happens on the very first commit is to fix the config and redo that commit. **"fatal: not a git repository (or any of the parent directories): .git"** A Git command ran in a folder that is not inside a repository, most often because the RStudio Terminal opened in a directory other than the project root, or because the Git pane is missing because the project was created without version control. Fix the first by opening the project with File, then Open Project. Fix the second with Tools, then Project Options, then Git/SVN, as described earlier. **Push rejected with "error: failed to push some refs" and the hint "Updates were rejected because the remote contains work that you do not have locally."** Someone or some machine pushed before you. Click Pull first. If the histories diverged, Git creates a merge commit or asks you to resolve conflicts as described above. Then Push again. Do not respond to this error with a force push, which overwrites the remote and erases a collaborator's work. **"remote: Support for password authentication was removed on August 13, 2021."** You entered your GitHub account password at the credential prompt. GitHub requires a personal access token or SSH authentication. Follow the token steps in the GitHub section above, or set up Git Credential Manager so the prompt disappears permanently. **"warning: in the working copy of 'analysis.R', LF will be replaced by CRLF the next time Git touches it"** or the reverse. This is a line-ending notice from Windows, where text files historically end with CRLF while Unix systems use LF. It is a warning, not an error, and committing proceeds normally. Setting `git config, global core.autocrlf true` on Windows, or `input` on macOS and Linux, standardizes behavior across your machines. Collaborators on mixed operating systems should agree on one setting, and the `.gitattributes` file can enforce it inside the repository. **"fatal: detected dubious ownership in repository at '/path/to/project'"** Git refuses to operate when the project folder is owned by a different user account than the one running Git, a situation common with Windows Subsystem for Linux, network drives, and shared lab servers. Git itself prints the exact command to trust the folder in this situation, and running that printed command resolves it. When the project sits on a network drive purely by habit, moving it into your home directory is the more durable fix, and it also speeds up Git noticeably. **"error: Your local changes to the following files would be overwritten by merge"** You tried to pull while holding uncommitted edits to files the incoming commits also touch. Commit your work first through the normal pane workflow, then pull. If the local edits are throwaway experiments you do not want to keep, the Diff view's Revert button discards them, after a confirmation dialog, and the pull then succeeds. ## A Reference Table of Git Pane Controls | Pane element | Action | When to use it | |--|--|--| | File checkbox | Stages or unstages a file | Immediately before committing | | Diff button | Shows line-level changes in red and green | Before every commit | | Commit button | Records staged changes with a message | After each unit of completed work | | History button | Lists all commits, click one to see its diff | Tracing which code version produced a result | | Branch dropdown | Shows, creates, switches, deletes branches | Starting or abandoning an experimental analysis | | Up arrow with number | Pushes local commits to GitHub | End of a work session | | Down arrow with number | Pulls remote commits to your machine | Start of a work session | | Right-click, Ignore | Adds a file pattern to `.gitignore` | First time an unwanted file appears | | Revert (in Diff view) | Discards uncommitted changes in a file | Removing accidental edits | ## Common Mistakes and Limitations These are the failure patterns seen repeatedly when scientists adopt the Git pane, with the specific fix for each. **Committing the workspace files.** `.RData` and `.Rhistory` change on nearly every interactive action, so they generate noise commits, inflate the repository, and imply a false record of reproducibility, since a saved workspace is precisely what reproducible workflows advise against relying on. Ignore them from day one, and run `rm(list = ls())` habits aside, structure scripts so a fresh R session can rerun them top to bottom. **Committing large data and generated outputs.** Git stores every historical version of every committed file. A directory of BAM files committed once is downloaded by every clone forever. Keep raw data in institutional storage, a dedicated data repository, or an external drive, reference it in the README, and track only code, small configuration files, and small static inputs. GitHub's per-file hard limit of 100 MB makes this a hard stop, not a preference. **Committing credentials.** API keys, database passwords, and tokens pasted into scripts and then committed remain in history even after you delete them in a later commit, because history preserves every snapshot. Anyone with repository access can read them. Keep secrets in a file named something like `.Renviron`, ignore that file in `.gitignore`, and if a secret ever does get committed, treat it as compromised and rotate it. Removing content from Git history is possible but disruptive, and prevention is the better policy. **Vague commit messages.** "fix" and "changes" in the message box destroy the main value of the history. A subject line that names the reason, such as "Exclude samples collected before protocol v2," turns the History pane into a searchable provenance record. **Pulling never, pushing blindly.** Working for weeks without pulling builds a large divergence that resolves into a painful conflict. Pulling at the start of each session keeps divergence at zero or near zero. **Expecting the pane to cover every Git operation.** The pane handles the daily loop well. It does not provide interactive partial staging of individual lines within a file, has no merge button, and offers limited tools for rewriting history. When you need those, the Terminal tab is one click away, and the pane's model of staging and commits maps directly onto the commands shown earlier. **Confusing version control with reproducibility.** Git records what the code was, not whether the code runs. A repository full of scripts with hardcoded absolute paths, undeclared package dependencies, and no documented entry point is version-controlled but not reproducible. The section below addresses the gap. ## Making the Analysis Reproducible Beyond the Snapshot Version control is one pillar. Three practices complete the structure, and all integrate cleanly with the pane workflow. **Pin your package versions with renv.** The renv package records the exact version of every package your project uses in a file called `renv.lock`: ```r install.packages("renv") renv::init() ``` renv automatically adds its private library folder to `.gitignore` while leaving `renv.lock` tracked. Commit the lock file. A collaborator, or you on a new machine, then runs `renv::restore()` and installs exactly the recorded versions. A commit that includes both a code change and its updated `renv.lock` pins the full software environment for that snapshot. **Write scripts that run from a fresh session.** Set the random seed with `set.seed()` wherever randomness appears, use relative paths through the here package rather than `setwd()` calls, and load packages at the top of the script. Record the session with `sessionInfo()` output in the README or at the end of the analysis log. The commit history then pairs naturally with the environment record: commit SHA plus `renv.lock` plus seed defines the analysis completely. **Document the entry point in a README.** Every repository needs a `README.md` saying what the project does, which file to run first, what input data is required and where it comes from, and roughly how long the pipeline takes. GitHub renders this file on the repository front page, which makes it the first thing a reviewer or collaborator reads. **Publish a citable snapshot.** When work is ready to share, create a GitHub Release from a tagged commit, which freezes a downloadable version of the code at a named point such as `v1.0`. GitHub integrates with Zenodo, a research data archive that assigns a citable digital object identifier to a repository release, so the exact code behind a paper carries a persistent citation. The tag-and-release workflow uses the same history the Git pane has been building all along. ## Next Steps After the Pane Once the daily loop is habit, GitHub adds collaboration features worth learning in this order. Issues let collaborators track problems and to-dos on the repository page. Pull requests let a colleague propose changes that you review as line-level diffs before merging, which brings code review into the analysis. GitHub Actions can run your pipeline automatically on every push, so a silent breakage announces itself the day it happens rather than the day a manuscript depends on the number. Each of these builds directly on the commit history you are now creating from the Git pane, and none of them requires relearning the fundamentals above. ## Frequently Asked Questions ### Do I need to learn command-line Git to use the RStudio Git pane? No. Staging, committing, diffing, viewing history, branching, pushing, and pulling all work from pane buttons. Keep the Terminal tab in reserve for merging branches, removing files from history, and troubleshooting, since a handful of commands cover those cases. ### Why is the Git pane missing from my RStudio window? The Git pane only appears when the open project has version control enabled. Either open the project through File, then Open Project, or enable Git under Tools, then Project Options, then Git/SVN, and restart. If the pane is hidden rather than absent, check View, then Show Git Pane, or the Pane Layout in Global Options. ### Should I commit .RData and .Rhistory files? No. List them in `.gitignore` before your first commit. They change constantly, carry no reproducibility value, and replace the real record of how results were produced, which is the committed script plus its inputs. ### How often should I commit? Commit whenever you reach a state you might want to return to, which for active analysis work usually means several small commits per day. Small commits with descriptive messages produce a far more useful history than one weekly commit titled "week's work." ### Can I use the RStudio Git pane without a GitHub account? Yes. Git works entirely on your local machine, and the pane's staging, committing, diffing, history, and branching features all function with no remote configured. GitHub becomes necessary only when you want cloud backup or collaboration, and you can add a remote months later without disturbing the existing history. ### What is the difference between staging and committing? Staging selects which changes go into the next commit, using the checkbox column. Committing records the staged changes permanently with a message. You can stage several files and commit them together, or stage some files now and leave others for a later, separate commit. ### How do I undo a commit I just made? Open the History pane, select the commit, and click Revert, which creates a new commit that reverses it while preserving the record. For uncommitted changes you simply want to discard, select the file in Diff view and click Revert there. Avoid history-rewriting commands until you are comfortable with the basics, since they can discard work permanently. ### How do I share my project with a collaborator? Push the repository to GitHub, open its Settings, then Collaborators, and add your collaborator's GitHub username. They then clone the repository through File, then New Project, then Version Control in their own RStudio, and your Pull and Push rhythm keeps both copies synchronized through the shared remote.