Terminology and Workflow

In this section we provide a glossary of terms and an example of a Git workflow involving two users. We recommend that you familiarize yourself with these terms before proceeding, and follow the example of the workflow in the diagram to better understand what Git is doing when each command is run.

Glossary of Terms

Term	Definition
Git	A popular version control program that allows multiple programmers to collaborate on a software project and keep track of code development.
GitHub	A server that hosts Git repositories remotely.
Command Line	A command line interface is an environment where a user interacts with a computer by typing line-by-line instructions into the computer.
Terminal	An application that allows users to work in a command-line interface. A terminal, such as Terminal on Mac OS and Linux or Git Bash on Windows, is considered Unix-like if it is similar to a Unix terminal.
Directory	A folder on your hard drive.
Repository	A folder that contains all of the files for your project. Your project’s repository contains all of your project’s files, commits, and branches. You can also discuss and manage your project’s work within the repository.
Staging Area	Collection of files of which the user wants to save changes. Files must first be added to the staging area before their changes can be saved into a commit.
Tracked Files	Files in your working directory that Git saves in its repository and checks to see if changes have been made to them.
Untracked Files	Files in your working directory that are unknown to Git. Therefore any changes to these files are not recorded. Any time a user creates a new file, it starts as an untracked file until it is added using `git add`.
Commit	A collection of saved changes that a user has made. After adding files to the staging area, these changes can actually be saved using `git commit`.
Commit Message	String of characters chosen by the user to label the commit.
Commit Hash	String of automatically-generated alpha-numeric characters that Git uses to identify a commit.
Branch	A series of commits in a project, which keeps track of our revision history. Developers usually have multiple branches if they want to maintain different versions of a project. The default branch is called `master`.
Remote	The remote repository is the version of our project stored on a server far away, such as GitHub, which can be contrasted with local repositories. When we push our changes successfully, these changes are reflected in the remote repository. Branches in remote repositories start with `origin/`.
Local	The local repository is the version of our project stored on a individual user’s machine, which can be contrasted with remote repositories. When a user makes changes on a private computer without pushing, the user is only modifying the local repository. Branches in local repositories don’t start with `origin/`. For example, regarding the main branch `master`, the local branch is referred to as just `master`, and the remote branch is `origin/master`.

Workflow

Git is often used by multiple users to collaborate on a coding project. To get a better idea of how this process might work in its use cases, here is an example of how Git is commonly used.

Consider the case where two users want to create a repository, work on some of the files individually, and combine their changes for the final product. This can be accomplished by performing the following steps. An illustration of how these commands interact with the actual repository is also included below.

For more information on how to use these commands, please see the detailed instructions that follow.

One of the users calls git init to create the repository.
User 1 calls git clone to copy the created remote repository so that they can work on their local computer.
User 2 also calls git clone to copy the created remote repository locally.
User 1 starts the project by adding some files to the repository.
User 1 calls git add to add these new files to the staging area so that git knows which files should be saved.
User 1 calls git commit to save the changes in the staging area into a commit.
User 1 calls git push to upload their changes from their local computer to the remote repository so both users can see the changes.
User 2 calls git pull to download the changes made from the remote repository to their local computer and works on the latest version of the repository.
User 2 edits some of the files and creates their own files.
User 2 calls git add to include these files in the staging area.
User 2 calls git commit to save the changes locally into a commit.
User 2 calls git push to upload their changes to the remote repository for both users to see.

This workflow is also detailed in the diagram below: