O que é, e pra que serve?

Mudanças Inevitáveis no Projeto

• Mudanças nos Requisitos
• Mudanças no Código Fonte
• Mudanças no Ambiente de Desenvolvimento
• etc...

Atividades da GCS

Fluxo de trabalho Integrado

Controle de Mudanças

Controle de Versão

Integração Contínua

Ferramentas que auxiliam no registro, avaliação, planejamento e acompanhamento das solicitações de mudanças mudanças

Ferramentas que realizam o registro histórico das configurações, controle da concorrência de edição dos arquivos, cria e mantém variações do projeto 

Ferramentas as quais executam scripts de construção, teste e métricas de qualidade para avaliar a integridades do Sistema

Ferramentas de GC/CM

Situações Comuns

1. "Essa mudança não deu certo, vamos voltar como estava antes."
2. "O que mudou nessa rotina? Quando foi essa mudança? Quem é o responsável?"
3. "Esse defeito já tinha sido corrigido, como apareceu?"
4. "A nova função que implementei ontem era pra estar aqui mas sumiu."  
5. "Preciso daquela versão que está no cliente. Cadê os arquivos?"
6. "Como fazer os teste sem para o desenvolvimento?"

Registrar a evolução do projeto

Registrar a evolução do projeto

• O que mudou?
• Quem mudou?
• Quando mudou?

Registrar a evolução do projeto

Trabalho em equipe

Trabalho em Equipe

Provê mecanismos para controle de concorrência:

• Travamento
• Mesclagem de arquivos
• Ramos individuais

Variações de projeto

Um controle de versão é composto por:

Rastreabilidade Bidirecional

Changeset

=

diferença entre duas configurações

Conceitos importantes

Configuração é o estado dos arquivos do projeto em um determinado momento

Revisão é uma configuração registrada no repositório

Changeset é o conjunto de diferenças entre duas configurações

Versão é uma configuração, é uma revisão ou um revisão usada em produção (Release)

Operações do Controle de Versão

Variam de acordo com o arranjo entre o repositório e espaço de trabalho

Controle de Versão Centralizado

Controle de Versão Distribuido

Sincronização de Repositórios

Resumo das operações Básicas

Identificação das Revisões

Sincronização no Controle de Versão Centralizado

Passo 1:

• Duas cópias de trabalho são criadas a partir do comando checkout.
• As duas iniciam no mesmo estado.

Sincronização no Controle de Versão Centralizado

Passo 2:

• Os dois desenvolvedores executam modificações nas suas cópias de trabalho, mas Aline publica antes no repositório.

Sincronização no Controle de Versão Centralizado

Passo 3:

• Roberto tenta publicar suas alterações, mas o controle de versão recusa justificando que as alterações foram baseadas em arquivos desatualizados.
• No caso, um ou mais arquivos alterados por Roberto já haviam sido alterados por Aline antes.

Sincronização no Controle de Versão Centralizado

Passo 4:

• Na atualização da cópia de trabalho, o controle de versão já mescla automaticamente as revisões.

Sincronização no Controle de Versão Centralizado

Passo 5:

• Após conferir se a atualização e a mesclagem produziram o resultado desejado, Roberto envia as mudanças ao repositório.
• Enquanto isso, Aline já trabalha em outra tarefa, executando novas alterações.

Sincronização no Controle de Versão Centralizado

Passo 6:

• O commit de Aline pode ser aceito sem problema se nenhuma das revisões que vieram depois da atualização da cópia de trabalho tiver alterado os mesmos arquivos que Aline.
• É uma situação possível de acontecer, mesmo que não seja comum.

Sincronização no Controle de Versão Distribuído

Passo 1:

• Roberto clona o repositório de Aline.
• Ambos partem do mesmo ponto.

Sincronização no Controle de Versão Distribuído

Passo 2:

• Aline e Roberto publicam suas alterações nos seus respectivos repositórios, sem interferir no repositório um do outro.

Sincronização no Controle de Versão Distribuído

Passo 3:

• Roberto sincroniza seu repositório com as revisões publicadas por Aline.
• Sua área de trabalho não é afetada pela sincronização.

Sincronização no Controle de Versão Distribuído

Passo 4:

•  A mesclagem entre as revisões de Aline e Roberto é feita explicitamente na área de trabalho de Roberto através de um comando merge.
• Enquanto isso, Aline já gera outra revisão no seu repositório.

Sincronização no Controle de Versão Distribuído

Passo 5:

•  Após conferir se a mesclagem produziram o resultado desejado, Roberto envia as mudanças ao seu repositório.
• Paralelamente, Aline publica mais uma vez no seu repositório.

Sincronização no Controle de Versão Distribuído

Passo 6:

•  Roberto envia suas revisões ao repositório de Aline, que as combina com o histórico de revisões já existente.

Mas antes, o que é baseline e codeline?

Delta Storage

• mantém como um conjunto de arquivos e as mudanças feitas a cada arquivo ao longo do tempo

Snapshot Storage

• Conjunto de snapshots de arquivos;
• Se foi alterado, o arquivo não é armazenada ( link para o arquivo que já foi armazenado)

O que é o Git?

• É um sistema de controle de versão distribuído
• Uma das ferramentas de GC mais utilizadas (Rebellabs)
• Foi criado por Linus Torvalds como alternativa para manter o Kernel do Linux

Existem três componentes em um projeto Git:

• Um repositório (repository), onde as mudanças são registradas

• Um espaço de trabalho (working directory), onde contém os arquivos que você está trabalhando

• Um index ou staging area, onde os commits/revisões são preparadas, comparando os arquivos do working directory e do repository.

Em um fluxo básico do Git

1. Os arquivos são modificados no espaço de trabalho
2. As mudanças são preparadas (staged) com o que você deseja incluir no próximo commit.
3. As mudanças são submetidas, o que as retira do index e as armazena no repositório.

Estados no GIT

Fluxos com Repositórios

Onde encontrar a explicação os comandos?

ou

Configurando o ambiente

Identificação

Editor

Verificar configurações atuais

Iniciando um projeto

Para iniciar um repositório Git:

Este comando cria toa a estrutura que o Git necessita para funcionar.

Os arquivos são criados na pasta oculta .git/

Verificando o estado do projeto

O git status exibe as alterações ocorridas no repositório desde o último commit.

Adicionando arquivos

O git add adiciona ou atualiza um arquivo da staging area.

Ou seja, o comando informa ao Git para rastrear o referido arquivo. Caso o arquivo já esteja sob controle do Git, ele o atualiza.

Confirmando mudanças

git commit transfere o estado do projeto salvo na staging area para o repositório do projeto.

Todo commit deve possuir uma mensagem de identificação, usada para descrever as alterações do commit.

Favor, use-a para tal fim.

Escreva mensagens intuitívas.

Comparando Alterações

O comando git diff compara o estado do repositório atualmente com o estado salvo na staging area

O git status informa "quem" foi alterado, mas e se eu quiser saber exatamente "o que" foi alterado?

O comando git diff --cached compara o estado do repositório salvo na staging area com o estado do último commit

Histórico de Alterações

O comando git log exibe o histórico de commits do projeto

Um pouco mais sobre git log

'Passeando' pelo Projeto

A partir do código associado aos commits você pode voltar para um determinado 'estado' do projeto

O comando git checkout também redireciona arquivos e branches

Se eu me arrepender das minhas últimas alterações?

Você pode descartar mudanças no seu working directory voltando o estado dos seus arquivos para o último salvo na staging area.

E se eu já adicionei as alterações na staging area?

O comando git reset HEAD devolve as modificações da staging area para o working directory.

E se eu já commitei minhas alterações?

1ª Solução: git reset

O comando git reset faz o projeto/arquivo voltar para um estado anterior.

2ª Solução: git reset

O comando git revert não desfaz um commit, mas cria outro removendo a alteração anterior

E se eu já commitei minhas alterações?

Removendo arquivos

O comando git rm remove um arquivo do seu projeto.

A opção --cached remove o arquivo apenas do Git, sem esta opção o comando remove o arquivo do seu computador também.

Ignorando arquivos

Deixar todos os arquivos contidos na pasta do projeto sob controle do Git pode acabar dificultando o gerenciamento, e muitas vezes simplesmente não achamos necessário rastrear alterações de alguns arquivos (arquivos temporários, executáveis e etc...).

O arquivo oculto .gitignore é o responsável por dizer ao Git quais arquivos ele pode ignorar.

Ignorando arquivos

• Basta adicionar uma pattern que o Git usará para ignorar os arquivos.

• Todos os arquivos que 'casarem' com as patterns serão ignorados.

• As patterns seguem o padrão utilizado nos sistemas unix/Linux.

Exemplos de patterns e extensões podem ser geradas em gitignore.io

Ramificando a produção de software

O Git permite criar uma linha independente de desenvolvimento no seu projeto. Isto permite alterações em partes especificas do software sem comprometer o restante do projeto.

Ramificando a produção de software

O comando git branch cria um novo branch a partir do último commit.

Além de visualizar commits antigos, o git checkout também é o responsável por alterar o branch corrente.

Após desenvolvedor uma funcionalidade separada do fluxo principal, muitas vezes é interessante incorporar as modificações no branch master.

O comando git merge uni dois branches novamente, combinando as funcionalidades do branch independente com o branch atual.

Quando não há commits posteriores à criação do branch, a incorporação das funcionalidades ocorre sem nenhum problema.

Porém, quando os branches divergem, o Git precisa que combinar seus conteúdos.

Para informar o trecho conflitante, o Git sinaliza as linhas do arquivo com algumas marcações(<<<<<<<, ======= e >>>>>>>), para corrigir o conflito e confirmar o merge, basta apagar as linhas desnecessárias do arquivo, mantendo conteúdo escolhido, e efetuar um novo commit. Este é basicamente o único trabalho manual que o Git necessita

Merge em novo commit

• --no-ff faz com que a mesclagem sempre crie um novo commit.

Após incorporar um branch à outro, pode não ser mais necessário manter uma ramificação. Para deletar um branch utiliza-se do parâmetro -d juntamente com o comando git branch

Branches Principais

Tempo de vida infinito

máster (origin/master)

• Reflete o estado do código fonte de produção

develop (origin/develop)

• Reflete ultimas mudanças entregues em desenvolvimento
• A.k.a.: "Integration Branch"

Branchs de Suporte

• ​Tempo de vida limitado
• Desenvolvimento paratelo entre membros da equipe;
• facilitar o rastreamento defeatures;
• Preparar releases para produção
• Correção rápida de problemas "live production"

Feature Branch

• Aka.: "topic branch"
• são usadas para desenvolver novos recursos para o lançamento futuro distante ou futuro.
• Existem apenas nos repositórios de desenvolvimento do desenvolvedor

Release Branch

Release branches dão suporte à preparação de uma nova liberação(release) de produção.

Utlizadas para pequenas correções de bugs e preparar metadados para uma versão (número da versão, datas de criação, etc.)

Hotfix Branch

• Criada quando ocoorre um erro crítico em uma versão de produção
• A hotfix é ramificada da tag correspondente na ramificação máster que marca a versão de produção.

Trabalhando com repositórios remotos

Muitas empresas possuem servidores dedicados para suas equipes, mas há algumas soluções no mercados que cumprem a mesma função.

Referenciando um repositório remoto

O comando git remote add é o responsável por referenciar um repositório remoto em um repositório local já existente

O comando git remote rm é utilizado para apagar uma referência à um repositório remoto. Util quando se deseja substituir o local onde o remoto está hospedado.

Copiando um repositório remoto

Quando se deseja iniciar/continuar um projeto já existente, utiliza-se dogit clone para copiar todo um repositório remoto para uma máquina local.

Baixando conteúdo do remoto

O Git disponibiliza duas maneiras de baixar as atualizações de um repositório remoto. O comando git fetch baixa as atualizações mas não as incorpora ao repositório local.

Baixando conteúdo do remoto

Outra maneira é utilizando o comando git pull, que baixa e incorpora as modificações no repositório local. Equivale à um git fetch seguido de uma git merge.

O que é uma release?

Um release de sistema é uma versão de um sistema de software distribuída aos clientes.  (Sommerville, 2011).

Versionamento Semânico

Dado um número de versão MAJOR.MINOR.PATCH, incremente a:

1. versão Maior(MAJOR): quando fizer mudanças incompatíveis na API,
2. versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e
3. versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade.

Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) estão disponíveis como extensão ao formato MAJOR.MINOR.PATCH.

https://semver.org/lang/pt-BR/​

Versionamento Semânico

Criando Versões

• Conforme incluímos funcionalidades no sistema, podemos definir pontos relevantes no software, que geralmente, marcam uma versão de lançamento.

• O comando git tag inclui um rótulo à um determinado commit para que este possa ser referenciado mais facilmente.

Compartilhando Versões

• Para visualizar as versões ja criadas, utilize  git tag.

• Por padrão, o comando git push não transfere tags

• Você deve enviar as tags explicitamente – você executa git push origin [nome-tag].

• se deseja enviar muitas tags ao mesmo tempo digite: