Git and Github Cheat Sheet

Overview

Git is a version control system that we use in programming.
GitHub is a website that allows us to share Git repositories. * Repositories are a container for our folders and files that make up a project.
In order to keep our code safe, we use a branching workflow that allows us to make changes to multiple files before fully commiting to those changes.
Commit messages help us create a readable history of changes.

Git

What is Git?

Git is a Version Control System (VCS). It allows you to save work on your project, and reference previous states of a project if needed. Normally when we save something on our computer, the newer version overwrites the older version. This is problematic if we need to look back at an earlier version. Git solves this problem by providing you multiple save points. You can get the current version, and ANY previous version. Git’s philosophy: never lose anything.

Commits

Saving your work in git is known as committing. Even though you may change a file and hit save, you don’t actually save it to your git repository until you use the commit command.

Changes can be in 3 different states:

Unstaged: we have made changes but not told git that we would like to commit them

Staged: we have made changes and told git that we are getting ready to commit them

Committed: we have committed our changes to the repository’s log of commits. Our work is saved.

Important Git Commands

init - create a git repository in the current directory.
status - show what changes have been made. This will show changes that are staged and unstaged.
add <file name> - stage a change for commit.
- ex: git add credit_check.rb
commit -m "<commit message>" - commit a change. Each commit requires a commit message (must be in quotes).
- ex: git commit -m "feat: add search"

Writing Good Commit Messages

Commit messages should be a short description of what is being added, changed, or removed in our code. Writing clear and consistant messages allows us to create a more readable history for ourselves and others. Commits should be specific and small pieces of functionality so that our messages can clearly reflect those changes in a brief message (approximately 50 characters).

How to Write a Good Commit Message

Begin the commit message with the type of the commit followed by a : and brief description.

Types of commits include:

fix - use if committed code is fixing a bug(broken code).
feat - stands for feature. This will likely be your most common type that you use. It should be used for any new functionality that is committed.
test - use if committed code is adding test functionality.
refactor - use if updating and/or removing existing code.
docs - use if updating your readme.

Examples of good commit messages:

fix: broken calculation for percent high ranking cards
feat: add shuffle to deck
test: add test for shuffle

Git Workflow

Creating a Git Repository

Use mkdir to create a new directory.
cd into that directory.
Run git init to make that directory a Git repository.

Committing Changes

These are the steps you should take to make changes and save them to your repository.

git status - make sure our working directory is clean, which means there are no changes. If there are changes, we need to figure out what to do with them, either commit them or stash them.
Make changes - e.g. create or update files
git status - we should see the files we changed as unstaged.
git add name of file we changed - stage those changes for commit. We need to do this for each file we changed.
git status - we should see the files we changed as staged for commit.
git commit -m "feat: add new method" - commit the changes.

Practice!

Using the commands above:

Create a new directory called git_practice.
Make your git_practice directory a Git repository.
Create a file inside of that directory called README.md and add some text to that file.
Commit your changes
Make some additional changes
Commit those changes

Github

GitHub is a website for hosting git repositories.

The git repository on your computer is called the local repository. It is only accessible through your computer. If you are working with a partner, they cannot access it on their computer. That’s where Github comes in. When you push your repository to Github, you are creating a remote repository. It is in the cloud and collaborators can access it through the web.

Before GitHub, developers or companies configured and ran their own independent git servers, and things were much more fragmented. Now GitHub has become the de facto community standard for hosting and sharing repositories.

You certainly don’t need GitHub to use git, but its popularity and dominance, especially within the open source community, have intertwined the 2 for many users.

As you progress through becoming a more practiced git user, don’t forget that these are 2 distinct things – git provides the core technology for tracking and managing source control changes, while GitHub provides a shared location for hosting git projects.

Creating a New Repository on GitHub

In order to create a new repository on GitHub we need to visit the site and click on the green New button next to the Repositories heading on our dashboard.

Name the new repository the same as what you have named the directory that you’re working in. The other default values should be fine for our purposes.

Commands for interacting with GitHub

Once you’ve created a new repository on GitHub, you need to link that repository to your local repository. We need to add a remote.

remote -v - this will show you what your remote repository is configured as. This is helpful for debugging.
remote add remote_name remote url - This adds a new remote. If you type remote -v and nothing shows up, it means you have no remotes and you will need to use this command to add one. Usually, you only need to do this once when you are setting up a project.
push remote_name branch_name - Update your remote repository to match your local repository. The remote name is almost always origin. The branch name is whatever branch you want to push to (more on branching further down). For instance, if you are working on the main branch, which is the default branch, the command would be:

git push origin main

pull remote_name branch_name - update your local repository with the changes made to the remote. This will be important when you are working with someone else, and you want to get the changes they made. Similar to pushing, remote name will almost always be origin. Branch name is whatever branch you want to pull from. So if you wanted to get the recent changes to main, the command would be:

git pull origin main note: This will pull the changes in to whatever branch you are currently working in

Git workflow with Github

To set up the link to our repository

pwd - make sure we’re in the right directory
git status - double check that we have already initialized our local Git repository
Create the repo on GitHub
Copy the SSH address from GitHub
git remote -v: this will tell us if we already have a remote repository for this local repository.
git remote add origin <YOUR_SSH_ADDRESS HERE>
git log make sure we have at least one commit
git push origin main

To push to your remote repository

Make changes
git status - we should see the files we changed as unstaged.
git add <name of file we changed> - stage those changes for commit. We need to do this for each file we changed.
git status - we should see the files we changed as staged for commit.
git commit -m "short message about the changes we made" - commit the changes.
git push origin main

It is important to note that you do not have to push every time you commit. You can make several commits, and push will send all the new commits you made at once.

Practice

Create a new repository called git_practice
Add the remote to your local git_practice repository
Push your existing commits to the GitHub repository
Make additional changes to your README
Commit them
Push your changes to GitHub

Branching

If you do git status you’ll see part of the status is “On branch main”. Branches represent a line of development. The main branch is the default branch, and is typically where the code works without known bugs.

Switching to a branch is called a checkout. When you checkout a new branch, it can serve as a sandbox for development where you can make changes or experiment with a research spike without affecting the main branch. If whatever you are trying doesn’t work, no big deal; your main branch remains intact.

This link shows some helpful visuals related to git branches.

More info on branching.

Branching commands

branch - view a list of branches
branch branch_name - create a new branch

ex: git branch new_feature

checkout branch_name - switch to a branch

ex: git checkout main

checkout -b branch_name> - create and switch to a branch in one command

ex: git checkout -b new_feature

push remote_name branch_name - push to a branch. If the branch doesn't exist in your remote, Github will create a new one for you.

ex: git push origin new_feature

pull remote_name branch_name - pull from a branch. Generally you want to be pushing to feature branches (branches where you're working on code) and pulling from main.

Pull Requests

If what you did in a branch works and you want to add it to the main branch, you will merge that branch into the main branch.

Pull Requests are a Github feature that allows us to merge code from one branch into another. The name “Pull Request” can be confusing because you are actually trying to merge code rather than pull it. Some other online systems such as Gitlab call them “Merge Requests” for this reason.

Not only do Pull Requests allow you to merge branches, they allow other collaborators to look at the code you added, make comments, and review your changes BEFORE the code gets merged. They are a very powerful collaboration tool, and used extensively in the industry.

Git Workflow with Branching and Pull Requests

This is the final version of our workflow, and is what you should be doing on every project, partner or solo.

git status - make sure our working directory is clean. If there are changes, we need to figure out what to do with them, either commit them or stash them.
git pull origin main - Make sure you are up to date with the latest version of main.
git branch feature_name - make a new branch based on a feature you want to add. Alternatively, you can use git checkout -b feature_name to create and checkout the branch in one command.
git checkout feature_name - Checkout the branch
Make changes
git status - we should see the files we changed as unstaged.
git add name_of_file_we_changed> - stage those changes for commit. We need to do this for each file we changed.
git status - we should see the files we changed as staged for commit.
git commit -m "short message about the changes we made" - commit the changes.
git push origin feature_name - Push your branch to Github.
Repeat steps 4 - 10 until the feature is complete
Put in a Pull Request (PR) to merge your branch into main.
Visit GitHub and merge your pull request into main.
git checkout main - Switch back to the main branch.
git pull origin main - Make sure that you have the most recent changes that you made on your local main branch.

Practice

Check out a new branch
Make some additional changes to your README
Commit those changes
Push your change to the branch on GitHub
Visit GitHub
Create a pull request
Merge your pull request
Check out your main branch locally
Pull your changes into your main branch

Wrap-Up

How do you create a git repository locally?
What should be included in a git commit message?

Git and Github Cheat Sheet

Overview

Git

What is Git?

Commits

Important Git Commands

Writing Good Commit Messages

Git Workflow

Creating a Git Repository

Committing Changes

Practice!

Github

Creating a New Repository on GitHub

Commands for interacting with GitHub

Git workflow with Github

To set up the link to our repository

To push to your remote repository

Practice

Branching

Pull Requests

Git Workflow with Branching and Pull Requests

Practice

Wrap-Up

Lesson Search Results

Showing top 10 results