Note: Config files are plain text files and can be edited manually.
Options can be stored:

• per repository (project/.git/config),
• globally for user (~/.gitconfig) – use –global parameter
• globally for all (/etc/gitconfig) – use –system parameter

Local settings override global, which override system wide options.

# List all config values including local:
git config -l

# List only global options:
git config --global -l

# set user name for the current repository:
git config user.name 'Ludovico Zamenhof'

# set email for the current repository:
git config user.email my@email.com

# set editor globally:
git config --global core.editor emacsclient

# pass traffic through *HTTP Proxy*:
git config http.proxy https://127.0.0.1:3128
# or add the following to the .gitconfig file:
# [http]
#     proxy = https://127.0.0.1:3128

mkdir myproject
cd myproject
git init

# myDir is optional target directory name
git clone <path-to-my-git-repository>/myproject.git [myDir]

# Start tracking new file:
git add new-file-name

# Add tracked file to the current changeset:
git add tracked-file

# Add all files (including tracked) from the current
# dir or below to the current changeset:
git add .

# Show every chunk and ask for adding it:
git add --patch

# Remove specified file:
git rm file-name

# Remove all files from the current dir or below:
git rm -r .

# remove from the current changeset if it has been added:
git reset HEAD filename

# Undo last commit, preserving local changes:
git reset --soft HEAD^ # HEAD~1 in Windows

# Undo last commit, deleting local modifications:
git reset --hard HEAD^

# checkout the last committed version, when not in changeset:
git checkout filename

Good description is the 2nd answer here.

# commit staged changes:
git commit -m 'message'

#commit all changes (omitting staging area):
git commit -a -m 'message'

# the same:
git commit -am 'message'

git branch              # list local branches
git branch -v           # like above, but with the last commit
git branch -a           # all (including remote/SVN and tags)
git branch --merged     # show merged branches
git branch --no-merged  # show not merged branches
git tag -l              # show all tags

git branch newBranchName [master]

• master is the branch you are forking from
• no need to add parent name, when forking from the current branch

git checkout -b new_branch_name [old_branch_name]

# Creates local branch newLocalBranch, connected to remote branch remoteBranch
git checkout -b newLocalBranch remoteBranch

git checkout newBranchName

You can do the following (assuming you are checked out on master and want to push to a remote branch master):

# Set up the 'remote' if you don't have it already:
git remote add origin ssh://repo.url

# Now configure master to know to track:
git config branch.master.remote origin
git config branch.master.merge refs/heads/master

# And push:
git push origin master

# Switches back to master:
git checkout master

# Merges branch-name to the current branch, which is
# master in this case. In case of conflicts, you will
# be prompted to fix them in your editor. Add fixed
# conflicts with "git add" and commit.
git merge branch-name

# Or to always create commit merge:
git merge branch-name --no-ff

# Or to merge branch's commits as one large commit:
git merge --squash branch-name

# Show conflicting changes. Staging them will automatically
# mark them resolved:
git status

# Then just commit merge and delete branch if needed.

# Abort the merge process and try to reconstruct
# the pre-merge state:
git merge --abort

It takes patch of the change introduced in a branch and reapplies it on top of another branch. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.

# Rebase changes from the current branch onto target-branch:
git rebase target-branch

# Rebase changes from the from-branch onto the target-branch:
git rebase [target-branch] [from-branch]

# Check out the client branch, figure out the patches from
# the common ancestor of the client and server branches,
# and then replay them onto master:
git rebase --onto master server client

After rebase fast-forward the target branch to include the latest changes:

git checkout target-branch
git merge topic-branch
git branch -d topic-branch

To turn on rebasing on pull (very useful):

git config --global pull.rebase true

# Delete branch:
git branch -d branch_name

# Delete branch even having changes:
git branch -D branch_name

# Deleting remote branch:
git push origin :branch_name

# Removing local ref to deleted remote branch
# (by default "fetch" preserves them):
git fetch -p origin

# Create a branch from a commit (e.g. master~10^2)
git checkout -b new-master

Especially useful for teams that start with git ;-).

# Rename the new branch to master dropping changes
# on old master:
git branch -M new-master master

# Force pushing my master as the new origin/master
# (without fast-forward and using changes on
# origin/master):
git push -f origin master:master

# Getting new master on other machines:
get fetch
git reset --hard origin/master

cd myproject
cat .gitignore
# a comment :-)
/target
pom.xml
*.jar

git rm --cached <file>

#Ignore local changes:
git update-index --assume-unchanged <file>

#Stop ignoring local changes:
git update-index --no-assume-unchanged <file>

#Stop ignoring local changes on all files:
git update-index --really-refresh

cd local-repo
git push --mirror https://github.com/ghuser/repo.git
cd ..
rm -rf local-repo
git clone https://github.com/ghuser/repo.git

git push --tags -v

# Add remote repo:
git remote add upstream <remote-repo>

# List all remotes:
git remote -v

# Fetch all from configured upstream:
git fetch upstream
# Change to local master:
git checkout master
# Merge changes from upstream (if there were no local
# commits, then it does Fast Forward):
git merge upstream/master

git log --walk-reflogs mybranch

git config core.logAllRefUpdates true
# Configure it system wide:
git config --system core.logAllRefUpdates true

git svn clone -s repo.url/mysvnproject myproj

• “-s” tells to git-svn that SVN repository has a standard layout (trunk/branches/tags). If it doesn’t, you can leave that off
• it creates git repo in “myproj” directory and maps it to trunk
• empty directories are not tracked in git, so not shown
• files ingored is SVN are not ignored automatically

# Download all new changesets from SVN, apply them to
# the last checkout from SVN, and then re-apply your
# local changes on top of that:
git svn rebase

# Downloads all changes (including new branches)
# from remote repository.
git svn fetch

# Like above, but skips tags:
git svn fetch --ignore-paths="^tags"
git svn fetch --ignore-paths=".*tags.*"

git svn show-ignore > .gitignore

mkdir repo
cd repo
svn2git https://svn.repo.url
git remote add origin https://git.repo.url
git push origin master
git push --tags