Linux kernel newbies em português

Este documento é um pequeno guia introdutório para operações básicas usando o GIT. A maioria das características são apresentadas em comparação com sistemas de controle de versão não distribuídos populares como o CVS e o Subversion.

Características

Introdução

O GIT é um sistema de controle de versão distribuído. Não há um repositório central, e cada desenvolvedor tem repositórios "particulares" na própria máquina onde está trabalhando. Qualquer um que tenha acesso a um repositório pode criar uma cópia exatamente igual, com todas as informações que o repositório original continha. Todas as cópias de repositórios são equivalentes entre si em funcionalidade.

Para facilitar a compreensão de quem já conhece outros sistemas de controle de versão, farei várias comparações do GIT com sistemas convencionais como o CVS e o Subversion, no texto abaixo, me referindo a eles como "CVS/SVN".

Muitos repositórios

Ao contrário de CVS/SVN, no git não há diferença entre "repositório" e um "checkout" (chamado "working copy" no Subversion). Para obter o código de um repositório, você faz um clone de um repositório (uma cópia completa) na sua máquina.

"Commite" à vontade

No CVS/SVN, quando você fez checkout de um repositório remoto, o comando
"commit" pergunta a sua mensagem de log e envia as modificações para o servidor imediatamente. As ações de documentar e publicar suas modificações são inseparáveis.

No GIT, como você possui um repositório completo na sua máquina, você pode fazer commits à vontade no seu clone, e só publicar ou enviar essas informações para um servidor (se houver) quando quiser. Você pode fazer commits menores e mais frequentes, mesmo quando ainda está testando o seu código, pois você sabe que não vai estar commitando código não testado num repositório central.

Branches

Cada repositório GIT pode conter vários branches. Alguns são especialmente interessantes porque são criados por default e comumente utilizados.

master

Geralmente todo repositório tem um branch chamado "master", que
geralmente é o branch principal do repositório (semelhante ao "trunk"
no SVN e a HEAD no CVS).

O "master" é criado por default quando um repositório é criado (git-init-db), e também quando é feito um clone (git-clone). A não ser que você faça questão de trabalhar com vários branches, em geral você vai trabalhar sempre no branch master do seu repositório.

origin

Nota: o parágrafo abaixo não se aplica mais, nas versões mais recentes do git. É necessário revisá-lo.

O branch "origin" é criado automaticamente quando é feito um clone
de outro repositório. Ele é utilizado para manter uma cópia do
repositório "original" quando você tem um clone de um repositório e
quer baixar modificações novas do repositório de onde você fez clone.
Apesar do GIT não impedir você de fazê-lo, é uma má idéia fazer
commits no branch "origin". A sua função é manter uma cópia de um
repositório externo, e commits nesse repositório irão confundir o
git-fetch (a ferramenta que busca modificações novas do repositório
original).

Logo, para tornar o seu uso do GIT mais agradável, siga a seguinte regra: Nunca faça commits no branch origin.

HEAD

O HEAD não é um branch propriamente dito, mas é como um ponteiro
para o "branch atual". O "branch atual" é o branch onde você está
trabalhando no momento, onde seus commits serão colocados e é o
branch default para a maioria das operações.

Quando quiser trabalhar em outro branch, você pode trocar o branch
atual com o comando git-checkout.

Comandos básicos

Clonando um repositório

git-clone <repositorio>

Este comando irá criar um repositório que contém uma cópia do
repositório original. O clone criado vai conter os branches do
repositório original, mais um branch chamado "origin".

Criando um repositório local

git-init-db

Este comando irá criar um repositório vazio, ainda sem nenhum commit,
apenas com um branch chamado "master".

Commits e log

Commitando

Para commitar as suas modificações no branch atual (HEAD):

git-commit -a [-s]

Usar o parâmetro -s é opcional, mas recomendável. Ele adiciona
uma linha "Signed-off-by" na sua mensagem de commit.
O parâmetro -a serve para simplificar algumas coisas. Caso queira
entender melhor o porquê, procure por "index file" na documentação
do GIT.
Caso arquivos tenham sido criados ou removidos, utilize
os commandos git-add e git-rm para adicioná-los e removê-los,

antes do commit.

Jogando fora modificações não commitadas

git-checkout -f

Todas as modificações que não foram commitadas serão descartadas, e
os arquivos serão revertidos para a versão do branch atual (HEAD).

Vendo commits anteriores

Para ver o log de commits de um branch:

git-log [<branch>]

Caso omitido, o log do branch atual (HEAD) será mostrado.
Para ver o que mudou em cada commit:

git-whatchanged [-p]

Com o parâmetro -p, um "diff" das modificações é mostrado. Sem
o parâmetro, apenas os nomes dos arquivos adicionados modificados e
removidos são mostrados.

Entendendo o estado atual do repositório

Para entender melhor o que vai acontecer caso git-commit
seja executado, você pode observar a saída de:

git-status

Trabalhando com branches

Listando os branches

git-branch

O branch atual (HEAD) é marcado com um asterisco, na lista.

Trocando de branch

Para mover para outro branch, para observar o código em um branch,
modificar e commitar no branch:

git-checkout <branch>

Nota: se houver modificações não "commitadas" no branch atual,
o git-checkout pode falhar. Caso queira guardá-las, commite as
modificações no branch atual (git-commit), ou jogue fora as
modificações com o comando git-checkout -f.

Criando branches

Para criar um branch:

git-branch <branch> [<origem>]

O branch criado será uma cópia de origem. Caso não seja especificado,
vai ser uma cópia do branch atual (HEAD).

Para criar um branch, e ao mesmo tempo apontar o "branch atual" (HEAD)
para o branch criado.

git-checkout -b <newbranch> [<origem>]

O comando acima é equivalente a um git-branch seguido de git-checkout.

Veja também

• Site do GIT: http://git.or.cz

• Tutorial Introduction to GIT: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
• Tutorial part 2: http://www.kernel.org/pub/software/scm/git/docs/tutorial-2.html
• Every day GIT with 20 commands or so: http://www.kernel.org/pub/software/scm/git/docs/everyday.html
• Kernel Hacker's GIT tutorial: http://linux.yyz.us/git-howto.html