GIT Controlo de versões

Transcrição

1 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES GIT Controlo de versões O GIT tem duas vantagens essenciais: Faz o controlo de versões Permite coordenar o desenvolvimento simultâneo dos vários elementos de uma equipa, gerindo conflitos Um repositório central guarda as várias versões dos documentos criados Pode ser baseado num servidor web, uma base de dados (Berkeley DB), ou simplesmente um conjunto de diretórios Cada elemento da equipa trabalha sobre uma cópia local (no seu computador) do projeto Quando apropriado, faz refletir as alterações no repositório

2 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES O que é o controlo de versões São criadas versões sucessivas dos documentos Quando necessário, pode-se recuperar uma versão anterior

3 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Três níveis Working tree: ficheiros que estão a ser editados Staging area, index: marcados para serem guardados no repositório

4 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Estados dos ficheiros Operações mais frequentes: Add / Stage / Commit

5 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Trunk, branches e tags Trunk Sequência de desenvolvimento principal Branches Variantes paralelas à sequência de desenvolvimento principal Adaptações para clientes diferentes Trabalho de grupos em paralelo, para evitar updates complexos e frequentes Tags Registo de pontos importantes no desenvolvimento Versões de produção (públicas)

6 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Repositório local e central clone push pull... Repositório central (GitHub, p.ex.) Repositório local Repositório local Repositório local stage commit branch merge tag... Eclipse Eclipse Eclipse

7 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Sequência de trabalho normal (1) Criar uma cópia de trabalho atualizada, a partir do repositório central (clone, checkout). Esta passa a ser a revisão BASE Atualizar o repositório local com as nossas alterações, quando apropriado, formalizando uma nova versão (commit) Ao atualizar o repositório, podem ser detetadas inconsistências com alterações feitas por outros elementos da equipa; podem ter que ser resolvidas à mão, uma a uma A versão mais recente do repositório é chamada a revisão HEAD

8 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Head, master e origin Head o commit corrente do repositório da máquina local para onde o meu repositório está a apontar Master nome do branch criado pelo Git ao criar um repositório frequentement significa main branch Origin nome dado pelo Git ao repositório central (remoto) Head é um nome oficializado no Git, master e origin são nomes usados frequentemente, mas não são obrigatórios

9 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Sequência de trabalho normal (2) Atualizar os ficheiros de trabalho quando adequado, para refletir na cópia de trabalho as alterações feitas no repositório central por outros elementos da equipa (pull) Atualizar o repositório central com as nossas alterações, quando apropriado (push) Ao atualizar o repositório, podem ser detetadas inconsistências com alterações feitas por outros elementos da equipa; podem ter que ser resolvidas à mão, uma a uma

10 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Sequência típica branch e tag Sequência típica Os commits são feitos nas versões trunk; inclui novo código, correção de bugs, etc. Quando a equipa entende que uma versão está a ficar pronta, o trunk é copiado para um branch. O trunk é copiado por exemplo para um branch 1.0 Duas equipas continuam a trabalhar em paralelo. Uma equipa faz os testes rigorosos do branch 1.0, e a outra continua o desenvolvimento (por exemplo para a futura versão 2.0). Quaisquer bugs descobertos numa das versões devem ser corrigidos em ambas Quando terminarem os testes, a versão de software é distribuída, sendo criado o tag 1.0.0, que fica como referência do que foi entregue aos clientes O trabalho no branch 1.0 pode continuar, com pequenos melhoramentos ou correção de bugs; se apropriado, o branch 1.0 pode dar origem a um tag 1.0.1

11 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Comandos mais usados (1) Commit: para fazer refletir no repositório as alterações feitas na cópia de trabalho Ao fazer commit é criada uma nova versão do projeto Deve-se escrever um comentário que seja sugestivo e permita identificar facilmente esta versão Pull: para atualizar a cópia de trabalho com as alterações feitas por outros no repositório central, fazendo merge e commit Update to revision / switch: para mudar a cópia de trabalho, passando a trabalhar com uma dada revisão

12 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Comandos mais usados (2) Branch: para criar uma nova sequência de desenvolvimento. Os updates e commits só afetam o branch em que estamos a trabalhar. Merge: para importar para a cópia de trabalho as alterações feitas por outros utilizadores ou em outros branches Tag: para criar uma imagem do projeto (uma fotografia do estado atual). Pode ser por exemplo uma versão do projeto que vai ser enviada para um ou mais clientes Revert: para anular as alterações feitas e regressar a uma versão BASE

13 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Push e pull (1) other master clone: commit local: remotes/origin/other master remotes/origin/master remotes/origin/other master remotes/origin/master push: remotes/origin/other master remotes/origin/master

14 Universidade Portucalense Engenharia de Software ES Universidade Portucalense Engenharia de Software ES Push e pull (2) Fazemos push e depois outro programador P tenta fazer push; o server não permite; então para atualizar, P tem que primeiro fazer pull para incluir o nosso commit e só depois fazer push pull: remotes/origin/other master remotes/origin/master agora P pode fazer push para atualizar o repositório central; se fizermos pull, incluimos o commit do outro programador