arosenkranz/Git-Rules.md

## git-commands.md

      
    Raw
  

              git-commands.md
            
          
    Create

git clone ssh://user@domain.com/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

      
    Raw
  

              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.