O que um Sistema de Controle de Verso?

Controle de Verso um sistema que grava as mudanas ocorridas nos arquivos com o passar do tempo para que voc possa recuperar verses anteriores especificas. No nosso caso, como desenvolvedores, iremos versionar nosso cdigo-fonte, embora voc possa faz-lo com qualquer tipo de arquivo.

Sistemas de Controle de Verso Local

Quem nunca versionou um projeto copiando para outro diretorio, colocando backup no nome ou bkp na extenso? Fazer isso muito simples, mas os riscos tambm so altos. Voc pode se confundir com as verses, esquecer para onde copiou o backup.. e a coisa complica a partir da. (Neste momento voc j est desesperado). Com o intuito de evitar esse problemas desenvolvedores criaram Sistemas de Controle de Verso Locais que possuem um banco de dados simples que mantm todas as alteraes feitas aos arquivos sobre controle do sistema.

Sistemas de Controle de Verso Centralizados

No entanto um problema maior estava por vir, a necessidade de colaborao entre os desenvolvedores nos projetos fez surgir Sistemas de Controle de Verso Centralizados. Um exemplo deste modelo de VCS (Version Control System) o Team Foundation Server - Source Control. Neste modelo um servidor contm todos os arquivos versionados e os clientes enviam e baixam arquivos deste repositrio centralizado. Entre as vantagens deste tipo de sistema a transparncia na realizao das atividades, pois todos sabem o que o outro est fazendo, administradores tem um maior controle sobre o que possvel fazer, como estabelecer politicas de check-in, alm da terica facilidade de administrao.

Sistemas de Controle de Verso Distribudos

Em DVCS (Distributed Version Control Systems) os clientes no fazem simplesmente um check-out dos arquivos. Na verdade ele espelha toda o repositrio. Desta forma se algum server cair, qualquer um dos clientes pode recupera-lo, copiando o repositrio novamente e restaurando-o. Entre exemplos deste sistema esto Mercurial, Git. Este tipo de sistema trabalha muito bem com repositrios remotos, deste modo voc pode colaborar com diferentes grupos de pessoas de diferentes maneiras simultaneamente no mesmo projeto. Permitindo atingir fluxos de trabalho que no so possvel em sistemas centralizados.

A Histria do Git (resumidamente)

O Kernel do Linux definitivamente um projeto opensource de larga escala. Na maior parte de seu ciclo de vida mudanas no software foram passadas adiante como patches ou arquivos. Em 2002 o projeto comeou a utilizar um DVCS proprietrio chamado BitKeeper. Em 2005 a relao entre a comunidade Linux e o empresa dona do BitKeeper desandou, quando a ferramenta deixou de ser free para esta comunidade. Isto fez com que a comunidade desenvolvesse sua prpria ferramenta baseada nos princpios e caractersticas do BitKeeper. Nasce o Git. Entre as caractersticas do projeto: Velocidade Design simples Suporte forte para desenvolvimento no linear Totalmente distribudo Habilidade para lidar com grande volume de maneira eficiente.

Sua Identidade
Ao instalar o Git a primeira coisa a se fazer configurar a sua identidade no Git. Isso importante porque por exemplo, todo Commit que voc realizar utilizaro destas informaes. Rode os seguinte comandos no Bash
git config --global user.name "Rodrigo Vidal" git config --global user.email rodrigovidal777@gmail.com

Aps ter configurado sua identidade, voc pode verificar suas configuraes globais com o comando
git config --list

Conectando o Git ao Github

O Github na verdade uma rede social para desenvolvedores, onde possivel contribuir para projetos opensource, acompanhar seu desenvolvimento e criar novos. Para que essa conexo entre o Git e o Github seja possivel voc precisar criar uma chave local e inform-la ao Github.
mkdir .ssh cd ~/.ssh ssh-keygen -t rsa -C email@provedor.com

Logo aparecer a seguinte mensagem: "Enter file in which to save the key (/c/Users/Me/.ssh/id_rsa)" Pressione Enter. Em seguida ser solicitado a criao de uma senha. Agora abra o arquivo id_rsa.pub gerado (Ex.: C:/Users/rodrigovidal/.ssh) com um editor de texto e copie todo o seu conteudo. V ao GitHub -> Account Settings -> SSH Public Keys. Clique em "Add another public key". D um nome para a chav pblica que voc criou . Cole o contedo do arquivo id_rsa.pub que voc copiou no passo anterior no campo key. Agora basta salvar. Para testar a sua conexo com o GitHub digite no Bash:
ssh git@github.com

Se tudo deu certo voc receber uma mensagem dizendo que voc foi autenticado com sucesso!

Criando um Repositrio no Git

Existem duas maneiras bsicas para se criar um repositrio no Git. Atravs da criao de um repositrio para um projeto novo ou existente, ou clonando um repositrio. Para comear a fazer o versionamento ou "track" de um projeto no Git, voc precisa entrar no diretrio do projeto e executar o comando:
$ git init

Este comando cria um subdiretrio escondido chamado ".git" que contm todos os arquivos necessrios para o repositrio, ou seja, ele cria um esqueleto do seu repositrio Git. Neste momento nada do seu projeto se encontra controlado, ou versionado, ou ainda com o status "tracked". Como exemplo, vamos criar um projeto no Visual Studio na pasta de sua escolha. No Git Bash, entre nesta pasta e digite o comando "git init" como listado acima.

Pronto nosso repositrio foi criado. Agora vamos comear a versionar o nosso projeto e fazer o primeiro Commit.
$ git add . $ git commit -m "Primeiro Commit"

O comando "git add . " faz o track de todos os arquivos de todas as pastas recursivamente. O parmetro m do comando commit permite que voc digite uma mensagem para identificar o que foi feito neste commit. Toda vez que o projeto atinge um estado que voc deseje salvar, voc utiliza o comando commit.

O ciclo de vida dos arquivos

Cada arquivo no seu diretrio pode possuir um de dois status: Tracked ou Untracked. O status Tracked informa que os arquivos estavam no ltimo snapshot. Eles podem ter 3 sub-status: unmodified, modified ou staged. O status Untracked marcam os arquivos que esto no seu diretrio mas no estavam no ltimo snapshot e no esto em staging.

Verificando o Status dos Arquivos

Uma maneira simples para ver os status dos arquivos para poder manipula-los com facilidade utilizar o comando:
$ git status

Neste momento como adicionamos todos os arquivos rea de staging e realizamos o commit, no h mais nada para commitar, em outras palavras, no h arquivos em status "tracked" ou "modified". Tambm no h arquivos "untracked", caso contrrio ele seriam listado como veremos no exemplo a seguir.

O status tambm te informa que voc se encontra no Branch Master, que o padro. Por enquanto no se preocupe com isso. Veremos o significado disso mais adiante. Vamos adicionar um arquivo ao nosso projeto e ver o que acontece. Adicionarei um arquivo chamado Class1.cs e executarei novamente o comando git status.

Pode-se notar que a classe que criamos (no arquivo Class1.cs) se encontra "untracked". Ou seja, o Git j reconheceu o arquivo e verificou que ele no se encontra no ultimo snapshot(commit). Para inclui-la, voc deve fazer explicitamente como veremos a seguir.

Fazendo "Tracking" de novos arquivos

Para realizar o Tracking do arquivo Class1.cs iremos executar o comando:
$ git add GitBlog/Class1.cs // (temos que informar GitBlog, pois na solution h um pasta GitBlog dentro de GitBlog)

Vemo o resultado a seguir:

Dessa forma j podemos dizer que o arquivo Class1.cs se encontra na rea de Staging, uma vez que ele est sobre o cabealho "Changes to be Committed". Caso execute o comando '"git commit" agora a verso do arquivo que ir para a snapshot ser a que se encontra na rea de Staging. No entanto, ao invs de commitar o arquivo deste modo, vamos complicar um pouco as coisas.

Fazendo "Staging" de arquivo modificados

E se eu modificar o contedo desta classe no meu editor de cdigo? Vamos ver o que acontece.

Uau! Nosso arquivo agora se encontra sob dois cabealhos, tanto em "Changes to be commited" quando em "Changed but not updated". Bom explicando o que podemos fazer. Caso eu realize um commit neste momento a verso do arquivo que ser feita a snapshot ser antes da modificao que eu realizei, ou seja, no ser a verso que se encontra presente no meu diretrio corrente. Para commitar a nova verso eu tenho que executar novamente o comando "git add" ( que um comando multi-proposito como se pode perceber) e ento executar o comando "git commit".

Removendo arquivos
Para remover um arquivo do Git voc deve remov-lo da sua rea de staging e ento commitar. O comando "git rm" faz isso e ainda remove o arquivo do seu diretrio, ento o arquivo no aparecer com o status Untracked.
$ git rm GitBlog/Class1.cs

Vamos supor que voc tenha feito commit de todos os seus arquivos. Logo seu diretrio est clean, como diria o Git. Voc no entanto faz uma modificao no arquivo Class1.cs e agora ele est com o status Untracked. Voc adiciona ele na rea de Staging com o comando:
$ git add Class1.cs

Agora Class1.cs possui o status Tracked. No entanto voc apenas deseja remov-lo da rea de staging, levando-o do status Tracked para Untracked. Para isso execute o comando:
$ git rm --cached Class1.cs

Abaixo, o que aconteceu:

Para isso o arquivo s ser removido da rea de staging aps o prximo commit. Isso pode ser um problema. Ento vejamos uma outra soluo.

Fazendo "Unstaging" de um arquivo "Staged"

Seguindo o modelo anterior voc realizou um "git add" no arquivo Class1.cs e agora ele se encontra staged. E voc deseja simplesmente fazer o "Unstaging" do arquivo deixando-o com o status Untracked. Para isso execute o seguinte comando:
$ git reset HEAD Class1.cs Desta forma como podemos ver a seguir o arquivo passou ao status Untracked.

Bom pessoal, vimos diversos comandos bsicos do Git neste artigo o que nos dar base para trabalhar com nosso controle de verso distribudo. Gostaria de reforar que os comandos a seguir funcionam no seu repositrio local e no no repositrio remoto, logo no h conexo com o Github ou outro repositrio remoto.