introdução a sistemas de controle de versão git

08 e 09 de Dezembro de 2016

Nome: Fabian Cesar Pereira Brandão ManoelE-mail: [email protected]

INTRODUÇÃO A SISTEMAS CONTROLE DE VERSÃO: GIT

OUTLINE 1.0. Introdução a sistemas de controle de

versão (CVS)

2.0. Introdução ao GIT

3.0. Conclusão

4.0. Referência bibliográfica

OUTLINE1.0. Introdução a sistemas de controle de versão(CVS)

1.1. O que é Controle de versão1.2. Local

1.3. Centralizado1.4. Distribuído

4Introdução a sistemas de controle de versões: GIT

1.1. O que é Controle de versão

•Sistema que registra as mudanças feitas em arquivos permitindo:

•a recuperação de versões específicas sempre que solicitado;

•a comparação sobre as modificações feitas;

•Conhecer quem, o que , como e quando alterou os arquivos;

•Existem 3 tipos de Sistemas de controle de versão:

1.0. INTRODUÇÃO A SISTEMAS DE CONTROLE DE VERSÃO


1.2. Local

•Todo o controle de versionamento é feito de forma local. Ideal para projetos individuais.



1.3. Centralizado

•Todo o controle de versionamento é feito de forma centralizada. Este método utiliza um servidor central que contém o controle de versão. É deste servidor que outros computadores terão acesso aos arquivos e suas versões.




1.4. Distribuído

•Todo o controle de versionamento é feito de forma distribuída. Este método faz com que todos os envolvidos no projeto possuam clones de todos os arquivos e suas versões.

OUTLINE2.0. Introdução ao GIT

2.1. Contextualizando2.2. Filosofia

2.3. Manuseio de arquivos e ferramenta

2.4. Meu primeiro projeto2.5. Repositório remoto


2.0. INTRODUÇÃO AO GIT2.1. Contextualizando


2.0. INTRODUÇÃO AO GIT2.1. Contextualizando

•GIT é um sistema de controle de versão distribuído que, para atingir seus objetivos, monitora arquivos de forma diferente de qualquer outro sistema. Vamos entender melhor:


2.2. Filosofia

2.0. INTRODUÇÃO AO GIT

•2.2.1. Fluxo de instantâneos•2.2.2. Operações locais•2.2.3. Integridade GIT•2.2.4. Estados e Seções•2.2.5. Principais comandos


2.2.1. Fluxo de instantâneos


•Outros sistemas de controle de versão pensam nas informações como uma lista de mudanças a serem armazenadas;


2.2.1. Fluxo de instantâneos


•Já o GIT funciona como um fluxo de instantâneos, ou seja, ele apenas “fotografa” a versão salva e associa a esta sempre uma referência de busca.


2.2.2. Operações locais


Por ser um Sistema de controle de versão distribuído, os locais envolvidos possuem suporte GIT, podendo clonar projetos do servidor. Com isso, ganha-se em velocidade em seus processos.


2.2.3. Integridade GIT


•GIT realiza um conjunto de somas para que, quando os arquivos forem armazenados, seja gerado uma sequência de 40 caracteres Hexadecimais através do mecanismo hash SHA-1. Este mecanismo está presente em toda integridade GIT. Segue o exemplo:


2.2.3. Integridade GIT


•OBS: Este mecanismo garante que o GIT entenderá as diferenças entre arquivos. Como padrão de Sistemas de controle de versão, o

GIT geralmente só adiciona dados, dificultando as chances de perda de arquivos.


2.2.4. Estados e seções


•Seus arquivos residem em 3 estados:

•(ou Commited). Arquivos já estão salvos na área GIT.

•(ou Modified). Arquivos foram modificados mas não se encontram na área GIT.

•(ou Staged). Arquivos foram selecionados e estão prontos para tornarem-se comprometidos.




•Isso nos leva a três seções de um projeto GIT:




•Para gerenciar os repositórios, o GIT disponibiliza 3 IDEs:•CMD

•GUI




•BASH


2.4. Meu primeiro projeto


ATRAVÉS DO GIT BASH, ENCAMINHE-SE AO DIRETÓRIO QUE DESEJA IMPOR A GERÊNCIA GIT.




E ENTÃO INICIE A GERÊNCIA GIT ATRAVÉS DO SEGUINTE COMANDO:

E VEJA QUE O GIT INSTALA O DIRETÓRIO OCULTO .git, QUE IRÁ PERMITIR QUE O GIT FAÇA SEU TRABALHO.




ENTÃO, CRIA-SE NESSE DIRETÓRIO UM PROJETO QUE DEVE SER ENCAMINHADO AO CLIENTE.

VERIFICA-SE, ENTÃO, O STATUS DO REPOSITÓRIO:

E PERCEBE-SE QUE O ARQUIVO ESTÁ NA ÁREA DE TRABALHO E NÃO É RECONHECIDO PELO GIT.

NOTE QUE O PROJETO JÁ POSSUI UM RAMO PADRÃO. ESTE CAMPO INDICA EM QUE RAMO SEU REPOSITÓRIO ESTÁ ATUANDO.




PARA ENVIAR O ARQUIVO AO CONTROLE GIT, ESTE PRECISA ESTAR NA STAGING AREA (ÁREA DE ESPERA OU PREPARAÇÃO). PARA ISSO USA-SE O COMANDO:

•git add . : ADICIONA TODOS OS ARQUIVOS DA ÁREA DE TRABALHO;•git add *.<formato>: ADICIONA TODOS OS ARQUIVOS DO FORMATO

DESEJADO;•git add <arquivo>.<fotmato>: ADICIONA APENAS O ARQUIVO DESEJADO.

AO CONSULTAR O STATUS NOVAMENTE:




AGORA QUE OS ARQUIVOS ESTÃO PREPARADOS, SERÁ FEITO O PRIMEIRO COMMIT:

COMMIT EFETUADO.

O PROJETO PROSSEGUIU E FOI INTERESSANTE GUARDAR MAIS 2 MOMENTOS DO PROJETO NO GIT, OU SEJA, REALIZAR 2 COMMITS.




ESTE É O ESTADO ATUAL DO PROJETO DESTINADO A UM CLIENTE.




FOI PRECISO TESTAR UMA IMPLEMENTAÇÃO FORA DO PLANEJAMENTO. NESTE CASO,

CRIAMOS UM NOVO RAMO CHAMADO iss53. A SEGUIR O COMANDO E O STATUS DO MEU

REPOSITÓRIO:

HEAD




HEAD

NESTE REPOSITÓRIO, FOI FEITO UM NOVO COMMIT. VEJA O QUE

ACONTECE.




É PRECISO IMPLEMENTAR UMA SOLICITAÇÃO NOVA DO CLIENTE.

HEAD




HEADCLIENTE APROVOU A

IMPLEMENTAÇÃO E PEDIU PARA ADICIONÁ-LA AO PROJETO.

NESTE CASO, USA-SE O CONCEITO MERGE.




RETORNO ENTÃO À IMPLEMENTAÇÃO PESSOAL E FAÇO

UM NOVO COMMIT.

HEAD

REPARE QUE, COMO O RAMO master PASSOU A APONTAR PARA O MESMO COMMIT QUE O RAMO hotfix, ESTE PODERÁ SER APAGADO.




FOI APRESENTADO AO CLIENTE E ESTE APROVOU. PEDIU PARA A IMPLEMENTAÇÃO FAZER PARTE DO

PROJETO.

HEAD

APLICA-SE O MERGE. MAS NESSE CASO, O COMMIT C4 NÃO É UM ANCESTRAL DO

COMMIT C5.




REPARE QUE NESTE CASO UM NOVO COMMIT É FEITO E ESTE NOVO PASSA A TER DOIS COMMITS DE ORIGEM (C4 E C5).

HEAD




COM OS OBJETIVOS INICIAIS DO PROJETO DEVIDAMENTE ATINGIDOS, ENTREGAREMOS AO CLIENTE. MAS ATENÇÃO! POR QUESTÕES DE SEGURANÇA, RECOMENDA-SE APLICAR UMA TAG À ESSA VERSÃO.

HEADV1.0.0


2.5. Repositório remoto


O conceito de reposirórios remotos permitem que equipes possam trabalhar dinamicamente, pois o projeto e suas versões passam a ser alocados em locais de acesso múltiplo. Assim, é possível que,qualquer pessoa com acesso àquele repositório possa contribuir com o mesmo.




REPOSITÓRIO REMOTO

LOCAL 1 LOCAL 2 LOCAL N




Dois repositórios remotos se destacam:




Alguns conceitos cercam a utilização de repositório remoto. São eles:

REMOTE: seu primeiro contato com repositório remoto deve especificar um nome e a url para este repositório. Veja como é feito.





CLONE: este conceito cria um repositório local clonado do repositório remoto que é destacado por você. Ao fazer um Clone, já é criado um repositório padrão no git, chamado origin com a url do projeto clonado. Veja o comando usado.





PUSH: este conceito realiza uma entregado repositório local para o remoto. Após a realização de todas as modificações feitas localmente, com os commits já definidos, está na hora de atualizar o repositório remoto com as suas modificações. Indicando o nome do repositório remoto e o ramo a ser passado, veja como se dá o commando:





FETCH: este conceito pega todos dados que o seu repositório local ainda não tem. Assim, você terá todas as referências possíveis para juntar os novos dados aos atuais (Merge). Veja como se faz:





PULL: este conceito realiza a captura dos dados não obtido (fetch), além de realizer o merge, o que permite que seu projeto seja atualizado em relação ao repositório remoto. Após a atualização de um projeto no repositório remoto (imagine que alguem fez um Push), é preciso atualizar o repositório local com as modificações feitas. Veja como usar io Pull.


3.0. CONCLUSÃO

Através das aplicações aqui mostradas, é possível constatar que, uma vez que usa-se controle de versão distribuído em projetos, ganha-se em tempo, organização e facilidade de implementação em equipe, uma vez que quaisquer membros atuantes têm acesso aos arquivos ali contidos. O GIT é uma ferramenta eficiente, pois sua filosofia de gerenciamento de arquivos torna ainda mais rápido e facilitado o andamento de um projeto de grande porte.


4.0. REFERÊNCIAS BIBLIOGRÁFICAS

• GIT. Documentation [online]. 2014. Referência disponível em https://git-scm.com/doc;• William Oliveira [online]. Referência disponível em https://woliveiras.com.br/posts/contribuindo-para-projetos-open-source-no-github-mesmo-sendo-iniciante/• Atlassian BitBucket [online]. Referência disponível em https://bitbucket.org/product

https://git-scm.com/doc

https://git-scm.com/doc

https://woliveiras.com.br/posts/contribuindo-para-projetos-open-source-no-github-mesmo-sendo-iniciante/

https://woliveiras.com.br/posts/contribuindo-para-projetos-open-source-no-github-mesmo-sendo-iniciante/

48Introdução ao Arduino: fundamentos e aplicações de microcontroladores

AGRADECIMENTOS

[email protected]

[email protected]@gmail.com

introdução a sistemas de controle de versão git

Software