GIT

Estrutura de trabalho do Git:

SUMINDO COM UM COMMIT PUSHADO! SOME ATÉ O HISTÓRICO

git push -f origin shadocommit:nomedabranch

Working dir ==(add)===> Stash ==(commit)==> git local <==(pull)==(push)==> git remoto

Comandos do dia a dia

git init - inicia um novo repositório local e inicia um diretório de trabalho
git clone URLDOREPOSITORIO - clona um repositório remoto para um local e inicia um diretório de trabalho
git add nomedoarquivo - adiciona um arquivo editado ou criado especificamente. Pode ser uma lista
git add . - adiciona tudo que tiver, inclusive arquivos excluídos ou não adicionados ao git ainda
git commmit -m "Mensagem" - Commita um arquivo 

Branches

git fetch && git checkout origin/nomedabranch - pega a branch remota
git branch nomedabranch - cria uma branch
git checkout nomedabranch - vai para a branch criada
git branch -tb nomedabranch - cria e vai para a branch
git push nomedorepositórioremoto nomedabranchlocaleremota (normalmente é origin, pois é o nome do remoto automático ao clonar)

Merges

git pull origin nomedabranch - é aconselhável sempre pegar a versão última versão remota antes de fazer merge com a branch local
git checkout nomedabranch - faça o checkout da branch a ser mergeada (master, por exemplo)
git merge nomedabranchorigem - faça o merge da branch atual com a branch que tem o trabalho novo

Outros repositórios remotos

git remote -v - lista os remotos
git remote add nomedoremoto urldoremoto - adiciona outro remoto
git remote rm nomedoremoto - remove um remoto

Configurações importantes / interessantes
=========================================
Configurando o git para armazenar a autenticação global:

$ git config --global credential.helper store

Utilizando o Meld como diff ou merge tool

$ git difftool -t meld
$ git mergetol -t meld

Definindo um proxy:

$ git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
$ git config --global --unset http.proxy
$ git config --global --get http.proxy

Em caso de problemas com o SSL do servidor (SSL certificate problem: self signed certificate):

$ git config --global http.sslVerify false

Desfazendo uma grande cagada commitada!

git reset --hard 56e05fced
git reset --soft HEAD@{1}
git commit -m "Revert to 56e05fced"

Merge de Remotes distintos

git remote add project-a path/or/url/to/project-a
git fetch project-a
git merge project-a/master # or whichever branch you want to merge
git remote remove project-a

Changing history

If it is the most recent commit, you can simply do this:

git commit --amend
This brings up the editor with the last commit message and lets you edit the message. (You can use -m if you want to wipe out the old message and use a new one.)

Pushing

And then when you push, do this:

git push --force-with-lease <repository> <branch>
Or you can use "+":

git push <repository> +<branch>
Or you can use --force:

git push --force <repository> <branch>
Be careful when using these commands.

If someone else pushed changes to the same branch, you probably want to avoid destroying those changes. The --force-with-lease option is the safest, because it will abort if there are any upstream changes (
If you don't specify the branch explicitly, Git will use the default push settings. If your default push setting is "matching", then you may destroy changes on several branches at the same time.
Pulling / fetching afterwards

Anyone who already pulled will now get an error message, and they will need to update (assuming they aren't making any changes themselves) by doing something like this:

git fetch origin
git reset --hard origin/master # Loses local commits
Be careful when using reset --hard. If you have changes to the branch, those changes will be destroyed.

A note about modifying history

The destroyed data is really just the old commit message, but --force doesn't know that, and will happily delete other data too. So think of --force as "I want to destroy data, and I know for sure what data is being destroyed." But when the destroyed data is committed, you can often recover old commits from the reflog—the data is actually orphaned instead of destroyed (although orphaned commits are periodically deleted).

If you don't think you're destroying data, then stay away from --force... bad things might happen.

This is why --force-with-lease is somewhat safer.