Mini curso gerenciamento de configuração e mudança com GIT + Eclipse - III workshop sinfo ufrn

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

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

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

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

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

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

Terminologias

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.

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

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.

Princípios Gerais

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

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
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
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 Funcionamento Interno
Commits
Ponteiro
Master

Master
Branch
1
Criação de uma nova branch
Ponteiros
Commits

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
Referência
local
ao
repositório
remoto
Remote
Repository
FETCH
O FETCH apenas atualiza a sua referência ao repositório
remoto na área chamada de: “Remote Tracking”

GIT PULL (FETCH + MERGE)
Your
Computer
Local
Repository
Remote
Tracking
Remote
Repository
MERGE
FETCH
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
Novo
commit
local
Novo
commit
remoto
Remote
Repository
FETCH
REBASE
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

Preparação do Ambiente
hRp://git-‐scm.com/downloads
hRps://www.eclipse.org/downloads/

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 Settingsnome_usuariogit (Windows)

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

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

Team -> Push to Upstream
Push Realizado com sucesso

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;
<<<<<<<<

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

Team -> PUSH
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 -> 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.

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

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.

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

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

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

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

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.

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.

Mini curso gerenciamento de configuração e mudança com GIT + Eclipse - III workshop sinfo ufrn

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Mini curso gerenciamento de configuração e mudança com GIT + Eclipse - III workshop sinfo ufrn

Ähnlich wie Mini curso gerenciamento de configuração e mudança com GIT + Eclipse - III workshop sinfo ufrn (20)

Mehr von Jadson Santos

Mehr von Jadson Santos (17)

Mini curso gerenciamento de configuração e mudança com GIT + Eclipse - III workshop sinfo ufrn