Git Cheatsheet

git-commands.md

Create

git clone ssh://[email protected]/repoName.git

Clone an exisiting repository

git init

Create a new local repository (do this if one isn't already made in GitHub)

---

Local Changes

git status

View changed files in your working directory (includes untracked files)

git diff

View changes to tracked files

git add .

Add all current changes to the next commit (called staging)

git add <fileOrFolderName>

Add only particular file's or directory/folder's changes to next commit

git commit -a

Commit all local changes in tracked files (won't use as much)

git commit -m "reason for commit"

Commit changes and write a message for what you're committing (will use primarily)

git commit --amend

Change the last commit (don't do this after a git push)

---

Updating & Publishing

git remote -v

List all currently attached remotes (GitHub / Heroku are remotes of your local Git)

git remote show <remoteName>

Show information about a remote

git remote add <remoteName> <remoteURL>

Add new remote repository

git remote rm <remoteName>

Remove remote repository by name

git fetch <remoteName>

Download all changes from (typically origin) but don't integrate/merge into files just yet

git pull <remoteName> <branch>

Download changes from (typically origin) and it's particular branch (typically master)

git push <remoteName> <branch>

Publish local changes on a remote to a particular branch (i.e. git push origin master). You do this AFTER a git add and git commit so Git knows what you're pushing up.

git branch -dr <remoteName/branch>

Delete a particular branch from remote

---

Branches

git branch -av

List all available branches and most recent commits to each

git branch <branchName>

Create a new branch based on your current HEAD or step into a local branch

git checkout -b <branchName>

Create a new local branch and step into it

---

Undo

git reset --hard HEAD

Discard all local changes in your working directory

git reset --hard origin/master

Discard all local changes and making it match the remote and base (GitHub repo)

git revert <commitCode>

Revert a commit (commitCode will be provided to you by typing in git log and getting the associated code with it)

Git-Rules.md

COMMIT RELATED CHANGES

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

COMMIT OFTEN

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.

USE BRANCHES

Branching is one of Git‘s most powerful features - and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…

DON'T COMMIT HALF-DONE WORK

You should only commit code when it‘s completed. This doesn‘t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in the repository before leaving the office at the end of the day. If you‘re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git‘s «Stash» feature instead.

WRITE GOOD COMMIT MESSAGES

Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions:

›› What was the motivation for the change?

›› How does it differ from the previous implementation?

Use the imperative, present tense («change», not «changed» or «changes») to be consistent with generated messages from commands like git merge.