4. Controle de versão e social coding

4.1 - O que é? Pra que serve?

  • Salvar o estado do código em revisões sequenciais.

  • Integrar o trabalho do time.

  • Acompanhar as mudanças no código (encontrar bugs, rollback, etc).

  • Ajuda, mas não resolve conflitos na edição de arquivos.

  • Boa prática: versionando desde o dia 0.

Imagens:

4.2 - Sistemas de controle de versão

4.2 - Quais sistemas existem?

Tópicos:

  • RCS (pré-histórico).

  • CVS (roots, centralizado).

  • Subversion (svn) (tradicional, centralizado).

  • Mercurial (hg), Monotone (mtn), Bazaar (bzr), Darcs, Git (modernos, distribuídos).

Imagens:

  • Ícones e screenshots do site de cada sistema.

4.2 - Centralizados versus distribuídos

Tópicos:

  • Centralizadaso:

    • Repositório central para onde são enviadas mudanças.

    • Ou seja, existe uma cópia de referência.

  • Distribuídos:

    • Cada cópia de trabalho é um repositório completo e possui todo o histórico de revisões (também uma forma de backup).

    • Não requer um repositório central, porém um ponto de trocas central pode ser estipulado entre os desenvolvedores/as.

Imagens:

4.3 - Git: introdução

4.3 - Características

  • Desenvolvido inicialmente por Linus Torvalds.

  • É o mais popular e difundido.

  • Complexo e poderoso, porém pode ser usado de modo simples.

  • Checagem de integridade nativa!

4.3 - Instalando e configurando

  • Focaremos em git pela linha de comando.

  • Disponível em tudo que é tipo de sistema operacional.

  • A única exigência é especificar um nome e email (de preferência funcional ;) para constar nas informações de revisão.

Roteiro do screencast:

sudo apt-get install git
git config --global user.name  "Meu Nome"
git config --global user.email "meu@email.tld"

4.3 - Repositórios

  • Repositórios: “pastas geridas pelo git”.

  • Pasta “.git” criada no repositório: não polui seu projeto.

Roteiro do screencast:

# Adicionando nosso projeto no git
cd ~/projetos/blogatico
git init

# Clonando um projeto existente
cd ~/projetos/
git clone https://github.com/rhatto/boaspraticas

4.4 - Trabalhando no projeto

4.4 - Trabalhando no projeto

  • Três estágios de mudanças: cometidas (commited), marcadas para commit (staged) e modificadas (changed).

Roteiro do screencast:

cd ~/projetos/blogatico
git status
git add README.mdwn
git status
gedit README.mdwn
git status
git diff
git commit -m "Primeira revisão"
git add README.mdwn # mudanças recentes adicionadas ao estágio de lançamento
git commit -m "Segunda revisão"
git add .
git commit -m "Adiciona demais arquivos" # coloca todas as mudanças no estágio e comete

Imagens:

4.4 - Log de revisões

  • Árvore de histórico do repositório.

  • Cada “revisão” do histórico representa um estado do repositório (snapshot).

  • ID da revisão: hash SHA-1.

Roteiro do screencast:

cd ~/projetos/blogatico
git log
sudo apt-get install gitk
gitk

Imagens:

4.4 - Interface gráfica

Roteiro do screencast:

sudo apt-get install git-cola
git cola

4.5 - Ramificações (branches e merges)

  • Existem vários “ramos” na história de um software.

  • Os ramos, ou branches, divergem e convergem.

  • A convergência nem sempre é suave, porém o git auxilia com várias estratégias.

Roteiro do screencast:

cd ~/projetos/blogatico
git branch develop
git checkout develop
git commit -a
git checkout master
git merge develop

4.6 - Usando o git-flow

  • O git-flow é um plugin para o git.

  • Ele força um fluxo de trabalho integrado.

  • Branches básicos (nomes podem ser customizados):

    • master: branch principal com o código que é submetido para a produção.

    • develop: branch de desenvolvimento onde funcionalidades são integradas e seu conjunto testado.

    • features/: prefixo para branches onde funcionalidades são desenvolvidas.

    • hotfix/: prefixo para branches de correções rápidas (bugfixes).

Roteiro do screencast:

cd ~/projetos/blogatico
git flow init
git flow feature start doc
git commit -a
git flow feature finish

4.7 - Submódulos

  • Um repositório git dentro de outro.

  • “Trava” o submódulo em revisões específicas.

  • “Sistema” de gestão de dependências de código simples e integrado ao git.

Roteiro do screencast:

# No repositorio
cd ~/projetos/blogatico
git submodule add https://github.com/dhg/Skeleton skeleton
git commit -a -m "Adiciona skeleton"

# Clonando o repositorio noutro local
cd ..
git clone blogatico blogatico-clonado
cd blogatico-clonado
git submodule update --init

# Ou:
cd ..
git clone --recursive projeto projeto-clonado

4.8 - Social coding (gitlab, github, etc)

4.8 - Repositórios públicos

  • O git e outros sistemas similares foi feito para facilitar o compartilhamento de código e o desenvolvimento colaborativo.

  • Isso é feito através da disponibilização pública dos repositórios, que podem ser clonados ou terem seu conteúdo copiado para outros repositórios.

Roteiro do screencast:

git pull origin master

Imagens:

  • Ciclo de desenvolvimento colaborativo.

4.8 - Redes sociais de código

  • Existem serviços que facilitam a criação de repositórios e a interação entre desenvolvedores(as).

  • Exemplos: BitBucket, Github, Gitlab.

4.9 - Github: criando e forkando um projeto

Nesta aula será apresentado o Github e será mostrado como criar e forkar um projeto.

Roteiro do screencast:

  • Criação de um repositório para o “blogatico”.

  • Forkando o projeto “boaspraticas”.

4.10 - Github: fazendo um pull request

Roteiro do screencast:

  • Fazendo um pull request no repositório do “blogatico”.

4.11 - Atividades

  1. Transforme o seu projeto num repositório git.

  2. Crie uma conta do Github ou no Gitlab.

  3. Bônus: git log to ChangeLog!

  4. Faça um fork do blogático e implemente alguma funcionalidade. Sugestões no arquivo TODO do projeto. Gostou das suas mudanças? Por que não fazer um pull request? :D