Mini Curso Gerenciamento de Configuração
e Mudança com GIT + Eclipse
Jadson Santos Amador Pahim
Gerenciamento de Configuração e Mudança
§ Gerenciamento de Configuração e Mudança
§ Padrões e Boas práticas de GCM
§ Sistema de controle de Versão Distribuído o Introdução ao GIT o Principais Comados o Resolvendo Conflitos o Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Gerenciamento de Configuração e Mudança
Gerenciamento de Configuração e Mudança
Define como a organização constrói e disponibiliza seu produtos e como identifica e rastreia as suas mudanças.
GCM
Fundamental para vários modelos de processos consolidados como: RUP, MPS-BR e CMMI
Compreende fatores como: gerenciamento de build, gerenciamento do processo de desenvolvimento e fluxo de trabalho da equipe, controle de versão dos artefatos do software.
Gerenciamento de Configuração e Mudança
“Um conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.”
Roger Pressman, Software Engineering: A Practitioner's Approach
GCM
Gerenciamento de Configuração e Mudança
Um bom processo de configuração e mudança permitirá um melhor controle sobre a evolução dos artefatos do código, evitando sua degradação com o tempo.
GCM
Erro Aprimoramento
Caso de Uso
Código Fantasma
Chapolin
Será preciso um grande esforço manual para fazer com que coisas inacabadas não sejam disponibilizadas para os usuários finais
Lixo
Gerenciamento de Configuração e Mudança
GCM
Usar GCM apropriadamente pode fazer seu esforço de desenvolvimento diminuir e dá a flexibilidade que você precisa para trabalhar com eficiência
Gerenciamento de Configuração e Mudança
É essencial planejar como vai ser o seu GCM antes de iniciar o
desenvolvimento de um software
GCM
Gerenciamento de Configuração e Mudança
Terminologias
Gerenciamento de Configuração e Mudança
É o lugar onde o desenvolvedor mantém todos os artefatos que ele precisa para realizar uma tarefa
Workspace
É um conjunto de arquivos fontes e outros artefato que abrange algum componente de software a medida que eles mudam ao longo do tempo. Uma codeline contém todas as revisões de todos os artefatos ao longo de uma caminho evolutivo.
Codeline
Gerenciamento de Configuração e Mudança
1.0, 2.0,…, N.0 = Vesão da codeline ou tag.
Codeline
Um label que identifica um snapshot da codeline contendo vários revisões de cada componente no codeline
Tag
Gerenciamento de Configuração e Mudança
Uma Branch é uma versão de uma codeline como um todo que inicia na versão central (trunk ) e evolui independentemente.
Branch
Integração entre mudanças realizadas em uma codeline para outra.
Merge
Gerenciamento de Configuração e Mudança
Princípios Gerais
Gerenciamento de Configuração e Mudança
Há alguns princípios gerais que podem ser aplicados ao uso de CGM a todos os projetos de software. Porém os detalhes de como aplicá-los vai depender do tamanho e da natureza do projeto
Princípios Gerais
Gerenciamento de Configuração e Mudança
Use controle de Versão: A maneira como a organização comunica trabalho desenvolvidos entre si mesma Faça Builds Periódicas e Integra Frequentemente: • Permite aos desenvolvedores verificarem o
funcionamento do software quando as parte do software executam em conjunto.
• Quanto frequente é esse período vai depender de detalhes internos de cada empresa.
• Integração demora um certo tempo, então isso pode adicionar um overhead ao processo de desenvolvimento.
Princípios Gerais
Gerenciamento de Configuração e Mudança
Permita Trabalho Autônomo: Cada membro da equipe deveria poder controlar que versão de que componente ele está trabalhando. Use Ferramentas: Se você tem muito processos manuais, erros ocorrerão com mais frequência
Princípios Gerais
Gerenciamento de Configuração e Mudança
Padrões de GCM
Gerenciamento de Configuração e Mudança
Padrões de GCM
Mainline Active Development Line Private Workspace Repository Private System Build Integration Build Third Party Codeline Task Level Commit Codeline Policy Smoke Test Unit Test Regression Test Private Versions Release Line Release-Prep Code Line Task Branch
Gerenciamento de Configuração e Mudança
Padrões
MAIN LINE PATTERN: Esse padrão descreve como gerenciar a sua codeline para minimizar os esforços de integração. Parece natural criar várias codeline para organizar seu trabalho em alguns casos. Porém mais codelines significa mais merges O esforço do merge pode superar a aparente organização
Gerenciamento de Configuração e Mudança
Padrões
Mau uso do Branches:
Gerenciamento de Configuração e Mudança
Padrões
Mau uso do Branches:
Gerenciamento de Configuração e Mudança
Padrões
MAIN LINE PATTERN: MAIN LINE: Uma codeline centralizada para servir de base para sub branches e merges que venham a ser necessários Use boas práticas de programação (integração contínua e testes automatizados) para assegurar que o que está na mainline é “usável”. Porém note que a MAIN LINE tem trabalho em progresso e nem sempre irá estar estável.
Gerenciamento de Configuração e Mudança
Padrões
MAIN LINE PATTERN Benefícios: • Ter uma MAIN LINE reduz merges e esforço de
sincronização
• A MAIN LINE traz alterações de volta para o fluxo de trabalho global, em vez de deixá-las fragmentadas
Gerenciamento de Configuração e Mudança
Sistema de Controle de Versão Distribuído ( Git )
Gerenciamento de Configuração e Mudança
Git é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte, com ênfase em velocidade. Cada diretório de trabalho do Git é um repositório com um histórico completo e habilidade total de acompanhamento das revisões, não dependente de acesso a uma rede ou a um servidor central.
GIT
Gerenciamento de Configuração e Mudança
GIT Funcionamento Interno
Commits Ponteiro
Master
Gerenciamento de Configuração e Mudança
GIT Funcionamento Interno
Master
Branch 1
Criação de uma nova branch
Ponteiros
Commits
Gerenciamento de Configuração e Mudança
GIT Funcionamento Interno Master
Branch 1
Merge entre a “Branch 1” com a “Master” apenas com mudança de ponteiros. Sem Cópias de Arquivos !!! Por isso o GIT consegue ser rápido e escalável.
Master
Your Computer
Gerenciamento de Configuração e Mudança
GIT FETCH
Local Repository
Remote Tracking
Remote Repository
FETCH
O FETCH apenas atualiza a sua referência ao repositório remoto na área chamada de: “Remote Tracking”
Referência local ao repositório remoto
Your Computer
Gerenciamento de Configuração e Mudança
GIT PULL (FETCH + MERGE)
Local Repository
Remote Tracking
Remote Repository
FETCH MERGE
Atualiza a sua referência ao repositório remoto e realiza o merge se existirem alterações localmente. Em caso de conflitos, marcará o seu código fonte local, será necessário editar os arquivos e remover o código não desejado e as marcações.
Your Computer
Gerenciamento de Configuração e Mudança
GIT REBASE
Local Repository Remote Tracking
Remote Repository
FETCH
Coloca o seu commit no topo da pilha de commits, como se você tive começado a alterar o código com a versão mais nova do repositório remoto. Em caso de conflitos, solicitará para você resolvê-los
REBASE
Novo commit remoto
Novo commit local
Gerenciamento de Configuração e Mudança
Gerenciamento de Configuração e Mudança
hRp://git-‐scm.com/downloads hRps://www.eclipse.org/downloads/
Preparação do Ambiente
Gerenciamento de Configuração e Mudança
Clone a Git Repository
h"ps://github.com/jadsonjs/workshopsinfo.git
Gerenciamento de Configuração e Mudança
Clone a Git Repository
Gerenciamento de Configuração e Mudança
Estrutura de um Projeto GIT
Mesmos commits. Isso significa que o repositório local está atualizado com o remoto.
Pelo mesmo desde a úl]ma fez que as referências ao remoto foram atualizadas
Gerenciamento de Configuração e Mudança
Estrutura de um Projeto GIT
Observação: Diferentemente do SVN o GIT não salva o projeto no workspace do eclipse e sim dentro do repositório git local da sua máquina. Por padrão em: /Users/nome_usuario/git (MacOS) /home/nome_usuario/git (Linux) C:\Documents and Settings\nome_usuario\git (Windows)
Team -> Commit
Gerenciamento de Configuração e Mudança
Modificar um artefato de código e realizar um commit no repositório local
Diferentemente do SVN, o commit não realizou nenhuma mudança do repositório remoto
hRps://github.com/jadsonjs/workshopsinfo.git
Team -> Push to Upstream
Gerenciamento de Configuração e Mudança
Push Realizado com sucesso
Team -> Push to Upstream
Gerenciamento de Configuração e Mudança
• PULL atualiza o seu repositório local com o repositório remoto (PULL = FETCH + MERGE )
• Observação: Caso você já tenha realizado alguma modificação no repositório local (feito algum commit que não tenha sido enviado ao remoto), o PULL não é aconselhado, pois se tiver conflitos, ele irá “bagunçar” suas classes marcando os conflitos:
>>>>>>>> v2e342as jadson@sinfo int a = 10; <<<<<<<< >>>>>>>> b66f8fk joao@sinfo int a = 20; <<<<<<<<
Team -> PULL
Gerenciamento de Configuração e Mudança
• Duas pessoas modificaram a mesma classe na mesma linha.
• Uma pessoa realizou o primeiro PUSH sem problemas.
• A segunda pessoa tenta realizar o PUSH , da mesma classe, para o repositório remoto. O Git mostrará uma mensagem impeditiva
Resolvendo Conflitos
Gerenciamento de Configuração e Mudança
Irá gerar a mensagem Non-fast-forward
Team -> PUSH
Gerenciamento de Configuração e Mudança
Non-fast-forward +- = não consegui encaminhar o seu commit de uma forma rápida porque o código do repositório remoto mudou, não está igual ao seu local, tem coisas novas lá. Você deve primeiro atualizar o seu repositório local para trazer o que há de novo no remoto, para só ai realizar o PUSH
Team -> PUSH
Gerenciamento de Configuração e Mudança
FETCH apenas atualiza a sua referência que você tem do repositório remoto. O seu código local continua da mesma forma que estava antes de realizar o FETCH.
Team -> FETCH from Upstream
Gerenciamento de Configuração e Mudança
• O Rebase tenta recuperar todos os commits trazidos para o Remote Tracking pelo FETCH e jogar o seu commit para o top do history, como se o commit tivesse sido realizado depois dos commits novos no repositório remoto
Team -> REBASE 1
Gerenciamento de Configuração e Mudança
Úl]mo Commit Local Antes da Modificação
Novos Commits no Remoto
Novos Commits no Remoto
Seu commit que deu erro ao tentar fazer o PUSH
Úl]mo Commit Local Antes da Modificação
Seu commit que deu erro ao tentar fazer o PUSH
Rebase!
• Após realizar o FECTH, para atualizar as referências no Remote Tracking, você então deve clicar em cima da referência remota do repositório e realizar um REBASE.
Team -> REBASE 2
Gerenciamento de Configuração e Mudança
Caso haja algum conflito a ser resolvido, o GIT pedirá para você resolver.
Team -> REBASE 3
Gerenciamento de Configuração e Mudança
A resolução de conflitos é igual ao SVN, mostrando os códigos fontes lado a lado.
Team -> REBASE 4
Gerenciamento de Configuração e Mudança
Ao solucionar o conflito, utilize a operação ADD TO INDEX para que a sua mudança realizada para resolver o conflito seja adiciona ao controle de versão e a classe deixe de ser mostrada como: “em conflito”. Equivalente à operação “mark as merge” do SVN
Team -> REBASE 5
Gerenciamento de Configuração e Mudança
Continuar para a próxima classe em conflito, até que todos os conflitos tenham sido resolvidos
Team -> REBASE 6
Gerenciamento de Configuração e Mudança
Cada mudança (tarefa) deve ser feita em uma branch local separada. Isso ajuda a melhorar a organização do seu repositório local. Um PUSH pode não ser imediatamente incorporado ao repositório remoto, principalmente se no processo de desenvolvimento existir uma etapa de revisão de código e autorização. Seu PUSH poderá passar um tempo para ser aprovado, utilizar neste caso uma única branch local pode começar a ficar difícil de gerenciar as suas alterações.
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Essa organização não é possível de ser feita com controle de versão centralizado como SVN, pois toda branch é remota • O ideal é que a branch master local não receba
commits, apenas PULL do remoto. Ou seja, a branch master local deve ser “read only”, commits devem ser realizados apenas nas branches específicas de cada tarefa (feature)
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Descrição do Fluxo “Branch por Tarefa”: 1º Vai Começar o trabalho estando na branch master local sem nenhum commit realizado localmente. Realiza um PULL para atualizar o repositório local com as ultimas mudanças no remoto. 2º Cria uma branch local a partir da master local e começa a fazer os commits da feature nessa banch. Ao realizar o PUSH se der algum problema, realizar o FETCH + REBASE na branch de trabalho local até conseguir enviar. 3º Enviou? Vai começar outra tarefa? Volta para a branch master local, realizar um PULL para atualizar a master local com as mudanças do remoto. Cria outra branch local para a nova tarefa e o fluxo se repete 4º Tarefa em produção ? Branch local da tarefa pode ser removida.
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
CUIDADO: Ao realizar o PUSH deve ser feita pela operação Remote -> PUSH .... Para escolher para qual branch remota deve ser enviado o seu commit. Se usar o “PUSH to Upstream” o eclipse por padrão envia o seu PUSH para uma branch remota de mesmo nome, que pode não ser a branch que você deseja enviar o commit
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Escolha a branch local que você está no momento e a remota para onde o PUSH será enviado. Por exemplo, pode ser a master remota. Clique em Add Spec -> Finish
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
É possível fazer alternância entre as branches locais com a operação de checkout
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Assim, caso o seu PUSH volte porque não foi aceito é possível votar para o código específico daquela tarefa, consertar o problema, enviar um novo PUSH e voltar para o branch local que você estava trabalhando. Quando a sua tarefa tiver em produção, o branch local pode ser removido, finalizado o fluxo.
Feature Branch Workflow
Gerenciamento de Configuração e Mudança
Quando o seu PUSH for aceito, ao realizar o PULL para a branch master as suas alterações realizadas na branch serão incorporadas à branch master local. Ao criar uma nova branch local deve-se fazer sempre partindo da master local, assim o seu código local estará sempre atualizado com o repositório remoto.
Gerenciamento de Configuração e Mudança