Getting Started with Git and GitHub at Chico State

Quick Links: | Article Summary | What Git Is | Git at Chico State | Understand the Git Workflow | Clone a Repository | Pull Changes | Make and Commit Changes | Push Changes | Common Git Terms | Good Commit Messages |

Article Summary  

This article introduces Git and GitHub to Chico State faculty and staff who are new to version control. It explains what Git is, why it can be useful in higher education, and the basic workflow for getting a repository onto your computer, keeping it current, saving your work, and sharing changes with others.

You do not need to be a software developer to use Git. Although Git is commonly associated with programming, it can be used to manage many types of files where tracking changes and collaborating with others is useful.

This article focuses on four common actions you will encounter when getting started:

  • Clone – Make a local copy of a repository on your computer.
  • Pull – Bring the latest changes from the shared repository into your local copy.
  • Commit – Save a meaningful snapshot of your changes in Git.
  • Push – Send your local commits back to the shared repository on GitHub.

What Git Is  

Git is a version control system. Version control keeps a history of changes made to files over time. Instead of relying on filenames such as Document-Final.docx, Document-Final-v2.docx, and Document-Really-Final.docx, Git records changes as part of an organized history.

A collection of files managed by Git is called a repository, often shortened to repo. A repository contains the project files along with their version history.

GitHub is a platform that hosts Git repositories and provides tools for sharing repositories, collaborating with other people, reviewing changes, tracking work, and maintaining documentation.

Diagram showing the relationship between Git and GitHub. On the left, a faculty or staff member uses a computer with a local repository containing files and a history of changes. On the right, GitHub hosts a shared repository. Arrows show Pull bringing changes from GitHub to the local repository and Push sending changes from the local repository to GitHub. Git tracks changes and keeps a history of work.

How Git Can Be Used at Chico State  

At Chico State, GitHub Enterprise provides faculty and staff with an institutionally supported environment for managing and collaborating on code, scripts, and related digital materials.

Git and GitHub may be useful for higher education work such as:

  • Maintaining scripts, configuration files, or other technical resources used by a department.
  • Collaborating with colleagues on shared projects.
  • Maintaining documentation alongside the files or systems it describes.
  • Keeping a history of how project files have changed.
  • Reviewing proposed changes before adding them to the primary version of a project.
  • Returning to an earlier version or understanding when and why something changed.

Chico State GitHub Enterprise access is currently available to faculty and staff only. Students are not supported at this time.

Access to GitHub Enterprise does not automatically provide access to every repository. You must also have permission to access the repository you want to use.

Understand the Basic Git Workflow  

For a new Git user, it can help to think of Git as a cycle between a shared copy on GitHub and a local copy on your computer.

  1. Clone the repository the first time you work with it.
  2. Pull before beginning new work to get changes made by other people.
  3. Make changes to files on your computer.
  4. Commit your changes with a short description of what changed.
  5. Push your commits to GitHub.
  6. When appropriate, create a pull request so the changes can be reviewed and merged.
  7. Continue to pull regularly so your local repository stays current.

Circular workflow diagram showing the basic Git process. The steps are: Clone a repository from GitHub to your computer, Pull the latest shared changes, Edit files on your computer, Commit changes with a description, Push commits to GitHub, and Review or Merge changes. The diagram shows the process repeating, with work happening between a local computer and the GitHub shared repository.

Clone a Repository for the First Time  

Cloning creates a complete local copy of a Git repository on your computer. You normally clone a repository only once on each computer where you plan to work with it.

Before cloning a Chico State repository, confirm that you have access to both Chico State GitHub Enterprise and the repository.

  1. Open the repository in GitHub.
  2. Locate the repository's option for cloning or copying the repository URL.
  3. Copy the repository URL.
  4. Open the Git application or command-line tool you will use to work with the repository.
  5. Choose the location on your computer where the repository should be stored.
  6. Clone the repository using the URL you copied from GitHub.
  7. After cloning is complete, open the local repository and confirm that the repository files are available.

Cloning establishes a connection between your local repository and the remote repository on GitHub. Git commonly gives that remote connection the name origin.

In other words, when Git displays a name such as origin, it usually means "the remote repository this local copy came from."

Diagram explaining Git clone and origin. A GitHub shared repository on the left is copied to a local repository on a user's computer through a Clone action. A connection between the two repositories is labeled origin, showing that Git uses this name for the remote repository where the local copy came from.

Pull the Latest Changes Before Starting Work  

After a repository has been cloned, other people may continue making changes to the shared repository on GitHub. Your copy does not automatically contain every new change.

A pull downloads the latest changes from the remote repository and updates your local repository.

  1. Open your local repository using your Git application or command-line tool.
  2. Before beginning new work, check for changes from the remote repository.
  3. Use Pull to retrieve the latest changes.
  4. Allow Git to update your local repository.
  5. Begin your work after your local repository is current.

A useful habit is: Pull before you start; push when your work is ready to share.

Make Changes and Create a Commit  

After your repository is current, work with its files as you normally would. Depending on the repository, this might mean editing documentation, changing configuration information, updating a script, or modifying other project files.

When you reach a useful stopping point, create a commit. A commit records a snapshot of the changes you have selected along with a short description called a commit message.

  1. Make the necessary changes to files in your local repository.
  2. Save the files.
  3. Review which files have changed before committing them.
  4. Select the changes that belong together.
  5. Write a short commit message describing the purpose of the change.
  6. Create the commit.
  7. Continue working and create additional commits when there are additional meaningful changes.

A commit is stored in your local repository. Creating a commit does not, by itself, send the change to GitHub. That happens when you push.

Push Committed Changes to GitHub  

Push sends commits from your local repository to the remote repository on GitHub.

  1. Confirm that your changes have been committed.
  2. Pull the latest changes if necessary so you are working with the current version of the repository.
  3. Use Push to send your local commits to GitHub.
  4. Allow the push to complete.
  5. Open the repository in GitHub and confirm that your commits appear as expected.
  6. If your repository uses pull requests, create a pull request when your changes are ready for review.

Comparison diagram showing the difference between Pull and Push in Git. GitHub's shared repository is shown above and a user's local repository is shown below. A Pull arrow points from GitHub to the computer, representing getting changes from GitHub. A Push arrow points from the computer to GitHub, representing sending committed changes to GitHub. A reminder states: Pull brings changes to me; Push sends my changes.

Understand Common Terms You May See  

Git uses several terms that can be confusing when you first encounter them. The following definitions cover terminology commonly used during basic Git work.

Term What It Means
Git The version control system that tracks changes to files.
GitHub The online platform used to host and collaborate on Git repositories.
Repository (Repo) A project and its files, including the history recorded by Git.
Local Repository The copy of the repository stored on your computer.
Remote Repository The shared copy of the repository hosted on GitHub.
Clone Create a complete local copy of a remote repository.
Commit A saved snapshot of selected changes with a description of what changed.
Pull Download the latest changes from the remote repository.
Push Upload your local commits to the remote repository.
Origin The default name Git commonly gives to the remote repository that you cloned.
Branch A separate line of work that allows changes to be made without immediately changing the primary version of the project.
Main The name commonly used for the primary branch of a repository.
Pull Request (PR) A request for other people to review changes before they are merged.
Merge Combine changes from one branch into another.
Merge Conflict A situation where Git cannot automatically combine changes and needs a person to decide which changes should be kept.
README A document that introduces a repository and commonly provides instructions or other important information about it.

Write Meaningful Commit Messages  

Commit messages become part of the repository's history. A useful message helps you and your colleagues understand why a change was made without having to inspect every changed file.

Keep commit messages short, specific, and focused on the change.

Less useful commit messages:

  • Updates
  • Changes
  • Fixed stuff
  • More edits
  • Final version

More useful commit messages:

  • Update installation instructions for Windows
  • Correct department contact information
  • Add instructions for requesting repository access
  • Fix incorrect link in README
  • Update configuration for new server name

A good test is to imagine another faculty or staff member reading the message six months from now. They should be able to get a reasonable idea of what changed without having to guess.

Diagram comparing unclear and descriptive Git commit messages, showing how meaningful messages make project history easier to understand.

Continue Learning Git  

Once you are comfortable with cloning, pulling, committing, and pushing, the next concepts to learn are branches and pull requests. These features allow you to work on changes separately and have those changes reviewed before they are merged into the primary version of a repository.

You do not need to learn every Git command before beginning. For most new users, understanding the relationship between your local repository and the shared repository on GitHub is the most important first step:

  • Clone once to get your copy.
  • Pull to get current.
  • Commit to record meaningful changes.
  • Push to share those commits.

 Still need help? Add your department's information or a link to a ticket type for further troubleshooting.
  
 Please do not leave the comment section blank! Provide constructive feedback to make this page better.

Print Article