Mini Curso Gerenciamento de Configuração e Mudança com GIT + Eclipse. Jadson Santos Amador Pahim

Transcrição

1 Mini Curso Gerenciamento de Configuração e Mudança com GIT + Eclipse Jadson Santos Amador Pahim

2 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

3 Gerenciamento de Configuração e Mudança

4 GCM Define como a organização constrói e disponibiliza seu produtos e como identifica e rastreia as suas mudanças. 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. Fundamental para vários modelos de processos consolidados como: RUP, MPS-BR e CMMI

5 GCM 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

6 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. Erro Aprimoramento Código Fantasma Lixo Caso de Uso Chapolin Será preciso um grande esforço manual para fazer com que coisas inacabadas não sejam disponibilizadas para os usuários finais

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

8 GCM É essencial planejar como vai ser o seu GCM antes de iniciar o desenvolvimento de um software

9 Terminologias

10 Workspace É o lugar onde o desenvolvedor mantém todos os artefatos que ele precisa para realizar uma tarefa Codeline É 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.

11 Codeline Tag 1.0, 2.0,, N.0 = Vesão da codeline ou tag. Um label que identifica um snapshot da codeline contendo vários revisões de cada componente no codeline

12 Branch Uma Branch é uma versão de uma codeline como um todo que inicia na versão central (trunk ) e evolui independentemente. Merge Integração entre mudanças realizadas em uma codeline para outra.

13 Princípios Gerais

14 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

15 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.

16 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

17 Padrões de GCM

18 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

19 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

20 Padrões Mau uso do Branches:

21 Padrões Mau uso do Branches:

22 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.

23 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

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

25 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.

26 GIT Funcionamento Interno Commits Ponteiro Master

27 GIT Funcionamento Interno Ponteiros Branch 1 Master Criação de uma nova branch Commits

28 GIT Funcionamento Interno Master Branch 1 Master 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.

29 GIT FETCH Referência local ao repositório remoto Your Computer Local Repository Remote Tracking FETCH Remote Repository O FETCH apenas atualiza a sua referência ao repositório remoto na área chamada de: Remote Tracking

30 GIT PULL (FETCH + MERGE) Your Computer Local Repository MERGE Remote Tracking FETCH Remote Repository 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.

31 GIT REBASE Your Computer Novo commit local Novo commit remoto Local Repository Remote Tracking Remote Repository REBASE 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

32

33 Preparação do Ambiente hrp://git- scm.com/downloads hrps://

34 Clone a Git Repository h"ps://github.com/jadsonjs/workshopsinfo.git

35 Clone a Git Repository

36 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

37 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)

38 Team -> Commit Modificar um artefato de código e realizar um commit no repositório local

39 Team -> Push to Upstream Diferentemente do SVN, o commit não realizou nenhuma mudança do repositório remoto hrps://github.com/jadsonjs/workshopsinfo.git

40 Team -> Push to Upstream Push Realizado com sucesso

41 Team -> PULL 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; <<<<<<<<

42 Resolvendo Conflitos 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

43 Team -> PUSH Irá gerar a mensagem Non-fast-forward

44 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

45 Team -> FETCH from Upstream 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.

46 Team -> REBASE 1 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 Seu commit que deu erro ao tentar fazer o PUSH Rebase! Seu commit que deu erro ao tentar fazer o PUSH Úl]mo Commit Local Antes da Modificação Novos Commits no Remoto Novos Commits no Remoto Úl]mo Commit Local Antes da Modificação

47 Team -> REBASE 2 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.

48 Team -> REBASE 3 Caso haja algum conflito a ser resolvido, o GIT pedirá para você resolver.

49 Team -> REBASE 4 A resolução de conflitos é igual ao SVN, mostrando os códigos fontes lado a lado.

50 Team -> REBASE 5 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

51 Team -> REBASE 6 Continuar para a próxima classe em conflito, até que todos os conflitos tenham sido resolvidos

52 Feature Branch Workflow 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.

53 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)

54 Feature Branch Workflow 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.

55 Feature Branch Workflow

56 Feature Branch Workflow

57 Feature Branch Workflow 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

58 Feature Branch Workflow 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

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

60 Feature Branch Workflow 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.

61 Feature Branch Workflow 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.

62