A dica Git desta semana é sobre como trabalhar com branches.

Branches

Até agora, só falei sobre o código que está em um único branch ou, em termos Git, o branch master. Isso é bom para começar, mas em breve você vai descobrir que deseja criar branches de desenvolvimento paralelo.

Primeiro, vale a pena mencionar brevemente como o Git lida com branches, porque é uma parte bastante fundamental de como o Git funciona. Cada repositório Git é uma árvore de commits, com o commit inicial sendo a raiz da árvore. Cada commit subsequente tem um ou mais pais; por isso, a partir de qualquer commit dado, você pode caminhar até a sua árvore-pai(s) para encontrar o commit inicial de um repositório.

Uma vez que cada um desses commits é representado como um hash, tipo 9ab532 … então qualquer ponto da árvore do repositório Git de commits pode ser identificado exclusivamente por este número por si só.

Como resultado, todos os mecanismos de referência em Git basicamente resumem-se a armazenar esse valor de hash em algum lugar. Para (local) branches, estes são armazenados nos arquivos refs/heads/*, você vai encontrar um arquivo master lá com um hash de 40 caracteres como seu conteúdo.

Trabalhando com branches

Para exibir uma lista de branches em Git, execute git branch. Isso mostra a lista de branches que estão atualmente em seu repositório. O asterisco mostra em qual branch você está a qualquer momento.

Para criar um novo branch fora do atual, você usa git branch name. Se você pretende baseá-lo em um commit diferente, você pode usar git branch hash name. Para mudar para um branch diferente, você usa o git checkout name. Aqui está como fica quando juntamos tudo:

$ git branch
* master
$ git branch new
$ git branch
* master
  new
$ git checkout new
$ git branch
  master
* new

Há um atalho para a criação e verificação de um branch, que é git checkout -b name [hash]; assim, no caso acima, poderíamos ter feito git checkout -b new:

$ git branch
* master
# Shorthand for: git checkout -b new master
$ git checkout -b new
$ git branch
  master
* new

Você verá que o que aconteceu foi que um arquivo foi criado, refs/heads/new, que contém o novo ponteiro para a árvore. Uma vez que criamos um a partir do outro, os dois têm o mesmo conteúdo. No entanto, se estávamos comitando uma mudança para o novo branch, então eles seriam diferentes. O branch master ficaria onde estava, enquanto o branch new estaria um commit à frente.

Se você fizer a verificação do branch master em vez disso, e criar um commit, então os branches começarão a divergir. Como alternativa, poderíamos trazer essa mudança de new para master, o que faremos com um merge na próxima vez.

?

Texto original disponível em http://alblue.bandlem.com/2011/04/git-tip-of-week-branches.html