Uma diferença básica que senti ao usar o git para controle de versão, se comparado com outros que usei antes, como cvs e subversion, é que ele mantém um repositório no local do desenvolvimento. Isso insere mais uma etapa no processo. Nas ferramentas de controle de versão, normalmente o commit é a etapa final que atualiza o repositório remoto. No git o commit atualiza o repositório local, onde você está desenvolvendo. Pra sincronizar com o repositório remoto é preciso fazer um push.

Nos comandos mostrados adotei a sintaxe comum dos manuais de *nix (man).

• Colchetes indicam uso opcional de um parâmetro
• Menor e maior que indicam algo que deve ser substituído por um valor real

• Cria um repositório local vazio ou reinicia o repositório:

git init

• Se ainda não tenho o repositório local para desenvolver:

git clone xxx://seu.site.git/usuario/repositorio

Esse link será fornecido no site.

• Se o repositório já foi clonado, entrar em qualquer subdiretório e executar:

git pull

• Para ver o status de um arquivo ou diretório estando em qualquer diretório do repositório:

git status [<nome>]

• Mostra histórico de alterações do ambiente ou de um arquivo:

git log [<nome>]

O fluxo mais comum de trabalho no dia-a-dia em um repositório já baixado vai ser:

• Atualizar o código (desnecessário se só você altera e sempre o faz desse local): git pull
• Alterar o que for necessário
• Indicar o que quer que seja atualizado (dentre o que foi alterado): git add <nome(s)>
• Atualizar o repositório local: git commit [-m “mensagem”] <nome(s)>|-a
• Atualizar o repositório remoto: git push

Além desse fluxo pode precisar também desses comandos:

• Adiciona um item para ser controlado ou atualizado:

git add <nome>

• Move ou renomeia um item (não se deve renomear com mv do SO):

git mv <nome>

• Remove um item (não se deve remover com o rm do SO):

git rm <nome>

Podem ser usados para experimentar, para guardar diferentes versões, para trabalho em equipe, para implementar nova funcionalidade e depois integrar com o curso principal, etc. Podem ser vistos como:

• pontuais:
  • implementar nova funcionalidade;
  • correção;
  • mudança de configuração…
• de vida longa:
  • master;
  • release;
  • develop…

Usos do comando branch:

Nota: o comando checkout apenas reaponta a referência HEAD e atualiza a árvore de trabalho de acordo com tal apontamento.

• Consultando os branches existentes (a opção -a mostrará também os branches remotos):

git branch [-a]

• Criando um branch (mas não te posicionando nele):

git branch <nome do branch>

• Apontando para o branch criado:

git checkout <nome do branch>

• Cria e já aponta para o branch criado:

git checkout -b <nome do branch>

• Removendo um branch:

git branch -d <nome do branch>

• Caso um commit tenha ficado órfão por deleção acidental do label do branch:
  • Listar história recente do HEAD: git reflog
  • Verificar se há um sha1 referente ao que se perdeu
  • Recriar o branch apontando para aquele commit órfão: git checkout -b <nome> <sha1>

• Mostra grafo histórico dos branches criados:

git log --oneline --graph

• Para push para o branch específico:

push -u origin <branch>

Obtendo um manual sobre o assunto:

  $ git help merge

Tipos:

• fast-forward
  • é o padrão
  • apenas move o label do ramo base para a ponta do ramo
• commit
  • próxima tentativa caso o fast-forward não seja possível
  • sempre terá múltiplos pais e pode gerar conflitos
• squash
• rebase

Realizando um merge tipo fast-forward:

• Reapontar o HEAD para master
• Realizar o merge propriamente dito
• Eliminar o ramo usado para a implementação (opcional)

# Uma conferida no status das coisas
$ git log --online --graph --all
$ git chechout master
$ git merge featureX
$ git branch -d featureX # opcional

Realizando um merge tipo commit

• Mesmos passos do fast-forward
• git vai detectar que o fast-forward não é possível
• git abrirá um editor para a mensagem de merge (pode aceitar a padrão ou editar)
• Manterá claramente o caminho do ramo no histórico
• Se quiser sempre fazer o tipo merge pode se usar a opção –no-ff

examine the history and state (see also: git help revisions)

 bisect     Use binary search to find the commit that introduced a bug
 grep       Print lines matching a pattern
 log        Show commit logs
 show       Show various types of objects
 status     Show the working tree status

grow, mark and tweak your common history

 branch     List, create, or delete branches
 checkout   Switch branches or restore working tree files
 commit     Record changes to the repository
 diff       Show changes between commits, commit and working tree, etc
 merge      Join two or more development histories together
 rebase     Reapply commits on top of another base tip
 tag        Create, list, delete or verify a tag object signed with GPG

collaborate (see also: git help workflows)

 fetch      Download objects and refs from another repository
 pull       Fetch from and integrate with another repository or a local branch
 push       Update remote refs along with associated objects

'git help -a' and 'git help -g' list available subcommands and some concept guides. See 'git help <command>' or 'git help <concept>' to read about a specific subcommand or concept.