====== Controle de versão com git ======

===== Introdução =====

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

===== Preparando o ambiente =====

  * Cria um repositório local vazio ou reinicia o repositório:
    <code>git init</code>

  * Se ainda não tenho o repositório local para desenvolver:
    <code>git clone xxx://seu.site.git/usuario/repositorio</code> Esse link será fornecido no site.

  * Se o repositório já foi clonado, entrar em qualquer subdiretório e executar:
    <code>git pull</code>

===== Verificando o ambiente =====

  * Para ver o status de um arquivo ou diretório estando em qualquer diretório do repositório:
    <code>git status [<nome>]</code>

  * Mostra histórico de alterações do ambiente ou de um arquivo:
    <code>git log [<nome>]</code>

===== Trabalhando numa mudança cotidiana =====

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:
    <code>git add <nome></code>

  * Move ou renomeia um item (não se deve renomear com mv do SO):
    <code>git mv <nome></code>

  * Remove um item (não se deve remover com o rm do SO):
    <code>git rm <nome></code>


===== Branches =====

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):
    <code>git branch [-a]</code>

  * Criando um //branch// (mas não te posicionando nele):
    <code>git branch <nome do branch></code>

  * Apontando para o //branch// criado:
    <code>git checkout <nome do branch></code>

  * Cria e já aponta para o //branch// criado:
    <code>git checkout -b <nome do branch></code>

  * Removendo um //branch//:
    <code>git branch -d <nome do branch></code>

  * 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:
    <code>git log --oneline --graph</code>

  * Para ''push'' para o //branch// específico:
    <code>push -u origin <branch></code>
===== Merging =====

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''
===== Rascunho =====

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.