Hoje eu vim falar sobre o fabric. O fabric é um cara que te ajuda a automatizar o deploy permitindo que você execute comandos de shell na máquina local e (o que é mais legal) em um servidor remoto de maneira muito simples.

Como assim?

Imagine que você tem seu programa lá, bonitão, works on my machine certified, mas você precisa por isso em algum lugar acessível ao público. Você pode muito bem gerar um .tar do seu código, copiar pro servidor, instalar… enfim, fazer tudo o que precisa na mão. Nem é complicado. Mas fazer isso é chato, e se a coisa cresce, tem sempre o risco de esquecer algo. É aí que entra o fabric! Com ele, você escreve um script (em Python) pra fazer o seu deploy.

Tá, beleza. Mas como funciona?

É bem simples. A primeira coisa a se fazer é instalar o fabric e a maneira mais fácil de fazer isso é pelo gerenciador de pacotes do seu sistema operacional (seu s.o. tem gerenciador de pacotes, não?). Depois de instalado o fabric, é só você criar um arquivo chamado fabfile.py contendo os comandos necessários ao deploy.

Pra começar, vamos fazer um ‘olá’ com o fabric pra gente ver como funciona. O fabfile pro nosso ‘ola’ ficou assim:

#-*- coding: utf-8 -*-

# Arquivo fabfile.py

def ola(nome):
    print 'olá, ', nome

A sintaxe pra se executar o fabfile é a seguinte: fab <nome_da_funcao>:<arg1>, <arg2>, …

Então, pra executar nosso fabfile acima, executamos o seguinte comando:

$ fab ola:juca
ola,  juca

Done.

Tá, entendi. Agora um exemplo decente, vai.

Agora que já vimos como usar o fabric, vamos a um exemplo real, pra gente dar uma olhada em algumas coisas interessantes da api do fabric.

A idéia aqui vai ser a seguinte: Eu tenho um repositório git na minha máquina contendo o código que eu quero subir. O procedimento pra subir é gerar um .tar contendo o código de uma named tree qualquer (um branch, uma tag, um commit…), copiar esse tar pro servidor remoto, desempacotar o tar no servidor remoto, se já tiver uma versão mais antiga instalada, desinstalar essa versão antiga, instalar a versão nova e por fim, reiniciar o web server.

Tudo muito simples, mas ficar fazendo isso é muito chato, então o fabfile abaixo resolve isso pra gente:

import os
import time
# aqui importando uns caras legais da api do fabric
# local - roda um comando de shell na máquina local
# run - roda um comando de shell no servidor remoto
# put - faz uma cópia via ssh (scp) pro servidor remoto
# env - configurações do ambiente
from fabric.api import local, run, put, env

LOCAL_SRC_PATH = '/home/juca/mysrc/sourcecode2html'
LOCAL_BUILD_PATH = '/tmp/amazon-build'
REMOTE_SRC_PATH = '/home/deployuser/src/codeprettifier'

# aqui é uma string do tipo usuario@host[:porta]
# usuario é um usuário do sistema no servidor remoto.
# É uma string como o que você passa pro ssh 
env.hosts = ['deployuser@myserver']

# É essa função que vai ser chamada na execução do fabfile, algo como:
# fab deploy:master
def deploy(tree_name):
    """ Executa as ações necessárias ao deploy
    """

    tar_file = _package_named_tree(tree_name)
    remote_tar_path, filename = _send_file(tar_file)
    _unpack_code(remote_tar_path, filename)
    _uninstall_last_version()
    _create_link_to_lastest(remote_tar_path)
    _build()
    _install()
    _restart_server()

def _package_named_tree(tree_name):
    """ cria um arquivo .tar.bz2 baseado numa named tree do git
    """

    try:
        os.mkdir(LOCAL_BUILD_PATH)
    except OSError:
        pass

    os.chdir(LOCAL_SRC_PATH)
    filename = '%s/codeprettifier-%s.tar.bz2' %(LOCAL_BUILD_PATH,
                                                tree_name)
    pack_command = 'git archive %s --prefix=codeprettifier/ |' % tree_name
    pack_command += ' bzip2 > %s' % filename

    # aqui, executando o comando na máquina local
    # com o local() da api do fabric
    local(pack_command)

    return filename

def _send_file(filename):
    """ send file to remote server
    """
    remote_tar_path = REMOTE_SRC_PATH + '/%s/' % int(time.time())
    try:
        # Aqui executando run(). O mkdir aí em baixo vai ser 
        # executado no servidor remoto. 
        # Assim que o primeiro run() é chamado, vai ser perguntada
        # a senha do usuário no host remoto.
        run('mkdir -p %s' % remote_tar_path)
    except:
        pass

    # aqui enviando arquivo via scp usando o put()
    # da api do fabric
    put(filename, remote_tar_path)
    filename = filename.split('/')[-1]
    return remote_tar_path, filename

def _unpack_code(remote_tar_path, filename):
    """ Desempacota o código no servidor remoto
    """

    run('cd %s' % remote_tar_path)
    run('tar -xjvf %s/%s -C %s' % (remote_tar_path, filename, remote_tar_path))

def _uninstall_last_version():
    """ unpacks the code on remote server
    """

    try:
        run('cd %s/latest/codeprettifier' % REMOTE_SRC_PATH)
    except:
        return

    uninstall_command = 'cd %s/latest/codeprettifier && ' % REMOTE_SRC_PATH
    uninstall_command += "sudo make uninstall | grep -v codeprettifier/ |"
    uninstall_command += 'grep -v Java/ | grep -v MultiLineStringDelimiter.pm |'
    uninstall_command += "cut -d'k' -f2 | grep -i CodePrettifier |"
    uninstall_command += " grep -v codeprettifier.pl |xargs sudo rm"
    try:
        run(uninstall_command)
    except:
        pass
    run('rm %s/latest' % REMOTE_SRC_PATH)

def _create_link_to_lastest(remote_tar_path):
    run('ln -s %s %s/latest' % (remote_tar_path, REMOTE_SRC_PATH))

def _build():
    """ Cria o Makefile pra instalação
    """
    remote_latest_dir = REMOTE_SRC_PATH + '/latest/codeprettifier'
    run('cd %s && perl Makefile.PL' % remote_latest_dir)

def _install():
    """ Faz a instalação em si
    """
    remote_latest_dir = REMOTE_SRC_PATH + '/latest/codeprettifier'
    run('cd %s && sudo make install' % remote_latest_dir)

def _restart_server():
    """ reinicia o server
    """
    run('sudo /sbin/service httpd restart')

Agora, é só executar

$ fab deploy:master
[deployuser@myserver] Executing task 'deploy'
[localhost] local: git archive master --prefix=codeprettifier/ | bzip2 > /tmp/amazon-build/codeprettifier-master.tar.bz2
[deployuser@myserver] run: mkdir -p /home/deployer/src/codeprettifier/1326011668/
[deployuser@myserver] Login password:
[deployuser@myserver] put: /tmp/amazon-build/codeprettifier-master.tar.bz2 -> /home/deployer/src/codeprettifier/1326011668/codeprettifier-master.tar.bz2
[deployuser@myserver] run: cd /home/deployuser/src/codeprettifier/1326011668/
[deployuser@myserver] run: tar -xjvf /home/deployuser/src/codeprettifier/1326011668//codeprettifier-master.tar.bz2 -C /home/deployuser/src/codeprettifier/1326011668/

...

[deployuser@myserver] run: cd /home/deployuser/src/codeprettifier/latest/codeprettifier && sudo make uninstall | grep -v codeprettifier/ |grep -v Java/ | grep -v MultiLineStringDelimiter.pm |cut -d'k' -f2 | grep -i CodePrettifier | grep -v codeprettifier.pl |xargs sudo rm
[deployuser@myserver] run: rm /home/deployuser/src/codeprettifier/latest
[deployuser@myserver] run: ln -s /home/deployuser/src/codeprettifier/1326011668/ /home/deployuser/src/codeprettifier/latest
[deployuser@myserver] run: cd /home/deployuser/src/codeprettifier/latest/codeprettifier && perl Makefile.PL

...

[deployuser@myserver] run: cd /home/deployuser/src/codeprettifier/latest/codeprettifier && sudo make install

...

[deployuser@myserver] run: sudo /sbin/service httpd restart

...

Done.
Disconnecting from deployuser@myserver... done.

E pronto, seu deploy foi feito automaticamente!

Pra finalizar, quero dizer que isso foi só um exemplo, você pode escrever o procedimento de deploy que quiser com o fabric. Ele é bem versátil!

Bom, é isso pessoal. Até a próxima! :)

O melhor é usar o gitorious, e você ainda pode baixar o código e ter a sua própria instalação.

Simples assim.

Depois de um bom tempo sem postar nada, vou aproveitar minha semaninha de folga pra tirar as teias do porão e vamos falar um pouquinho sobre orientação a objetos no Perl.

Mas o Perl é um cara sem classe, não?

No Perl realmente não existe uma palavra mágica class ou algo do tipo, mas a gente pode criar classes sim!

As classes no Perl são criadas o mecanismo de package que também é usado mais usualmente para criar módulos tradicionais. E os objetos… bom, os objetos são referências abençoadas ! :P

Referência abençoada? Que diabo é isso?

Calma… nada de misticismos. Uma referência abençoada é só uma referência que foi passada como argumento para a função bless. É essa função a responsável por dizer: ‘essa referência pertence a este package (classe)’. Depois de abençoada, você será capaz de chamar funções através dessa referência, ou, em outras palavras, você terá métodos!

Entendi, mas já cansei de papo…

Beleza, já falei bastente, e agora é hora do código.

Pra este exemplo vou criar uma classe (package) Pessoa (como um módulo normal do Perl, isso será gravado em um arquivo chamado Pessoa.pm), e nessa classe criarei o contrutor da classe e os seus outros métodos. Agora sim, o código:

1package Pessoa; # Arquivo Pessoa.pm
2
3use strict;
4use warnings;
5
6# Aqui é o contrutor da classe.
7# O nome 'new' não é uma obrigação, só
8# uma convenção de uso.
9sub new{
10    # classe onde o a referência será abençoada.
11    # Isso aqui não precisa ser passado como parâmetro
12    # na hora de instanciar o objeto, é passado implicitamente
13    my $class = shift;
14
15    # Nossa referência que será abençoada.
16    # Pode ser uma referência qualquer, não necessáriamente
17    # uma referência a um hash;
18    my $self = {};
19    $self->{NOME} = undef;
20    $self->{IDADE} = undef;
21
22    # Agora a mágica acontece
23    bless($self, $class);
24
25    return $self;
26}
27
28
29# Métodos pra proteger o acesso aos nossos atributos
30sub nome{
31    # Como $class no contrutor, $self aqui também é parâmetro implícito
32    my $self = shift;
33    $self->{NOME} = shift if @_;
34    return $self->{NOME};
35}
36
37sub idade{
38    my $self = shift;
39    $self->{IDADE} = shift if @_;
40    return $self->{IDADE};
41}
42
43# Outro metodozinho só de exemplo
44sub fale{
45    my $self = shift;
46    my $fala = shift || "Qualquer coisa";
47    return $fala
48}
49
50# Precisa retornar um valor verdadeiro
511;

Agora, vamos criar uma subclasse de Pessoa

1package PessoaMuda; # Arquivo PessoaMuda.pm
2
3# Importando a super classe
4use Pessoa;
5
6# Aqui estamos dizendo que PessoaMuda é uma Pessoa
7@ISA = (Pessoa);
8
9# Sobrescrevendo o método fale pra que retorne nada...
10sub fale{
11    my $self = shift;
12    return
13}
14
151;

E, por fim, vamos usar nossos objetos

1#!/usr/bin/env perl
2
3use strict;
4use warnings;
5
6# Importando nossas classes
7use Pessoa;
8use PessoaMuda;
9
10# Nova instância de Pessoa;
11my $p = Pessoa->new();
12$p->nome('Alguém');
13print $p->nome();
14
15$p->idade(10000);
16print $p->idade();
17
18print $p->fale('Eu nasci a 10000 anos atrás...') . "\n";
19
20# Uma pessoa muda
21my $pm = PessoaMuda->new();
22$pm->nome('Ninguém');
23print $pm->nome();
24
25$pm->idade(10000);
26print $pm->idade();
27
28# Mudos não falam, lembra? Sobrescrevemos o método...
29print $pm->fale('Alguma coisa');

Bom, é isso! Pra mais sobre orientação a objetos no Perl, leiam o perltoot.

Valeu, e até a próxima!

Hoje eu estou aqui pra mostrar como se usa o (básico do) Python Debugger, o pdb, que é (óbvio) um depurador pra se usar com o Python.
Este exemplo é feito usando o Python 3.

Bom, existe mais de uma maneira de usar o pdb. A que vou mostrar é chamando o pdb como um script para depurar outro script.

Então, primeiro, vamos criar um scriptosco com um erro mais tosco ainda pra gente começar a brincar com o pdb. O scriptosco é o seguinte:

#-*- coding: utf-8 -*-

def divide(a, b):
    erro = False
    try:
        return float(a) / float(b)
    except:
        erro = True

    if erro:
        raise Exception("Não vou te dizer qual é o erro...")

a = 1
b = 2
divide(a, b)
a = 3
b = 0
divide(a, b)

Bom, rodando isso aí, a gente tem o seguinte:

$ $python3 exemplopdb.py
Traceback (most recent call last):
  File "exemplopdb.py", line 18, in
    divide(a, b)
  File "exemplopdb.py", line 11, in divide
    raise Exception("Não vou te dizer qual é o erro...")
Exception: Não vou te dizer qual é o erro...

Agora que temos um erro, podemos usar o pdb pra achar cara. A gente vai fingir que não vê nada errado até a hora certa, tá? :P
A sintexe pra se chamar o pdb é a seguinte:
python -m pdb <meu_script>
Então, ao chamar nosso doente junto com o pdb, a gente vai cair no shell do pdb. Assim:

$ python3 -m pdb exemplopdb.py
--Return--
> /media/5511fc83-ad85-484b-9b0e-0948abcb6026_/virtualpython/lib/python3.1/encodings/__init__.py(67)normalize_encoding()->'utf_32_be'
-> return ''.join(chars)
(Pdb)

Nós começaremos criando breakpoints nas linhas 11 e 18. Fazemos isto com o comando b[reak]. Depois, utilizando o comando c[ontinue], continuaremos a execução do programa até que algum breakpoint seja encontrado. E por fim, usaremos o comando list para listar um trecho de código e ver onde paramos.

(Pdb) break exemplopdb.py:11
Breakpoint 1 at /media/sda6/Projetos & afins/scripts/exemplopdb.py:11
(Pdb) b exemplopdb.py:18
Breakpoint 2 at /media/sda6/Projetos & afins/scripts/exemplopdb.py:18
(Pdb) c
> /media/sda6/Projetos & afins/scripts/exemplopdb.py(18)()
-> divide(a, b)
(Pdb) list
 13  	a = 1
 14  	b = 2
 15  	divide(a, b)
 16  	a = 3
 17  	b = 0
 18 B->	divide(a, b)
 19
[EOF]
(Pdb)

Nosso primeiro breakpoint é bem na chamada da função, então vamos “entrar na função” e acompanhar a execução. A gente faz isso com o comando s[tep]. Uma vez na função, a gente pode acompanhar a execução linha-por-linha usando o comando n[ext] e também pode imprimir os valores das variáveis com print.

(Pdb) s
--Call--
> /media/sda6/Projetos & afins/scripts/exemplopdb.py(3)divide()
-> def divide(a, b):
(Pdb) list
  1  	#-*- coding: utf-8 -*-
  2
  3  ->	def divide(a, b):
  4  	    erro = False
  5  	    try:
  6  	        return float(a) / float(b)
  7  	    except:
  8  	        erro = True
  9
 10  	    if erro:
 11 B	        raise Exception("Não vou te dizer qual é o erro...")
(Pdb) n
> /media/sda6/Projetos & afins/scripts/exemplopdb.py(4)divide()
-> erro = False
(Pdb) n
> /media/sda6/Projetos & afins/scripts/exemplopdb.py(5)divide()
-> try:
(Pdb) n
> /media/sda6/Projetos & afins/scripts/exemplopdb.py(6)divide()
-> return float(a) / float(b)
(Pdb) print(a, b)
(3, 0)
(Pdb) n
ZeroDivisionError: 'float division'
> /media/sda6/Projetos & afins/scripts/exemplopdb.py(6)divide()
-> return float(a) / float(b)
(Pdb)

Bom, aí matamos o erro, não? Funciona mesmo!

Moral da história: As vezes o pdb pode salvar várias horas do seu dia. Faça dele um amigo. :)

Esse programinha aí, o localepurge, é um cara que apaga as traduções de programas e manuais que estão nos idiomas que você não usa. Dependendo do tanto de coisa que você tem instalado, vai ter bastante espaço liberado. Isso me libera pra mais de 500 MiB.

Pra instalar no Debian, como sempre, é simples.

E depois:

É isso.

O que acontece é que no arquivo /etc/sysctl.d/bindv6only.conf a variável net.ipv6.bindv6only estava marcada como 1, e essa é a fonte do problema. Esta variável tem que estar marcada como 0. Pra arrumar isso, use:

# sed -i ‘s/net.ipv6.bindv6only\ =\ 1/net.ipv6.bindv6only\ =\ 0/’ /etc/sysctl.d/bindv6only.conf
# invoke-rc.d procps restart

É isso aí.

Antes de mais nada, a fonte primária de informação é essa aqui.
Isto aqui é a continuação do post anterior sobre o git. Como prometido, hoje vou explicar como configurar o git para usar http ou invés de ssh.

Começando do começo

Bom, começarmos a configurar o servidor você vai precisar de algumas coisas instaladas nele. São elas:
   – Um servidor web apache
   – Git
Você vai precisar também ter acesso como root neste servidor para poder fazer a configuração inicial do repositório.

Antes de prosseguir, vale uma ressalva: O apache é um treco chato… Se você pegar os fontes e compilar, o ‘document root’ e os arquivos de configuração serão em um lugar. Se você estiver usando um Red Hat serão em outro, em um Debian serão em outro ainda. E no windows então! Nem faço idéia como funciona o apache no windows.
Por isso, primeiro sempre darei uma explicação “genérica” de como a coisa funciona. Nos exemplos que darei, os caminhos de arquivos e tudo mais serão baseados em Debian. Se você uma um sistema operacional diferente, leia o manual do apache e veja onde estão localizados seus arquivos.

Configurando o servidor

A primeira coisa a fazer é certificar-se que o módulo dav_module está sendo carregado pelo apache. Isto pode ser feito adicionando as seguitnes linhas os seu httpd.conf:
LoadModule dav_module libexec/httpd/libdav.so
AddModule mod_dav.c
DAVLockDB "/usr/local/apache2/temp/DAV.lock"


No Debian, isto pode ser feito de uma outra maneira. Deste jeito:
# a2enmod dav_fs
# a2enmod dav


Depois disto, é preciso criar um repositório “pelado” para o git. Para isto, criaremos um diretório dentro do nosso “document root”, criaremos o reporitório dentro deste diretório recém criado, e por fim, deixaremos o usuário do apache como dono deste diretório e de todos os seus sub-diretórios. No Debian fica assim:
# mkdir /var/www/novo_projeto.git
# cd /var/www/novo_projeto.git
# git --bare init
# cd ../
# chown -R www-data:www-data novo_projeto.git/


Agora, vamos criar um usuário/senha para acessar o projeto . A sintaxe é assim:
htpasswd -c /caminho/para/o/arquivo/de/senha <usuario>


O diretório onde se encontra o arquivo de senhas tem que ser lido pelo apache e, de preferência, não ser lido pelo resto do mundo. O parâmetro -c passado ao htpasswd significa que criaremos um novo arquivo. Se o arquivo já exitir e você quiser apenas acrescentar mais um usuário, htpasswd deve ser chamado sem o parâmetro -c.

Aqui no Debian, ficou assim:
# htpasswd -c /etc/apache2/passwd.git gituser


Depois de criado o usuário, vamos definir as regras do apache para o diretório do nosso repositório. Geralmente você precisaria adicionar algo assim ao seu httpd.conf:
<Location /meu_repo>
   DAV on
   AuthType Basic
   AuthName "Git"
   AuthUserFile /caminho/para/o/arquivo/de/senha
   Require valid-user
</Location>


Como o Debian lê automaticamente os arquivos em /etc/apache2/conf.d/, eu criei o arquivo /etc/apache2/conf.d/git.conf e adicionei o seguite a ele:
<Location /novo_projeto.git>
   DAV on
   AuthType Basic
   AuthName "Git"
   AuthUserFile /etc/apache2/passwd.git
   Require valid-user
</Location>


Agora, reinicie o apache. No Debian fica assim:
# /etc/init.d/apache2 restart


Neste ponto o servidor já deve estar funcionando corretamente. Para testar, acesse o seu servidor da seguinte maneira:
http://servidor/novo_projeto.git


O servidor peguntará seu usuário/senha. Depois de informá-las, se você ver uma listagem de diretórios e arquivos do git, o servidor está funcionando corretamente.

Configurando o cliente

Agora que o servidor já está configurado, é hora de configurar o cliente.
A primeira coisa a fazer, é informar nosso usuário e senha pra que não tenhamos que ficar digitando isso toda vez… é chato! Fazemos isso adicionando as seguintes linhas ao arquivo $HOME/.netrc:
machine <servidor>
login <usuário>
password <senha>

Como nossa senha está aí, é bom restringir o acesso a este arquivo. Fazemos isto assim:
$ chmod 600 ~/.netrc


Depois disso, precisamos configurar o git para acessar nosso servidor. Isso é muito simples.

$ git config remote.novo_projeto.url http://<usuário>@<servidor>/novo_projeto.git/

OBS: Não esqueça da ‘/’ no final da url, senão você vai cair num redirecionamento eterno…

Bom, aqui já está tudo configurado. Só o que precisamos fazer agora é ‘empurrar’ os arquivos do projeto para o servidor.
$ git push novo_projeto master
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from 5b0bc00758855aef6dafe7aa9849443aea0dbf1c
to b4857d97182a582c76961370de489b14385f9af9
sending 13 objects
done


Bom, é isso aí! Git configurado pra usar HTTP. Agora você que decide como usar seu Git.

Apresentando-se ao git

O que faremos aqui é versionar um projeto que já temos. Neste exemplo meu projeto estará em /home/juca/src/novo_projeto. Então, vamos lá!

Depois de instalado o git (instruções de instalação aqui) a primeira coisa a fazer, é apresentar-se ao git. Para tanto, vamos informar ao git nosso nome e email.
$ git-config --global user.name "Juca"
$ git-config --global user.email "juca@minhacasa.nada"

Versionando nosso primeiro projeto

Agora que já nos apresentamos ao git, vamos versionar nosso projeto. A primeira coisa é ir até o diretório onde está seu projeto, depois dar um “git init” neste diretório para criar um novo repositório do git, e por fim, adicionar e ‘commitar’ os arquivos do projeto. A coisa fica assim:
$ cd /home/juca/src/novo_projeto
$ git init
Initialized empty Git repository in /home/juca/src/novo_projeto/.git/
$ git add .
$ git commit

Com o que fizemos até agora, já temos o projeto versionado. Para ver o log dos commits use “git log”, assim:
$ git log
commit dc00b38b6beb9db50d8b0ad0fb7e6a80689c80cb
Author: Juca
Date: Tue Jan 5 12:41:51 2010 -0200

   Primeiro commit do tutorial

Podemos também listar os arquivos que estão sob o controle de versão usando “git ls-files”, assim:
$ git ls-files
arquivo1
arquivo2


Alterando e trabalhando com os arquivos do projeto

Agora, vamos alterar um arquivo pra ver como fica.
emacs arquivo1


Altere o que quiser e salve o arquivo. Antes de adicionar e commitar podemos ver o que foi alterado com “git diff”:
$ git diff --color arquivo1
diff --git a/arquivo1 b/arquivo1
index a353720..d80b33a 100644
--- a/arquivo1
+++ b/arquivo1
@@ -1 +1,2 @@
-Oi, eu sou o arquivo1. Essa merda é só pra brincar com o git e escrever o tuto...
\ No newline at end of file
+Oi, eu sou o arquivo1 (agora alterado).
+Essa merda é só pra brincar com o git e escrever o tuto...
\ No newline at end of file arquivo1

Obs: A opção “–color” é usada para que o resuldado do diff fique colorido, mas aqui no tuto as cores foram pro saco…

Agora, é só adicionar e commitar o arquivo modificado.

$ git add arquivo1
$ git commit


Criando branches

Agora vamos falar de branches. Branches não custam nada no git, e são muito fáceis de manejar. Todo novo repositório do git é criado com um branch chamado “master”. Tudo o que fizemos até agora foi neste branch. Vamos criar um novo agora com “git branch”


$ git branch #primeiro para ver os branchs que já existem
* master
$ git branch teste #criando o branch 'teste'
$ git checkout teste #mudando para o branch 'teste'


Agora, vamos alterar um arquivo no branch teste.

$ emacs arquivo1


Altere e salve o arquivo. Em seguida, adicione e commite o arquivo modificado

$ git add arquivo1
$ git commit


Neste ponto, temos arquivos que têm diferenças entre a versão do branch master e do branch teste. Para “juntar” as versões dos dois branches usaremos “git merge”. O que faremos é o seguinte: Primeiro voltaremos ao branch master e depois faremos o merge das versões.

git checkout master
git merge teste


Agora, depois do merge, você pode ver que as alterações feitas no branch teste também estão visíveis no branch master. Sendo assim, podemos apagar o branch teste.

$ git branch -D teste


Trabalhando com os outros

Bom, até agora foi o basicão do “eu trabalhando comigo mesmo”, mas a graça da coisa é distribuir o código e desenvolver com os outros, não? Então! agora vamos ver como usar o git para distribuir (ou receber de outros) o código.

Clonando um projeto

Vamos supor que eu (Juca) estou em hostjuca e um outro cara (Zé) está em hostze e quer contribuir com o projeto. Para fazer isto, o git pode usar ssh ou http. Vamos começar pelo ssh é qué mais simples. O Zé precisa ter acesso liberado no ssh da minha máquina. hostjuca será o repositório “principal”

O Zé ainda não tem uma cópia do projeto, então a primeira coisa a fazer é clonar o projeto com “git clone”. A sintaxe do “git clone” é assim (lembrando que estamos usando ssh):

git clone ssh://[usuario@]host:[porta]/caminho/pro/repositorio


Então, pro Zé clonar meu projeto, a coisa ficaria assim:

ze@hostze:~/src$ git clone ssh://ze@hostjuca:22/home/juca/src/novo_projeto
Initialized empty Git repository in /home/ze/src/novo_projeto/.git/
ze@hostjuca's password:
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 7 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (7/7), done.


Agora o Zé já tem os arquivos do meu projeto e pode brincar a vontade.

ze@hostze:~/src$ cd novo_projeto
ze@hostze:~/src/novo_projeto$ vi arquivo2 #O Zé é filho do capeta, vocês viram, né?
ze@hostze:~/src/novo_projeto$ git add arquivo2
ze@hostze:~/src/novo_projeto$ git commit


Sincronizando os repositórios

Agora as versões do Juca e do Zé estão diferentes. Temos duas opções para sincronizar estas duas versões. Ou o Juca ‘puxa’ as mundaças do Zé ou o Zé empurra as mudanças dele para o repositório do Juca.

Antes de prosseguirmos, vale uma explicaçãozinha sobre o comportamento do git. O git não gosta que você empurre o mesmo branch que você clonou (ou puxou). Parece estranho, mas tem sentido. Tente empurrar o branch master que você verá um aviso muito explicativo.

Empurrando as coisas

Como o Zé já tem acesso a máquina do Juca, vamos deixá-lo empurrar as mudanças para o repositório principal. Isso será feito com “git push”. A sintaxe do “git push” é a seguinte:

git push ssh://[usuario@]host:[porta]/caminho/pro/repo branch_local


Por causa do comportamento do git, o Zé tem que primeiro criar um novo branch e empurrar este novo branch. A coisa fica assim:

ze@hostze:~/src/novo_projeto$ git branch branchdoze
ze@hostze:~/src/novo_projeto$ git push ssh://ze@hostjuca:22/home/juca/src/novo_projeto branchdoze
ze@hostjuca's password:
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 349 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://ze@hostjuca:22/home/juca/src/novo_projeto
* [new branch] branchdoze -> branchdoze


Com isso, lá no repositório principal (hostjuca) foi criando um branch chamado branchdoze, e para terminar a operação o Juca (dono do repositório principal) precisa fazer um ‘merge’ do branch ‘branchdoze’ para o branch ‘master’.

juca@hostjuca:~/src/novo_projeto$ git merge branchdoze


Com isso temos o código que está em hostze e o código que está em hostjuca (o repo principal) sincronizados.

Voltando no tempo…

Lembra que falei que tinhamos duas opções pra sincronizar o código: empurrar ou puxar? Então, o que fizemos até aqui foi empurrar o código de um desenvolvedor para o repositório principal. Vamos fazer o contrário (o repo principal puxa as alterações do dev) só pra ver como fica.

Pra isso, vamos voltar o código do repositório principal para a versão anterior as mudanças feitas pelo Zé lá em hostze. Isso é feito com “git reset”. A sintaxe é a seguinte:

$ git reset --hard <commit>


Então, será feito o seguitne no repositório principal: primeiro daremos um “git log” pra ver qual o hash do commit que queremos e depois usaremos o git reset para voltar para esta versão. Assim:

juca@hostjuca:~/src/novo_projeto$ git log
commit 2117cfdf7a4ff0683487a33008e3fc5bca42cdbe
Author: Zé
Date: Tue Jan 5 15:49:24 2010 -0200

   Primeira alteração do Zé

commit 937f17e96ee04e1221783e664d270dda5d87657d
Author: Juca
Date: Tue Jan 5 14:37:20 2010 -0200

   Só testando o novo branch

commit dc00b38b6beb9db50d8b0ad0fb7e6a80689c80cb
Author: Juca
Date: Tue Jan 5 12:41:51 2010 -0200

   Primeiro commit do tutorial

juca@hostjuca:~/src/novo_projeto$ git reset --hard 937f17e96ee04e1221783e664d270dda5d87657d
HEAD is now at 937f17e Só testando o novo branch
Com isso temos o nosso repositório principal de volta a época em que o Zé não tinha alterado nada.

Puxando as coisas

Agora vamos sincronizar fazendo com que o repositório principal ‘puxe’ as mudanças do repositório do Zé. Isso será feito com “git pull”. A sintaxe é a seginte:

$ git pull ssh://[usuario@]host:[porta] branch_remoto


Então, pro Juca puxar as mudanças do Zé, a coisa fica assim:

juca@hostjuca:~/src/novo_projeto$ git pull ssh://juca@hostze:22/home/ze/src/novo_projeto master
juca@hostze's password:
From ssh://hostze:22/home/ze/src/novo_projeto
* branch master -> FETCH_HEAD
Updating 937f17e..2117cfd
Fast forward
arquivo2 | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)


Como não existia nenhum conflito entre as versões, tudo ocorreu tranqüilamente, e já temos novamente nossos códigos em hostze e hostjuca sincronizados.

Bom, isso é só uma amostra do que o git pode fazer, mas o git pode fazer muito mais que isso. Dá uma olhadinha no gitmagic pra você ver.

Na minha próxima postagem sobre o git, explico como configurar o git para usar http ao invés de ssh.

Então, até lá e divirtam-se!

Pergunta: Pra que serve um túnel ssh reverso?
Resposta: Eu uso isso pra chegar em uma máquina que não poderia chegar diretamente (máquina atrás de nat e talz…)

Vamos lá!

Suponhamos que eu tenha dois hosts distintos (host1 e host2). host1 está atrás do nat e host2 está conectado diretamente na internet. O que faremos aqui é abrir uma conexão ssh de host1 para host2 e deixar o túnel aberto, assim podendo ir de host2 para host1 (adeus nat!).

A sintaxe para sair de host1 para host2, deixando o túnel aberto, seria assim:
ssh -R [porta_pra_voltar_pra_host1]:localhost:[porta_ssh_host2] host2

Então, eu estando em host1 faria o seguinte:
juca@host1:~$ ssh -R 2222:localhost:22 host2

Ai, enquanto (e somente enquanto) esta conexão estiver aberta, é possivel conectar de host2 em host1 usando:
ssh -p [porta_pra_voltar_pra_host1] localhost

Então, eu estando em host2, faria o seguite:
juca@host2:~$ ssh -p 2222 localhost

Bom… É isso ai. Molezinha, não?

Primeiro, instalar o banco:
# aptitude install postgresql

Depois de baixar e instalar é hora de configurar. O usário root do nosso banco de dados é o postgres. No processo de instalação foi criado um usuário chamdo postgres também no sistema. Então, nos logaremos com este usuário.
# su postgres

Por padrão, o usuário de banco de dados ‘postgres’ não tem senha, então agora nos logaremos no shell do PostgreSQL para alterar a senha do usuário postgres.
Primeiro, logando no shell…
$ psql

Agora, já no shell do PostgreSQL, vamos alterar a senha do usuário postgres
postgres=# ALTER USER postgres WITH PASSWORD 'qualquersenha';

Esse cara que a gente acabou de configurar ai é o root do banco de dados… A gente não vai ficar usando esse usuário nas nossas aplicações, né? Então! vamos criar um novo usuário.
postgres=# CREATE USER usuario NOCREATEDB NOSUPERUSER NOCREATEROLE PASSWORD 'senha';

Agora, vamos criar uma tabela também
postgres=# CREATE DATABASE minhabase;

Bom, já criamos usário, base de dados… Agora precisamos configurar o modo como os clientes se autenticarão no servidor. Essas configurações se encontram no arquivo pg_hba.conf, que no Debian fica em /etc/postgresql/8.4/main.
OBS: Esse 8.4 aí em cima se refere à versão que estou usando. Se sua versão for diferente, o número também será.
Vamos abrir o arquivo e editá-lo.
emacs /etc/postgresql/8.4/main/pg_hba.conf

Como o arquivo é bem comentado não vou me alongar na explicação… Qualquer coisa é só olhar aqui.

A primeira coisa que farei aqui é deixar o tipo de autenticação para os usuários locais como md5. Então, a linha que era assim:
local all all ident
Ficou assim:
local all all md5

Do jeito que as coisas estão, somente usuários locais poderão se conectar ao banco. Então agora vamos fazer umas configurações para que clientes remotos possam se conectar ao banco.

O primeiro passo para liberar conexões para clientes remotos é adicionar uma liniha ao pg_hba.conf. A linha seria algo como:
host all all 0.0.0.0/0 md5.

Pra finalizar precisaremos também editar o arquivo postgresql.conf, que fica no mesmo diretório que o pg_hba.conf.
emacs /etc/postgresql/8.4/main/postgresql.conf

No postgresql.conf procure pela linha #listen_addresses = ‘localhost’ e mude para listen_addresses = ‘*’

Agora é só reiniciar o postgresql…
/etc/init.d/postgresql-8.4 restart

E está tudo pronto!