Engenharia de Software –

Sistema de Controle de Versão

Prof. Washington Almeida, MSC, ISF 27002
 VCS – Version Control System
• Os sistemas de controle de versão identificam, armazenam e controlam o
acesso às diferentes versões dos componentes. Existem dois tipos de
sistema de controle de versão modernos:
1. Sistemas centralizados:
Um único repositório mestre mantém todas as versões dos componentes
de software que estão sendo desenvolvidos. O Subversion é um exemplo
amplamente utilizado de sistema de controle de versão centralizado.
2. Sistemas distribuídos:
Existem várias versões do repositório de componentes ao mesmo tempo.
O repositório Git é um exemplo amplamente utilizado de sistema de
controle de versão distribuído.

3
 VCS
• Sistemas de controle de versão centralizados e distribuídos fornecem
funcionalidades comparáveis, mas as implementam de maneiras
diferentes. As principais características desses sistemas são:
1. Identificação de versão e lançamento.
As versões gerenciadas de um componente recebem identificadores
únicos quando são submetidas a um sistema. Esses identificadores
permitem que diferentes versões do mesmo componente sejam
gerenciadas, sem alterar o nome dele. As versões também podem
receber atributos, e o conjunto de atributos pode ser utilizado para
identificar cada versão de maneira única.

4
 VCS
2. Registro do histórico de mudanças.
O sistema de controle de versão mantém registros das mudanças feitas para criar uma
versão nova de um componente, com base em uma versão anterior. Em alguns sistemas,
essas mudanças podem ser usadas para selecionar uma determinada versão de sistema.
Isso envolve marcar os componentes com palavras-chave que descrevem as mudanças
feitas. Depois, é possível usar essas palavras-chave para selecionar os componentes a
serem incluídos em uma baseline.
3. Desenvolvimento independente.
Diferentes desenvolvedores podem estar trabalhando simultaneamente no mesmo
componente. O sistema de controle de versões controla os componentes em que se fez
check-out para edição e assegura que as mudanças feitas em um componente por
desenvolvedores diferentes não interfiram umas nas outras.

5
 VCS
4. Apoio de projeto.
Um sistema de controle de versões pode apoiar o desenvolvimento de vários
projetos que compartilham componentes. Normalmente, é possível fazer
check-in e check-out de todos os arquivos associados a um projeto, em vez de
ter de trabalhar com um arquivo ou diretório de cada vez.
5. Gerenciamento de armazenamento.
Em vez de manter cópias separadas de todas as versões de um componente, o
sistema de controle de versões pode usar mecanismos eficientes para garantir
que não sejam mantidas cópias duplicadas de arquivos idênticos.
Nos casos em que há apenas pequenas diferenças entre os arquivos, o sistema
de controle de versão pode armazenar essas diferenças em vez de manter
várias cópias dos arquivos. Uma versão específica pode ser recriada
automaticamente aplicando as diferenças a uma versão mestre.

6
Check-in e Check-Out Repositório Centralizado
✓ A maior parte do desenvolvimento de software é uma atividade
para ser realizada por um time, então, frequentemente,
diversos membros trabalham no mesmo componente de modo
simultâneo.
✓ Por exemplo: Alice está fazendo algumas alterações em um
sistema, o que envolve mudanças nos componentes A, B e C.
Ao mesmo tempo, Roberto está trabalhando em alterações que
requerem mudanças nos componentes X, Y e C. Tanto Alice
quanto Roberto estão, portanto, alterando o componente C.
✓ É importante evitar situações em que as mudanças interfiram
umas nas outras — ou seja, evitar que as mudanças feitas por
Roberto em C sobrescrevam as de Alice, ou vice-versa.
✓ Para apoiar o desenvolvimento independente sem
interferências, todos os sistemas de controle de versão usam o
conceito de um repositório de projeto e de uma área de
trabalho particular.
✓ O repositório do projeto mantém a versão ‘mestre’ de todos os
componentes, que é utilizada para criar as baselines para a
construção do sistema.
✓ Ao modificar componentes, os desenvolvedores copiam (fazem
check-out) esses componentes do repositório em sua área de
trabalho e trabalham nessas cópias. Após concluírem as suas
alterações, os componentes modificados são devolvidos (faz-
se check-in) para o repositório.

7
Clonagem do Repositório
•Em um sistema de controle de versão distribuído, como o Git, uma
abordagem diferente é usada. Um repositório ‘mestre’ é criado em um
servidor, que mantém o código produzido pelo time de
desenvolvimento.
•Em vez de simplesmente fazer o check-out dos arquivos de que
precisa, um desenvolvedor cria um clone do repositório do projeto,
que é baixado e instalado em seu computador. Os desenvolvedores
trabalham nos arquivos necessários e mantêm as novas versões em
seu repositório particular, em seu próprio computador.
•Quando terminam de fazer alterações, eles ‘efetivam’ (commit) essas
alterações e atualizam seu repositório privado. Eles podem, então,
‘enviar’ (push) essas alterações para o repositório do projeto ou dizer
ao gerente de integração que as versões modificadas estão
disponíveis, que pode então ‘puxar’ (pull) esses arquivos para o
repositório do projeto.
•Nesse exemplo, Roberto e Alice clonaram o repositório do projeto e
têm arquivos atualizados. Eles ainda não enviaram esses arquivos de
volta para o repositório do projeto.

8
 Vantagens Modelo Distribuído
Esse modelo de desenvolvimento tem uma série de vantagens:
1. Ele fornece um mecanismo de backup para o repositório. Se o
repositório estiver corrompido, o trabalho pode continuar, e o
repositório do projeto pode ser restaurado a partir de cópias
locais.
2. Ele permite o trabalho off-line para que os desenvolvedores
possam efetivar (commit) as alterações se eles não tiverem uma
conexão de rede.
3. O apoio ao projeto é a maneira padronizada de trabalhar. Os
desenvolvedores podem compilar e testar todo o sistema em suas
máquinas locais e testar as alterações que eles fizeram.

9
 Consequências
• Uma consequência do desenvolvimento independente do mesmo
componente é que os codelines podem se ramificar. Em vez de
uma sequência linear de versões, que refletem as alterações no
componente ao longo do tempo, pode haver várias sequências
independentes, conforme a Figura a seguir.
• Isso é normal no desenvolvimento de sistemas, pois diferentes
desenvolvedores trabalham independentemente em versões
diferentes do código-fonte e o alteram de maneiras diferentes.
• Em geral, quando se trabalha em um sistema, é recomendável que
uma nova ramificação (branch) seja criada, para que as alterações
não afetem acidentalmente um sistema que está funcionando.

10
Ramificação (branch) e fusão (merge)

Em algum momento, talvez seja

necessário fundir (merge)
ramificações de código para criar
uma versão nova de um
componente que inclua todas as
alterações feitas.
Isso também é mostrado na
Figura, em que as versões de
componente 2.1.2 e 2.3 são
fundidas para criar a versão 2.4.

11
 Gerenciamento de armazenamento usando deltas
▪Quando uma nova versão é criada, o sistema
simplesmente armazena um delta, uma lista
de diferenças entre a nova versão e a versão
mais antiga usada para criar a nova.
▪Os deltas geralmente são armazenados
como listas de linhas alteradas e, aplicando-as
automaticamente, uma versão de um
componente pode ser criada a partir de outra.
▪Como a versão mais recente de um
componente provavelmente será a utilizada, a
maioria dos sistemas armazena essa versão
na íntegra. Então, os deltas definem como
recriar versões anteriores do sistema.
▪Um dos problemas com a abordagem é que
▪Como hoje o armazenamento em disco é relativamente barato, o Git usa uma abordagem pode levar muito tempo para aplicar todos os
alternativa mais rápida. deltas.
▪O Git não usa deltas, mas aplica um algoritmo de compressão padrão nos arquivos
armazenados e em sua metainformação associada. A abordagem não armazena cópias
duplicadas de arquivos. A recuperação de um arquivo simplesmente envolve sua
descompactação, sem necessidade de aplicar uma cadeia de operações.
▪O Git também usa a noção de packfiles, em que vários arquivos menores são combinados
em um arquivo indexado único. Isso reduz a sobrecarga associada a vários arquivos
pequenos. Os deltas são usados dentro de packfiles para reduzir ainda mais o seu tamanho. 12
 Questão 1
Ano: 2019 Banca: FCC Órgão: Prefeitura de Manaus - AM Prova: FCC - 2019 - Prefeitura de Manaus -
AM - Assistente Técnico de Tecnologia da Informação - Programador
No repositório SVN, o comando usado para criar uma cópia de trabalho do repositório para poder
editar é o:
a) CHECKOUT.
b) DIFF.
c) PERFORM.
d) COMMIT.
e) UPDATE.

13
 Questão 1
Ano: 2019 Banca: FCC Órgão: Prefeitura de Manaus - AM Prova: FCC - 2019 - Prefeitura de Manaus -
AM - Assistente Técnico de Tecnologia da Informação - Programador
No repositório SVN, o comando usado para criar uma cópia de trabalho do repositório para poder
editar é o:
a) CHECKOUT.
b) DIFF.
c) PERFORM.
d) COMMIT.
e) UPDATE.

Justificativa:
checkout, co - Create a local working copy of a remote repository

14
 Questão 2
Ano: 2019 Banca: FCC Órgão: SEMEF Manaus - AM Prova: FCC - 2019 - SEMEF Manaus - AM - Técnico em Web
Design da Fazenda Municipal
Um Técnico em Web Design tem a incumbência de verificar a possibilidade de uso de um Gerenciamento de
Repositório (SVN), sendo que em sua pesquisa esse técnico verificou que, nesse repositório, a operação de
a) salvar no repositório mudanças feitas em uma cópia de trabalho, corresponde à operação
denominada commit.
b) criar um repositório corresponde à operação de checkout.
c) descartar modificações feitas no repositório corresponde à operação denominada status.
d) sincronizar uma cópia de trabalho com o repositório corresponde a uma operação de revisão.
e) criar uma cópia de trabalho, a partir do repositório, corresponde à operação denominada commit.

15
 Questão 2
Ano: 2019 Banca: FCC Órgão: SEMEF Manaus - AM Prova: FCC - 2019 - SEMEF Manaus - AM - Técnico em Web
Design da Fazenda Municipal
Um Técnico em Web Design tem a incumbência de verificar a possibilidade de uso de um Gerenciamento de
Repositório (SVN), sendo que em sua pesquisa esse técnico verificou que, nesse repositório, a operação de
a) salvar no repositório mudanças feitas em uma cópia de trabalho, corresponde à operação
denominada commit.
b) criar um repositório corresponde à operação de checkout.
c) descartar modificações feitas no repositório corresponde à operação denominada status.
d) sincronizar uma cópia de trabalho com o repositório corresponde a uma operação de revisão.
e) criar uma cópia de trabalho, a partir do repositório, corresponde à operação denominada commit.

Justificativa:
SVN commit, ci - Commit (check in) local changes to the repository.

16
 Questão 3
Ano: 2018 Banca: CCV-UFC Órgão: UFC Prova: CCV-UFC - 2018 - UFC - Analista de Tecnologia da Informação
O Git é um sistema de controle de versão distribuído gratuitamente e de código aberto projetado usado, principalmente, no
desenvolvimento de software. Sobre o Git o que é correto afirmar?
a) O Git não suporta commits em vários branches.
b) O comando git stash retorna o repositório ao HEAD.
c) O comando git checkout é utilizado para desfazer alterações, mesmo que o arquivo tenha sido adicionado na staged area.
d) Use git merge quando quiser gravar o estado atual do diretório de trabalho e do índice, mas quiser voltar para um
diretório de trabalho limpo.
e) O comando git add armazena o conteúdo atual do índice em um novo commit junto com uma mensagem de log do
usuário descrevendo as alterações.

17
 Questão 3
Ano: 2018 Banca: CCV-UFC Órgão: UFC Prova: CCV-UFC - 2018 - UFC - Analista de Tecnologia da Informação
O Git é um sistema de controle de versão distribuído gratuitamente e de código aberto projetado usado, principalmente, no
desenvolvimento de software. Sobre o Git o que é correto afirmar?
a) O Git não suporta commits em vários branches.
b) O comando git stash retorna o repositório ao HEAD.
c) O comando git checkout é utilizado para desfazer alterações, mesmo que o arquivo tenha sido adicionado na staged area.
d) Use git merge quando quiser gravar o estado atual do diretório de trabalho e do índice, mas quiser voltar para um
diretório de trabalho limpo.
e) O comando git add armazena o conteúdo atual do índice em um novo commit junto com uma mensagem de log do
usuário descrevendo as alterações.

Justificativa:
O Git não suporta commits em vários branches.
- Certa, o Git Não suporta um commit simultâneo em várias branches.
O comando git stash retorna o repositório ao HEAD.
- Errada, o comando git stash armazena as modificações temporárias, mas não altera o HEAD.
O comando git checkout é utilizado para desfazer alterações, mesmo que o arquivo tenha sido adicionado na staged area.
- Errada. Quando o arquivo foi adicionado na staged area (após ter sido utilizado o comando git add), é necessário o comando git reset para reverter e não checkout.
Use git merge quando quiser gravar o estado atual do diretório de trabalho e do índice, mas quiser voltar para um diretório de trabalho limpo.
- Errada, o comando merge serve para unir duas branches, podem haver conflitos durante, e ele irá até o diretório atual, e não a um diretório de trabalho limpo.
O comando git add armazena o conteúdo atual do índice em um novo commit junto com uma mensagem de log do usuário descrevendo as alterações.
- Errada. O comando descrito é o git commit, o git add apenas adiciona as alterações para a staging area.
18
 Lista de Comandos
• SVN - https://openoffice.apache.org/svn-basics.html

19
 Lista de Comandos
• GIT - https://git-scm.com/docs

20
 Gabarito

Questão Resposta
1 LETRA A
2 LETRA A
3 LETRA A

21
22
 Referências

• PRESSMAN, Roger S. ; Bruce R. Maxim. Engenharia de Software, Uma Abordagem Profissional, 8° ed.
Porto Alegre: AMGH, 2016. ISBN 978-85-8055- 533-2.
• SOMMERVILLE, Ian. Engenharia de Software, 9. ed. São Paulo: Pearson Prentice Hall, 2011. ISBN 978-
85-7936-108-1.

23