Video Notes

This guide covers a practical Git workflow inside Positron, a data science–focused IDE for R and Python.

Introduction - What Version Control Is and Why It Matters

Version control solves two core problems:

1. Tracking changes over time - Every meaningful change to your project can be saved as a snapshot. This makes it easy to see what changed, when it changed, and why.
2. Collaboration without overwriting work - Multiple people can work on the same project without accidentally deleting or overwriting each other’s changes.

Even when you’re working alone, version control acts like a time machine. If something breaks or you take your code in the wrong direction, you can always return to a previous state.

Installing and Verifying Git

Before using Git in Positron, Git must be installed on your system. To confirm it is:

1. Open the Terminal in Positron
2. Run: which git

If Git is installed, you’ll see a path to the executable. If not, you’ll need to install Git from https://git-scm.com/install/mac.

One-Time Git Configuration

Now that we have confirmed Git is installed, we’ll do some initial configurations.

Still in the Terminal tab in Positron, run the following command (edit to use your name) to identify the name to be associated with your Git interactions:

> git config --global user.name "Susan"

Also set your email address (replace with your own):

> git config --global user.email "mail@codewithsusan.com"

Set the default branch name for new repositories to main (the GitHub.com convention) with this command:

> git config --global init.defaultBranch main

Run the following command so that Git will ignore filemode (permission) changes:

> git config --global core.filemode false

Finally, run the following command to configure how Git handles line endings in files:

> git config --global core.autocrlf input

That’s it for Git configs, so let’s move on...

Creating a Repository on GitHub

When creating a new repository on GitHub, it’s good practice to:

1. Include a README file
2. Add a .gitignore file appropriate for your language (e.g. R or Python)

The README provides basic information about the project, while the .gitignore tells Git which files should not be tracked, such as environment-specific or temporary files.

GitHub automatically creates an initial commit when the repository is set up.

Cloning the Repository Into Positron

Once the repository exists on GitHub, the next step is to clone it locally.

In Positron:

1. Open the Source Control pane
2. Choose Clone Repository
3. Paste the repository URL
4. Select a destination folder
5. Open the cloned repository

At this point, you have two copies of the project:

1. A remote version on GitHub
2. A local version on your computer

Making Changes and Understanding Staging

As you edit files or add new ones, Git detects those changes automatically.

Before creating a commit, files must be staged. Staging lets you choose exactly which changes will be included in the next commit.

Common file states include:

• Untracked: New files Git hasn’t seen before
• Modified: Existing files that have changed
• Staged: Files ready to be committed

Staging gives you fine-grained control over your commit history.

Creating Commits and Syncing With GitHub

Once files are staged:

1. Write a short, descriptive commit message
2. Create the commit
3. Push or sync the commit to GitHub

The first time you connect to GitHub from Positron, you’ll be prompted to authenticate. After that, syncing becomes a routine part of your workflow.

Reviewing Changes and Undoing Mistakes

Positron makes it easy to:

• View diffs showing exactly what changed
• Discard changes and revert a file to its last committed state
• Commit only a subset of your current changes

These features encourage experimentation, since you can always undo work that doesn’t pan out.

When to commit?

You don’t make commits after every single change you make. Instead, make commits when you’re at notable “save points”. Here are some examples:

• When you’re wrapping up a session - If you just spent some time working on a project and are going to move on to something else, make a commit to save your progress up to that point.
• When something finally works - If you reached notable point in the project, for example, something you had been struggling with is finally working! Make a commit to record the project in that working state.
• Before experimenting - Maybe you decide to take your project in a different direction, but you’re not sure how it will go - make a commit before you start, so you can always revert back to the previous code if things go awry.
• Before sharing - If it’s time to share the project with a colleague/boss/whatever for review, make a commit so what you share via GitHub.com reflects the most up to date state of your code.

If in doubt, commit early and often. It never hurts to have a healthy working history of how your project is evolving.

Advanced Git

The above steps outline the essentials of getting a Git workflow set up for a project, and for many, that’s as far as they’ll need to take Git.

That being said, there are many more things you can do with Git that you may wish to explore as you get more comfortable with it including:

• Creating and working with branches for feature development and experimentation
• Using pull requests to propose, review, and merge changes collaboratively
• Reverting commits or using Git reset to undo changes cleanly
• Stashing changes with Git stash to temporarily set aside work
• Tagging commits to mark version releases or key milestones
• Viewing commit history with Git log, Git diff, and graphical tools
• Resolving merge conflicts during collaborative work
• Using GitHub issues and project boards to organize tasks and bugs