git cheat sheet

Here's the rundown of my basic git workflow. Please note:

• This cheat sheet assumes you
  1. signed up for GitHub and know how to make a repository (module 2)
  2. understand terminal basics (module 10)
• Code in italics is a placeholder and should be replaced with names or paths specific to your project.
• git is the command line (terminal) tool, while GitHub is the website that hosts your git repositories.
• Don't type text following a # in the commands below. These are comments to explain each command.

1. Setting up a project
2. Workflow
3. Pull requests and merge conflicts
4. Merge conflicts

Setting up a project

The below is a one-time setup procedure. Start by creating a repository or forking an existing repo on GitHub. git clone should refer to your fork of someone else's repo or an original repository you created. add upstream should refer to someone else's original repository (not your fork), or your original repo if you created it.

git clone https://github.com/username/repo.git               # copy the repository
cd repo                                                      # open the repository directory
git remote add upstream https://github.com/username/repo.git # set the upstream repository

Workflow

After you've cloned a repository and set the upstream remote, here's a workflow to use as you code:

git pull upstream master    # merge changes from upstream repository into master branch
git push origin master      # push the latest changes to your repo

#### code away! ####

git add filename            # or use 'git add -A ' to add all modified files
git commit -m "description" # create a commit
git push origin master      # push your changes to your repo

#### open a pull request if necessary (see below) ####

At this point, your changes were pushed to origin (your version of the repository), but if you forked the repository from another source, that source (upstream) doesn't have your changes. To ask the owner of that repository to merge your changes into the upstream repository, open a pull request and wait for the repository owner to merge your changes (or ask you to make modifications). If the owner adds you as a collaborator, you can push your code directly to the upstream repository or merge your pull request.

Pull requests

If you're an owner of a repository, people who fork your repository may submit pull requests, or proposed changes to the files in the repository. If you trust the person submitting the pull request (and there are no merge conflicts--more on this below), you can simply merge the changes on GitHub after taking a look at their proposal. However, in many cases, you'll want to run and test the code locally before merging.

Merge conflicts

It often happens that a pull attempts to modify a file that has since been changed in the same location: there are two mutually exclusive versions and a decision has to be made about which will remain. This scenario is called a merge conflict. Resolving a merge conflict involves choosing between the two versions, modifying the code accordingly, then staging changes as normal with git add . and making a commit.