Controlo de versões com GIT

• Controlo de versões – é um sistema que grava mudanças

a um ficheiro ou conjunto de ficheiros, ao longo do

tempo, de modo a que possam ser invocadas versões

específicas mais tarde.

• Sistema de Controlo de Versões Local

• Sistema de Controlo de Versões Centralizado

• Sistema de Controlo de Versões Distribuído

• Sistema de Controlo de Versões Local:

• Copiar ficheiros para um diretório com data

• Guardar numa base de dados todas as mudanças a ficheiros.

• Exemplo: RCS (Revision Control System)

• Sistema de Controlo de Versões Centralizado:

• Um único servidor contém todos os ficheiros sob controlo de versões, e clientes fazem checkout desses ficheiros.

• Permite que utilizadores em diferentes sistemas colaborem entre si.

• Desvantagem: ponto único de falha.

• Exemplo: CVS, Subversion

• Sistema de Controlo de Versões Distribuído:

• Os clientes não só fazem checkout dos ficheiros existentes no servidor, mas também obtêm uma cópia completa do repositório.

• Exemplo: GIT, Mercurial

• Checkout – consultar, verificar, obter a última versão.

• Linus Torvalds

• O projeto do software do kernel do Linux, open source,

usou até 2005 o sistema de controlo de versões proprietário

Bitkeeper.

• Em 2005, Linus Torvalds, o criador do Linux, desenvolveu

o GIT para usar no projeto do kernel do Linux.

• A maior parte dos sistemas de controlo de versões guardam as mudanças efetuadas a cada ficheiro ao longo do tempo.

• Git guarda os ficheiros completos do projeto sempre que se faz commit, exceto se um ficheiro não mudou, Git guarda apenas um link ao ficheiro idêntico já guardado.

• Git funciona como um mini filesystem e guarda snapshots desse mini filesystem.

• No Git, a maior parte das operações são realizadas localmente porque só necessitam de ficheiros e recursos locais, e localmente existe o histórico completo do projeto.

• Para ver as diferenças entre a versão atual de um ficheiro e uma versão anterior, Git efetua a operação de cálculo das diferenças localmente, sem necessidade de acesso a um servidor remoto.

• Integridade

Tudo o que Git guarda é check-summed e passa a ser

referenciado pelo checksum.

O mecanismo de checksumming é SHA-1 hash, uma string de

40 carateres calculada com base no conteúdo do ficheiro.

• Configuração do Git

Git vem com uma ferramenta designada git config que permite configurar variáveis que controlam o modo de funcionamento do Git

• Configurar a nossa identidade:

$ git config --global user.name ”John Doe”

$ git config --global user.email johndoe@example.com

• Git escreve esta informação no ficheiro “.gitconfig” no diretório home

• Todos os commits efetuados usam esta informação

• Git escreve para este ficheiro se usarmos a opção --global

• Sem a opção --global git guarda no ficheiro .git\config do repositório local

As variáveis podem ser armazenadas em locais diferentes:

/etc/gitconfig

• Contém valores para cada utilizador do sistema e todos os seus repositórios.

• No Windows, debaixo do diretório onde se instala o Git.

.gitconfig

• No diretório home.

• Específico de cada utilizador.

• Git lê e escreve para este ficheiro usando a opção --global.

.git/config

• Ficheiro config no diretório .git de um repositório.

• Específico para esse repositório.

• Para usar um username ou email diferente num dado projeto devemos executar o comando git config sem a opção --global e posicionados no projeto.

Níveis mais específicos reescrevem valores de outros níveis.

$git config --list - lista todos os settings

$git config user.email - lista apenas um único valor

Um projeto Git tem 3 secções principais:

1) Working Directory

• O diretório de trabalho contém um único checkout de uma versão do projeto.É um conjunto de ficheiros extraídos da base de dados comprimida, existente no git directory, e colocados num diretório para serem usados e modificados.

2) Staging Area ou index

• A staging area ou index é um ficheiro único, geralmente contido no git directory, que guarda tudo o que vai no próximo commit.

3) Git Directory

• O git directory é onde o Git guarda a base de dados do projeto. É o que é copiado quando se efetua o clone de um repositório de outro computador.

Workflow básico do Git:

1. Modificámos os ficheiros no working directory

2. Fazemos o stage dos ficheiros, adicionando-os à staging area

• $git add .

3. Fazemos o commit que guarda permanentemente os

ficheiros da staging area no git directory.

• $git commit –m ’Versao inicial do projeto’

Workflow básico do Git:

Working Directory Staging Area

(Index)

Git Directory

(.git)

git add

(stage ficheiro)

git commit

git checkout

Criar um repositório GIT local:

1) Inicializar um repositório Git num diretório existente

• No diretório do projeto:

• $git init .

• Cria um subdiretório com o nome .git que contém um esqueleto de um repositório Git vazio.

• Para começar a controlar ficheiros existentes:

• $git add .

• $git commit –m ‘versao inicial do projeto’

2) Clone de um repositório existente

Git recebe uma cópia de todos os dados do servidor.

• $git clone git://github.com/user1/dir1.git

• §git clone https://bitbucket.org/user1/teste

Se quisermos criar um diretório com um nome diferente.

• $git clone git://github.com/user1/dir1.git dir2

Os 4 estados de um ficheiro:

1. Untracked• Os ficheiros no working directory poderão estar untracked ou tracked. Se

adicionarmos um ficheiro novo ao projeto, esse ficheiro fica no estado untracked e não é incluído no próximo commit, a não ser que se adicione explicitamente. É assim para que os ficheiros binários ou log gerados automaticamente não sejam incluídos.

• Para começar a controlar um novo ficheiro devemos usar o comando git add

2. Unmodified ou Commited• Se o ficheiro está no git directory ou então no working directory após checkout, mas

antes de ser editado.

• Após efetuar o clone de um repositório, os ficheiros no working directory estão todos tracked e unmodified, porque foi feito o checkout e ainda não foram editados.

3. Modified• Se o ficheiro foi checkedout e modificado no working directory.

4. Staged• Se foi modificado e adicionado à staging area.

• $ git add .

Ciclo de vida do estado dos ficheiros:

Untracked

(no Working

Directory)

Unmodifiedou

Commited(no Working Directory

ou Git Directory)

Staged

(na Staging Area)

git add

(stage ficheiro)

git remove

Modified

(no Working

Directory)

git add

Editar ficheiro

git commit

• Gravar Alterações do Projeto para o Repositório Local

• Fazemos alterações ao projeto e quando o projeto atinge um estado que pretendemos gravar efetuámos o commit.

$git status

• Lista:

Changes to be commited - ficheiros staged.

Changed but not updated - ficheiros tracked, modificados,

mas ainda não staged.

Untracked files - ficheiros fora do controlo de versões

Working directory clean - significa working directory sem untracked files e sem tracked files modified.

• Ver o histórico de Commits

$git log

• Lista os commits feitos no repositório por ordem

cronológica inversa.

• Ferrramenta gráfica para visualizar o histórico dos commits:

• $gitk

• Retirar ficheiro da área de staging

• $git reset HEAD ficheiro1

• Desfazer as modificações efetuadas no working directory

• $git checkout --ficheiro1

Ignorar Ficheiros

• Os ficheiros que pretendemos que o Git ignore, não sendo mostrados como untracked com o comando git status, tais como ficheiros gerados automaticamente, os seus nomes devem ser colocados no ficheiro .gitignore

• O ficheiro gitignore poderá conter padrões em que:

• Linhas em branco ou linhas começando por # são ignoradas.

• Padrões podem terminar por / para especificar um diretório.

• Começar por ! significa negar o padrão.

• Exemplos.

*.[oa] # ignora ficheiros *.o ou *.a

!lib.a # não ignora lib.a

/file1 # ignora o ficheiro file1 se está na raiz

dir1/ # ignora todos os ficheiros no diretório dir1/

Repositórios Remotos

Repositórios remotos são versões do nosso projeto alojadas na Internet.Para colaborar com outros utilizadores é necessário gerir repositórios remotos, fazer push e pulldos dados.

Quando efetuámos o clone de um repositório, Git dá-lhe o nome de origin(shortname). O nome completo é o Url.

$git remote lista os repositórios remotos

$git remote –v lista os repositórios remotos com os Urls

Adicionar repositórios remotos

• $git remote add [shortname] [url]

• Exemplo: $git remote add origin https://bitbucket.org/...

Fazer o fetch (ir buscar) e a seguir o merge (fundir) com o nosso branch corrente

• $git pull origin master

Fazer push (enviar) para o repositório remoto

• $git push [remote-name] [branch-name]

• Exemplo: $git push origin master

Repositórios Remotos - Merge

git merge incorpora no branch corrente as mudanças dos commits do branch remoto desde que as suas histórias divergiram.

C---D---E origin (repos. remoto)

/

A---B---F---G master (repos. local)

$git merge origin master

• Substitui as mudanças feitas no branch origin (remoto) desde que divergiu do branch master (i.e., desde B) até ao seu commit corrente (até E) em cima do branch master (local), e grava o resultado num novo commit.

• Este comando git merge é automaticamente executado quando se executa git pull.

• Se as mudanças no branch remoto e no branch local são feitas em ficheiros diferentes, ou então se são feitas no mesmo ficheiro mas em linhas diferentes, o merge é efetuado automaticamente assim como um novo commit com uma mensagem de merge.

• Se o merge falha (resultando em conflitos) o commit não é efetuado, para o utilizador poder editar o ficheiro resultante do merge.

Repositórios Remotos - MergeSe o merge é resolvido como um fast-forward só atualiza o apontador do branch, sem criar um commit de merge.

C---D---E origin (repos. Remoto)/

A---B master (repos. Local)

$git merge --abortSó pode ser executado depois do merge resultar em conflitos; aborta o processo de merge e tenta reconstruir o estado antes do merge.

Mudanças locais uncommited

• git pull e git merge abortam sem fazer qualquer alteração quando mudanças uncommited locais se sobrepõem com ficheiros que git pull ou git merge possam necessitar de atualizar.

Git – comandos úteis

Mudanças locais uncommited

• git reset –-hard coloca o working directory e o index igual ao

estado que estava no último commit, possibilitando fazer o pull sem

necessidade de fazer commit.

Outros comandos• git remote add origin https://bitbucket.org/...

• git clone https://bitbucket.org/...

• git add .

• git pull origin master

• git push origin master