No dia 06/04/2015 o Git completou 10 anos (Dois dias apos eu ter lançado o artigo "A ameaça eminente do software proprietário" e também dois dias depois do meu aniversário).
Vamos então ao básico do Git e Github que inclusive fará parte do meu próximo vídeo.

O sistema de controle de revisão distribuído é um doce passo a frente do Subversion, CVS, Mercurial, e de todos esse outros temos testado. Ele é ótimo para desenvolvimento distribuído, quando se tem múltiplos contribuintes trabalhando no mesmo projeto, e é excelente para testes seguros de todos os tipos de mudanças loucas. Vamos utilizar uma conta livre no Github para a pratica assim podemos saltar diretamente e começar a fazer as coisas.

Conceitualmente Git é diferente de outros sistemas de controle de revisão (revision control systems). RCS antigos rastreavam as alterações nos arquivos, que você pode ver quando você cutuca por aí em seus arquivos de configuração. A aproximação do Git é mais parecido com filesystem snapshots, onde cada commit ou estado salvo é um snapshot completo ao invés de um arquivo cheio de diffs. Git é space-efficient por ele armazena somente as alterações em cada snapshot, e linka aos arquivos inalterados. Todas as alterações são feitas a base de checksum, então você é assegurado da integridade do dado, e sempre sendo capaz de reverter alterações.

Git é muito rápido, por que seu trabalho é todo feito no seu PC local e depois empurrado para um repositório remoto. Isso torna tudo o que você faz totalmente seguro, por que nada afeta o repo remoto até que você empurra as alterações para ele. E mesmo depois você tem mais um failsafe: branches. O branching system do Git é brilhante. Ele Cria um branch a partir do seu master branch, desempenha todos os meios de experiencias terríveis, e depois realiza nuke ou realiza push upstream. Quando realiza upstream outros contribuidores podem trabalhar nele, ou você pode gerar um pull request para tê-lo revisado, e então depois ele passa a inspeção para emergi-lo no master branch.

Então e se, depois de todo esse cuidado, ele ainda explodir o master branch? Sem preocupações, por que você pode reverter seu merge.

Pratique no Github

O jeito mais rápido de por o Git na prática é abrindo uma conta livre no Github. A figura número 1 mostra o meu playground Github testado e nomeado. As novas contas Github vem com um repo prefab povoado por um arquivo README, licença, e botões para rapidamente gerar bug reports, pull requests, Wikis, e outros recursos úteis.

Contas livres no Github somente permitem repositórios públicos. Isso permite que qualquer um visualize e baixe seus arquivos. No entanto, ninguém pode realizar commits ao menos que eles tenham uma conta no Github e você tenha os aprovado como colaboradores. Se você quiser um repo privado escondido do mundo, você precisa de uma paid membership. Sete pratas por mês lhe oferece cinco repos privados, e repos públicos ilimitados como contribuidores ilimitados.

Github fornece muito bem URLs copy-and-paste para clonagem de repositórios. Então você gerar um diretório no seu computador para seu repositório, e depois clonar dentro dele:

$ mkdir git-repos
$ cd git-repos
$ git clone https://github.com/AlracWebmaven/playground.git
Cloning into 'playground'...
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
Checking connectivity... done.
$ ls playground/
LICENSE README.md

Todos os arquivos são copiados para o seu computador, e você pode ler, editar, e excluí-los bem como qualquer outro arquivo. Vamos melhorar o README.md e aprender a maravilha do Git branching.

Branching

Git branches são gloriosamente excelentes para realizar e testar alterações com segurança. Você pode gerar e destruí-los todos que você quiser. Vamos gerar um README.md para edição:

$ cd playground
$ git checkout -b test
Switched to a new branch 'test'

Execute

git
status

para visualizar aonde você está:

$ git status

On branch test
nothing to commit, working directory clean

Quais branches você tem gerado?

$ git branch
* test
master

O asterisco indica em qual branch você está.

Master

é o seu main branch, aquele que você nunca quer realizar quaisquer alterações até que ele tenham sido testado em um branch. Agora realize algumas alterações no README.md, e depois verifique seu status novamente:

$ git status
On branch test
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")

Isso não é legal? Git lhe diz o que está acontecendo, e lhe dá dicas. Para descartar sua alterações, execute

$ git checkout README.md

Ou você pode excluir todo o branch:

$ git checkout master
$ git branch -D test

Ou você pode mandá-lo rastrear o arquivo:

$ git add README.md
$ git status
On branch test
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: README.md

Nesse estágio Git está rastreando o README.md, e está disponível para todos os seus branches. O Git lhe oferece uma dica útil – Se mudar de ideia e não quiser que o Git rastreie esse arquivo, execute

git
reset

HEAD
README.md

. Esse, e toda atividade do Git, é rastreado no diretório

.git
no seu repositório

. Tudo está em arquivo no formato de texto simples: arquivos, checksums, qual usuário fez o que, repos remotos e locais -- tudo.

E se você possuir múltiplos arquivos para adicionar? Você pode lista cada um deles, por exemplo

git
add file1 file2 file2

, ou adicionar todos os arquivos com o

git
add *

Quando há arquivos excluídos, você pode utilizar

git
rm nomeDoArquivo

, que somente os desordena do Git e não os exclui do seu sistema. Se você possuir um monte de arquivos excluídos, utilize

git
add -u

Committing Files

Agora vamos alocar (commit) nosso arquivo alterado. Isso o adiciona ao nosso branch e não fica mais disponível para os outros branches:

$ git commit README.md
[test 5badf67] changes to readme
1 file changed, 1 insertion(+)

Será lhe pedido para fornecer uma mensagem commit . É uma boa prática gerar as suas mensagens commit detalhadas e especificar, mas por enquanto não vamos ser exigentes demais. Agora o seu arquivo editado tem sido alocado para o branch test. Ele não tem sido fundido ao master ou realizado push upstream; ele vai somente reuní-lo lá. Esse é um bom ponto de parada se você precisar ir fazer outra coisa.

E se você tiver múltiplos arquivos para alocar alocar? Você pode alocar arquivos específicos, ou todos os arquivos disponíveis:

$ git commit file1 file2
$ git commit -a

Como você sabe quais commits ainda não tem sido realizado pushe upstream, mas ainda não reunidos em branches? O

git
status


não lhe dirá

, então utilize esse comando:

$ git log --branches --not --remotes
commit 5badf677c55d0c53ca13d9753344a2a71de03199
Author: Carla Schroder
Date: Thu Nov 20 10:19:38 2014 -0800
changes to readme

Isso lista commits não fundidos, e quando ele não retorna nada, então todos os commits tem sido realizado pushe upstream. Agora vamos push esse commit upstream:

$ git push origin test
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 324 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/AlracWebmaven/playground.git
* [new branch] test -> test

Suas credenciais de login Github podem ser solicitadas. O Git gera cache delas por 15 minutos, e você pode alterar isso. Esse exemplo define o cache em duas horas:

$ git config --global credential.helper 'cache --timeout=7200'

Agora vá ao Github e olhe seu novo branch. Github lista todos os seus branches, e você pode pré-visualizar seus arquivos nos diferentes branches (2ª imagem).

2ª imagem: Seu novo commit e branch no Github.

Agora você pode criar uma pull request ao clicar o botão Compare & Pull Request. Isso lhe dá uma nova chance de revisar suas alterações antes de fundir (merge) com o master. Você pode também gerar pull requests a partir da linha de comando no seu computador, mas esse é um processo trabalhoso, ao ponto que você pode todos os tipos de ferramentas por facilitar o processo por toda a Web. Então, por enquanto, utilizaremos os bons e rápidos botões do Github buttons.

Github lhe deixa visualizar seus arquvos em texto simples, e também possui suporte a linguagens de marcação (markup languages), então você cpnsegue visualizar uma pré-visualização gerada. Nesse ponto você pode push mais alterações no mesmo branch. Você consegue também realizar edições diretamente no Github, mas quando você faz isso, você obterá conflitos entre a versão online e sua versão local. Quando você estiver satisfeito com as suas alterações, clique no botão Merge pull request. Você terá que clicar duas vezes. Github automaticamente examina sua pull request para verificar se ele pode ser fundido limpamente, e se houver conflitos, você terá que concertá-los.

Um outro recurso legal no Github é quando você possui múltiplos branches, você pode escolher qual fundir ao clicar o botão Edit à direita das lista de branches (3ª imagem):

3ª imagem: Escolhendo quais branches emergir ou fundir.

Depois de você ter fundido, clique no botão Delete Branch para manter tudo organizado. Depois em seu computador local, exclua o branch ao enviar primeiro as alterações ao master, e depois você pode excluir seu branch sem que o Git reclame:

$ git checkout master
$ git pull origin master
$ git branch -d test

Você pode excluir um branch de forma bruta (force-delete) com um uppercase -D:

$ git branch -D test

Revertendo Alterações

Novamente, o Github método pointy-clicky é o mais prático. Ele lhe exibe uma lista de todas as alterações, e você pode reverte qualquer uma delas ao clicar o botão apropriado. Você poode até mesmo restaurar branches excluídos.

Você pode também fazer todas essas tarefas exclusivamente a partir da sua linha de comando, que é um ótimo tópico para outro dia por que ele é complexo. Para um tutorial exaustivo sobre o Git. Teste o Git book gratuito.