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) Unmodified ou Commited (no Working Directory ou Git Directory) Modified (no Working Directory) Staged (na Staging Area) git add Editar ficheiro git add (stage ficheiro) git commit git remove
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]!lib.a /file1 dir1/ # ignora ficheiros *.o ou *.a # não ignora lib.a # ignora o ficheiro file1 se está na raiz # 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 pull dos 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 $git remote v lista os repositórios remotos 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 / A---B---F---G origin (repos. remoto) 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 - Merge Se o merge é resolvido como um fast-forward só atualiza o apontador do branch, sem criar um commit de merge. / A---B C---D---E origin (repos. Remoto) master (repos. Local) $git merge --abort Só 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