Mini Curso Gerenciamento de Configuração e …...Gerenciamento de Configuração e Mudança GIT Funcionamento Interno Master$ Branch1 Merge entre a “Branch 1” com a “Master”

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




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.


“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


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


GCM

Usar GCM apropriadamente pode fazer seu esforço de desenvolvimento diminuir e dá a flexibilidade que você precisa para trabalhar com eficiência


É essencial planejar como vai ser o seu GCM antes de iniciar o

desenvolvimento de um software

GCM


Terminologias


É 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


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


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


Princípios Gerais


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


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


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


Padrões de GCM


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


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


Padrões

Mau uso do Branches:


Padrões

Mau uso do Branches:


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.


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


Sistema de Controle de Versão Distribuído ( Git )


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


GIT Funcionamento Interno

Commits Ponteiro

Master


GIT Funcionamento Interno

Master

Branch 1

Criação de uma nova branch

Ponteiros

Commits


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


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


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


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



hRp://git-‐scm.com/downloads hRps://www.eclipse.org/downloads/

Preparação do Ambiente


Clone a Git Repository

h"ps://github.com/jadsonjs/workshopsinfo.git


Clone a Git Repository


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


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


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


Push Realizado com sucesso

Team -> Push to Upstream


•  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


•  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


Irá gerar a mensagem Non-fast-forward

Team -> PUSH


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


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


•  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


Ú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


Caso haja algum conflito a ser resolvido, o GIT pedirá para você resolver.

Team -> REBASE 3


A resolução de conflitos é igual ao SVN, mostrando os códigos fontes lado a lado.

Team -> REBASE 4


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


Continuar para a próxima classe em conflito, até que todos os conflitos tenham sido resolvidos

Team -> REBASE 6


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


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)



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.









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



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



É possível fazer alternância entre as branches locais com a operação de checkout



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.



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.
