Git Tutorial and Cheat Sheet

This tutorial skips over some details as it is intended to accompany classroom discussion. However, it does provide more hand-holding than a cheat sheet. This tutorial is a simplified and updated version of Andrew Burgess’ 2009 Tutorial on TutsPlus.

A Note on Syntax: Be sure to exclude the brackets [] in the examples below. Use your custom values instead.

The install section of the Git book provides details for Mac, Windows, and Linux environments.

$ git config --global user.name "Your Name"
$ git config --global user.email "your@email.com" 

Add text coloring to the bash terminal:

$ git config --global color.ui auto

$ git config --list

C:\users\%UserProfile%\

Only done and needed for a new project (top-level folder). Leave out the repository (repo) name so it will default to “master.”

$ cd C:\wamp\www\python\extreme-moves-app

$ git init 

This creates (initializes) a Git repository in your project folder. The .git folder that’s created and initialized tracks changes to your code and denotes it with a secure hash on each commit.

We always create a new branch (1) before and (2) when we intend to make drastic changes to the branch we are located in!

But, before we tell you how to create branches, this is how you view a project’s branches:

$ git branch

Create a New Branch

First, checkout the branch you want to fork from. We call this the “parent” branch! Second, create a branch of that “parent”. Here are the steps:

1. Work on (i.e., checkout) the branch you want to fork:

$ git checkout [branch-name]

2. Create a new branch:

$ git branch [branch-name]

$ git checkout -b [branch-name] ([parent-branch-name])

$ git checkout -b [new-branch-name]
$ git add .
$ git commit -m "rewrote core code. deleted old test files. reorganized folders"

The staging area “holds” files and their changes for your next commit:

$ git add .

The . will stage all changed and untracked files. You may also use wild cards and specific file names to stage certain files and types:

$ git add *.css
$ git add hello.py

$ git commit -m "descriptive msg as to why code was committed"

$ git commit -am "message, so you know why that code was committed"

git commit --amend

$ git config --global --get core.editor

$ git config --global core.editor "code --wait"
$ git config --global format.commitMessageColumns 72

$ git config --global core.editor "nano"

$ git commit -av 

The git status command shows you which files were changed (modified) and new (untracked) since your last commit.

$ git status

This is done after we finish creating and testing a new feature. We merge the child branch into it’s parent branch. Upon a merge, the changes in the child will overwrite the existing files of the parent.

Merge a branch (child) into the branch you’re currently working on (parent) like so (make sure you’re in the branch you want the child branch to be merged into):

$ git merge [branch-name-I-want-to-merge]

Delete branch (child) after merging (into parent):

$ git branch -d [branch-name]

Delete branch that you never merged:

$ git branch -D [branch-name]

Experiment with the below and learn what they do!

$ git log

$ git log --graph

$ gitk --all  #color gui

$ gitk path/to/file

$ git log -p -- path/to/file

$ git log --follow -p -- file

Stashing is a power user feature. Here are two use-cases of why and when to use git stash

1. You started working in “branch a”. After 3 hours of coding you realize your changes would be better off in a new branch, say “upgrades/mega-filter”. Also, your changes were previously committed to this “branch a” during your first hour. So, Git won’t let you switch and commit these changes to a new branch!
   Here’s the solution:
   a. Create a stash:

   $ git stash

   b. Create a new branch from the stash:

   $ git stash branch upgrades/mega-filter



2. From the Git stash docs: “You’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later.”
   The solution would be to stage your changes and then create a stash:
   a. Stage Changes:

   $ git add .

   b. Stash changes:

   $ git stash

   Warning: Always Stage Before You Stash

   Always stage your changes before you stash! If you do not (1) stage your changes before stashing and (2) then switch to another branch, you will (3) receive a merge conflict error CONFLICT (content): Merge conflict in XYZ when you attempt to recover your stashed files! You do not want this to happen! Always stage before stashing!

   Now, you’re free to checkout any branch you want to work on! And, when you’re ready return to your stash, just do:

   $ git checkout [branch-that-you-stashed]

   $ git stash apply

Social Coding: Connecting to GitHub and BitBucket

1. Connecting to GitHub

Generate a new SSH key for GitHub:

NB: RSA signatures are no longer recommended for modern computers.

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
$ ssh-keygen -t ed25519 -C "your_email@example.com" -f custom_name_to_save_as

Where:
-t = Specify the digital signature algo to use -C = comment stored in the public key file. It serves the ssh key identifier
-f = optional parameter used to save key file with a custom name. Default file name is the digital signature algo used (e.g., rsa.pub or ed25519.pub)

$ ssh-agent -s

# If using MINGW64 (i.e., Windows users) type this instead:
$ eval $(ssh-agent -s)

$ ssh-add -l

$ ssh -vT git@github.com

2. Connecting to BitBucket for the First Time

GitHub’s SSH documentation is better than Bitbucket’s. So once you’re set up on GitHub, log into your Bitbucket account, and do the following to connect it to:

1. Within git bash, copy your SSH public-key:

   $ clip < ~/.ssh/id_rsa.pub

2. On Bitbucket's website, click the icon in the lower left, then select "Bitbucket Settings" from the menu
3. On the left side of the resulting page there are 3 columns of list menus. On the third column (a long menu of links), click "SSH Keys" which is under the "Security" header
4. Click the "Add Key" button and paste your public-key
5. Within git bash, verify your connection to bitbucket:

   $ ssh -T git@bitbucket.org

Cloning a Repo

Cloning is primarily used to quickly get a local copy of a repository from the source code's owner. Cloning without forking is done when we do not intend to contribute to the original project. Unlike a fork, a clone does not maintain a connection with the original owner's source (i.e., upstream) repository.

When we clone a repo, we save it to our local drive. The process is as follows:

#Using https:
$ git clone https://github.com/your-user-name/project-name [name-of-folder-to-clone-to]

#Using ssh (note the repo name must end in .git):
$  git clone git@github.com:your-user-name/project-name.git  [name-of-folder-to-clone-to]

Cloning a Private Repo

Although, forking is not permitted on private repos, you may clone and then submit pull requests for merges. If you use GitHub from the command line here is how you clone a private repo:

1. Using https:

   git clone https://Your_GitHub_Username:$your_GitHub_token@github.com/CodeSportLabs/programmable-nfts.git

   Using ssh:

   git clone git@github.com:CodeSportLabs/programmable-nfts.git

   NB:The repo is automatically tagged as origin when you clone it

2. How to clone a specific branch:

   git clone -b my-branch https://Your_GitHub_Username:$your_GitHub_token@github.com/CodeSportLabs/programmable-nfts.git

3. Create a new branch, make your edits, stage and commit locally. Then push your new branch to the repo.

Transfer a Repo to Another Git Provider

Cloning is also used as an intermediary step to transfer (or duplicate) a repo onto another git provider. If you need to transfer the repo to another provider (e.g., transfer from Github to Bitbucket), first initiate a clone as above, then proceed as follows:

# Step 1: Go to Bitbucket and manually create a new and empty repo with the name of the project you want to clone

# Step 2: On your local drive 'cd' into the project you just cloned in the prior steps
$ cd project-name

# Step 3: change the Github remote from 'origin' to 'upstream'*
$ git remote rename origin upstream

# Step 4: Finally, add the new Bitbucket repo as the 'origin'  
$ git remote add origin git@bitbucket.org:your-user-name/project-name.git

# Step 5: Push all branches to Bitbucket once**:
$ git push -u --all origin

Forking a Repo

The forking process is defined by manually creating a duplicate of a repo on your git provider’s website. Here is a nuance between forking and cloning:

A forked repository differs from a clone in that a connection exists between your fork and the original repository itself. In this way, your fork acts as a bridge between the original repository and your personal copy where you can contribute back to the original project using Pull Requests.

–Forking vs Cloning via Github

GitHub has solid documentation on forking, so we’ll punt in this section and refer you to their help doc called Forking a Repo. Here’s summary of the the workflow taken from the above link:

Forks are the first step in either proposing changes to someone else’s project or to use someone else’s project as a starting point for your own idea.

Forks are often used to propose changes for bug fixes. For example, instead of logging an issue for a bug you’ve found, you can:

1. Fork the repository [make a remote repo] and then clone it to your local machine [make a local repo]
2. Create a new branch were you plan to make your fixes
3. Make your fixes (and test them)
4. Push your fix from your local repo to your remote repo
5. Submit a pull request to the project owner (Note: Pull requests are done on the Github/Bitbucket websites, not the command line)

–Forking a Repo via Github

Once you fork, you’ll also want to:

1. Synch your local copy to ensure you’re working with the latest version of the original owner’s repo

   $ cd [project home directory]
   $ git remote add upstream git@github.com:ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git 
   $ git fetch upstream
   $ git checkout master
   $ git merge upstream/master
   

2. After synching your local copy, then push the changes out to your remote fork on Github/Bitbucket to keep it in synch with your local version

   $ git push origin master
   

First, refer to GitHub’s tutorial on creating a personal access token for the command line. Items in red should be customized to your use case:

curl -H "Authorization: token PLACE_GITHUB_TOKEN_HERE" https://api.github.com/user/repos -d '{"name":"PROJECT_NAME", "private":"true", "description":"DESCRIPTION GOES HERE", "homepage":"https://codesport.io"}'

NB: If you’re creating a repo for an organization, change:

https://api.github.com/user/repos

https://api.github.com/orgs/COMPANY_NAME/repos

git remote add upstream git@github.com:GITHUB_USER_NAME/PROJECT_NAME.git

git push -u upstream master #NB: for first commit -u is shorthand for '--set-upstream' and activates branch tracking

If you have a brand new local project that you’d like to push out to GitHub, please be sure you’ve created an empty repo on GitHub first. This may be done via the command line. Or manually pressing a button on GitHub.

Below is the full workflow:

1. First create an empty repo on GitHub by following the steps mentioned above, in Create a Remote Repo on GitHub via the Command Line
2. Configure Project’s Push Destination from CLI

   $ git remote add [name][url]

In the example below, the name of push destination [name] is upstream and [url] is git@github.com:codesport/repo-name.git:

$ git remote add upstream git@github.com:codesport/repo-name.git

3. Push Project to the Newly Created Remote Repo for the First Time

Continuing with the example above, to push the current branch and set the remote as upstream do

$ git push --set-upstream upstream master

4. Push Subsequent Updates to Remote Repo

   $ git push upstream master

Pre-existing Repos Forked from Others

For pre-existing repos that you have forked and are modding, use the below workflow:

Use git push to send commits made on your local branch to a remote repository.

$ git push origin [your_local_branch_name]

Alternatively, you may use git push -u origin [your_local_branch_name] the first time you push out an update.

Where: -u is shorthand for --set-upstream. This activates branch tracking. And, with tracking on, for subsequent pushes you just type git push.

See these Stack-overflow Q&As for further context

• How do I push a new local branch to a remote Git repository and track it too?
• Git: Pushing to a Remote Branch
• Pushing a New Branch in Git

$ git remote

$ git push remote_name branch_name

git branch -m [old_name] [new_name]

git push [remote] --delete [old_name]

git push [remote] :[old_name]

git push [remote] [new_name]

git push [remote] -u [new_name]

git branch -d [bad_branch_name]

Terminology: Pull Requests vs git pull

A Pull Request happens when you (1) make changes to a branch (or a fork) and (2) request that the original owner(s) pull your changes into their repository. Hence, the term “pull request”.

Pull requests lie in the domain of social coding platforms such as GitHub and Bitbucket. While git pull is a git command. Yangsu has a good tutorial where you may learn both by doing a simple example! Here are some quotes that sum things up:

Pull requests let you tell others about changes you’ve pushed to a GitHub repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary. — GitHub Help: Using Pull Request

…git pull does a git fetch followed by a git merge. A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches. — Greg Hewgill