12  Github

Adapted by UCD-SeRG team from original by Stephanie Djajadi and Nolan Pokpongkiat

12.1 Basics

  • A detailed tutorial of Git can be found here on the CS61B website.
  • If you are already familiar with Git, you can reference the summary at the end of Section B.
  • If you have made a mistake in Git, you can refer to On undoing, fixing, or removing commits in git (Robertson, n.d.) to undo, fix, or remove commits in git.
  • For hands-on Git practice, see the UC Davis DataLab Git Sandbox - a collaborative repository for learning Git workflows.

12.2 GitHub Education and Copilot Access

12.2.1 GitHub Education Benefits

Students, faculty, and researchers at UC Davis can access GitHub Education benefits, which include free access to GitHub Pro features and various developer tools.

To sign up for GitHub Education:

  1. Visit the GitHub Education website
  2. Click “Get benefits” or “Join GitHub Education”
  3. Sign in with your GitHub account (or create one if you don’t have one)
  4. Complete the application form using your UC Davis email address (ending in ucdavis.edu)
  5. Provide proof of your academic affiliation (e.g., upload a photo of your student ID or university letter)
  6. Wait for approval (typically takes a few days)

Once approved, you’ll have access to the GitHub Student Developer Pack (for students) or GitHub Teacher Toolbox (for faculty), which includes numerous free tools and services for learning and development.

12.2.2 GitHub Copilot Access for UC Davis Members

GitHub Copilot is an AI-powered coding assistant that can significantly accelerate your work. As a member of the UC Davis GitHub organization, you may be eligible for a free Copilot seat.

To request a Copilot seat:

If you are not yet a member of the UC Davis GitHub organization:

  1. Ensure you have a GitHub account and have signed up for GitHub Education (see above)
  2. Go to the UC Davis IT ServiceHub GitHub page
  3. Click the blue “Get GitHub!” button near the top right
  4. When you receive the invitation email, make sure to check the “Ask for a GitHub Copilot seat (optional)” checkbox before joining (Figure 12.1)
Figure 12.1: UC Davis GitHub invitation with Copilot seat option
  1. Click “Join UC Davis” to accept the invitation
  2. Follow the setup instructions to install and configure Copilot in your development environment

If you are already a member of the UC Davis GitHub organization:

  1. Go to your GitHub Copilot settings
  2. Scroll to the “Get Copilot from an organization” section at the bottom
  3. Find the “ucdavis” entry and click the request button
Figure 12.2: GitHub Copilot settings page showing organization options
  1. Wait for approval from the UC Davis GitHub organization administrators
  2. Once approved, follow the setup instructions to install and configure Copilot in your development environment

For guidance on using GitHub Copilot effectively, see Section 18.5.8 in the Working with AI chapter.

12.3 Github Desktop

While knowing how to use Git on the command line will always be useful since the full power of Git and its customizations and flexibility is designed for use with the command line, Github also provides GitHub Desktop (“GitHub Desktop,” n.d.) as a graphical interface to do basic git commands; you can do all of the basic functions of Git using this desktop app. Feel free to use this as an alternative to Git on the command line if you prefer.

12.4 Git Branching

Branches allow you to keep track of multiple versions of your work simultaneously, and you can easily switch between versions and merge branches together once you’ve finished working on a section and want it to join the rest of your code. Here are some cases when it may be a good idea to branch:

  • You may want to make a dramatic change to your existing code (called refactoring) but it will break other parts of your project. But you want to be able to simultaneously work on other parts or you are collaborating with others, and you don’t want to break the code for them.
  • You want to start working on a new part of the project, but you aren’t sure yet if your changes will work and make it to the final product.
  • You are working with others and don’t want to mix up your current work with theirs, even if you want to bring your work together later in the future.

A detailed tutorial on Git Branching can be found here. You can also find instructions on how to handle merge conflicts when joining branches together.

12.5 Example Workflow

A standard workflow when starting on a new project and contributing code looks like this:

Table 12.1: Standard Git workflow for new projects
Command Description
SETUP: FIRST TIME ONLY: git clone <url> <directory_name> Clone the repo. This copies of all the project files in its current state on Github to your local computer.
1. git pull origin master update the state of your files to match the most current version on GitHub
2. git checkout -b <new_branch_name> create new branch that you’ll be working on and go to it
3. Make some file changes work on your feature/implementation
4. git add -p add changes to stage for commit, going through changes line by line
5. git commit -m <commit message> commit files with a message
6. git push -u origin <branch_name> push branch to remote and set to track (-u only needed if this is first push)
7. Repeat step 4-5. work and commit often
8. git push push work to remote branch for others to view
9. Follow the link given from the git push command to submit a pull request (PR) on GitHub online PR merges in work from your branch into master
(10.) Your changes and PR get approved, your reviewer deletes your remote branch upon merging
11. git fetch --all --prune clean up your local git by untracking deleted remote branches

Other helpful commands are listed below.

12.6 Commonly Used Git Commands

Table 12.2: Commonly used Git commands
Command Description
git clone <url> <directory_name> clone a repository, only needs to be done the first time
git pull origin master pull from master before making any changes
git branch check what branch you are on
git branch -a check what branch you are on + all remote branches
git checkout -b <new_branch_name> create new branch and go to it (only necessary when you create a new branch)
git checkout <branch name> switch to branch
git add <file name> add file to stage for commit
git add -p adds changes to commit, showing you changes one by one
git commit -m <commit message> commit file with a message
git push -u origin <branch_name> push branch to remote and set to track (-u only works if this is first push)
git branch --set-upstream-to origin <branch_name> set upstream to origin/<branch_name> (use if you forgot -u on first push)
git push origin <branch_name> push work to branch
git checkout <branch_name>  git merge master switch to branch and merge changes from master into <branch_name> (two commands)
git merge <branch_name> master switch to branch and merge changes from master into <branch_name> (one command)
git checkout --track origin/<branch_name> pulls a remote branch and creates a local branch to track it (use when trying to pull someone else’s branch onto your local computer)
git push --delete <remote_name> <branch_name> delete remote branch
git branch -d <branch_name> deletes local branch, -D to force
git fetch --all --prune untrack deleted remote branches

12.7 How often should I commit?

It is good practice to commit every 15 minutes, or every time you make a significant change. It is better to commit more rather than less.

12.8 Repeated Amend Workflow

When working on a complex task, you may want to make frequent incremental commits to protect your progress, but avoid cluttering your Git history with many tiny “work in progress” commits. The Repeated Amend pattern lets you build up a polished commit gradually.

12.8.1 Basic Workflow

Start with a clean working tree in a functional state. Then:

  1. Make a small change and verify your project still works
  2. Stage and commit with a temporary message like “WIP” (work in progress)
  3. Do not push yet
  4. Make another small change and verify it works
  5. Stage and amend the previous commit: git commit --amend --no-edit
  6. Repeat steps 4-5 as needed
  7. When finished, amend one final time with a proper commit message
  8. Push your completed work

In RStudio, you can use the “Amend previous commit” checkbox when committing.

12.8.2 Key Points

  • Each amend replaces the previous commit rather than creating a new one
  • This keeps your history clean while letting you work incrementally
  • Only use this pattern before pushing - never amend commits that others may have pulled
  • If you need to undo changes, use git reset --hard to return to your last commit state
  • Think of commits as climbing protection: use them when in uncertain territory

For more details and troubleshooting scenarios, see the Repeated Amend chapter in Happy Git with R.

12.9 What should be pushed to Github?

Never push .Rout files! If someone else runs an R script and creates an .Rout file at the same time and both of you try to push to github, it is incredibly difficult to reconcile these two logs. If you run logs, keep them on your own system or (preferably) set up a shared directory where all logs are name and date timestamped.

There is a standardized .gitignore for R which you can download and add to your project. This ensures you’re not committing log files or things that would otherwise best be left ignored to GitHub. This is a great discussion of project-oriented workflows, extolling the virtues of a self-contained, portable projects, for your reference.

12.10 Customizing How Files Appear on GitHub

GitHub uses a tool called Linguist to detect languages in your repository and generate language statistics. You can customize how certain files are treated by GitHub using a .gitattributes file in the root of your repository. This is particularly useful for marking generated files, documentation, or vendored code that shouldn’t count toward your repository’s language statistics.

12.10.1 The linguist-generated Attribute

One of the most useful attributes is linguist-generated, which marks files as generated code. Files marked this way are:

  • Excluded from language statistics - they won’t affect your repository’s language breakdown
  • Hidden by default in diffs - making pull request reviews cleaner and more focused on actual code changes

Common use cases for linguist-generated include:

  • Compiled or minified files (e.g., *.min.js, *.min.css)
  • Auto-generated documentation files
  • Files generated by build tools or code generators
  • Lock files that are updated automatically

For more details, see the Generated code documentation.

12.10.2 Using .gitattributes

Create a .gitattributes file in the root of your repository and add patterns for files you want to mark as generated:

# Mark minified JavaScript as generated
*.min.js linguist-generated

# Mark search index as generated
search/index.json linguist-generated

# Mark compiled CSS as generated
dist/styles.css linguist-generated

To unmark a file that would normally be considered generated:

# Don't treat bootstrap as generated
bootstrap.min.css -linguist-generated

The .gitattributes file uses the same pattern matching rules as .gitignore. For more details, see the pattern format documentation and the Using gitattributes guide.

12.10.3 Other Useful Linguist Attributes

Beyond linguist-generated, you can use several other attributes:

  • linguist-vendored - Marks vendored code (libraries you didn’t write) to exclude from stats (documentation)
  • linguist-documentation - Marks documentation files to exclude from stats (documentation)
  • linguist-detectable - Forces a file type to be included in language stats (useful for data or prose files) (documentation)
  • linguist-language=<name> - Overrides the detected language for syntax highlighting (documentation)

Example .gitattributes file:

# Exclude vendored dependencies
vendor/* linguist-vendored

# Exclude generated files
*.generated.ts linguist-generated
dist/* linguist-generated

# Mark documentation
docs/* linguist-documentation

# Force R Markdown files to be detected
*.Rmd linguist-detectable

For complete documentation, see Customizing how changed files appear on GitHub and the Linguist overrides documentation.