Iniciando no GIT – Parte 1

Não esqueça de ler a segunda parte desse artigo. Se você não trabalha com nenhum controle de versão ainda ou nem sabe o que isso significa, dá uma lida nesse texto antes de começarmos aqui. Controles de versão são sistemas que controlam o código gerado em projetos. Se você e mais alguém precisam editar o

Não esqueça de ler a segunda parte desse artigo.

Se você não trabalha com nenhum controle de versão ainda ou nem sabe o que isso significa, dá uma lida nesse texto antes de começarmos aqui.

Controles de versão são sistemas que controlam o código gerado em projetos. Se você e mais alguém precisam editar o mesmo arquivo em um mesmo projeto, como você faz? Espera o primeiro editar, salvar e depois subir no FTP só para aí então você abrir o arquivo e fazer suas alterações?

Esse cenário se repete em muitas empresas, de todos os tamanhos. Os controle de versão ajudam a resolver esse e outros problemas de gerenciamento de código e organização. Um dos controles de versão mais conhecidos é o GIT.

Git é um sistema de controle de versão distribuído com ênfase em velocidade. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux. – Wikipedia, GIT

Como funciona o GIT?

Normalmente a maioria dos controles de versão guardam as mudanças do código como alterações de um determinado arquivo. Ou seja, a cada mudança no arquivo, o sistema guarda essa mudança apenas e não o arquivo inteiro.

O Git pensa um pouco diferente: ele trata os dados como snapshots. Cada vez que commitamos (commitar é enviar alterações para o controle de versão) ou salva o estado do projeto no Git, ele basicamente guarda um snapshot de como todos os arquivos estão naquele momento e guarda a referência desse estado. Para os arquivos que não foram modificados, ele não guarda uma nova versão, ele apenas faz um link para a versão anterior idêntica que já foi guardada em outro momento.

Esta imagem vem direto do GitHub. Fica mais fácil entender como ele atrela um commit no outro usando snapshots.

Áreas de operação

Os locais de operação são as áreas onde os arquivos irão transitar enquanto estão sendo editados e modificados. São 3: Working Directory, Stage Area, Git directory.

O Git Directory é onde o Git guarda os dados e objetos do seu projeto. Ele é o diretório mais importante do Git e é ele que será copiado quando alguém clonar (clonar é copiar o projeto para a sua máquina) o projeto.

O Work Directory é onde você vai trabalhar. Os arquivos ficam aí para poderem ser usados e alterados quantas vezes quiser para você. É basicamente sua pasta de arquivos dos projeto.

Quando você faz uma alteração em algum arquivo, ele vai para o Staging Area, que é uma área intermediária. Basicamente o Staging Area contém o Git Directory com os arquivos modificados, onde ele guarda as informações sobre o que vai no seu próximo commit. Veja a imagem abaixo direto do site do Git.

Instalando o Git

Se você tem Windows baixe o EXE direto deste link e instale.

Ele vai instalar para você os comandos do Git para serem usados no terminal e uma uma interface padrão para quem não está acostumado a usar linhas de comando.

No Mac você tem vários caminhos, baixando o installer, usando Macports:

E até mesmo usando Brew.

Com Linux eu preciso falar? 😉

Yum.

Ou apt-get.

Configurando suas informações

A primeira coisa que você deve fazer depois de instalar o Git é definir seu usarname e email. Isso é importante por que os seus commits usarão essas informações para identificar o autor das mudanças. Pois é… Se alguém fizer alguma merda no projeto e quebrar todo o sistema, é possível saber quem, quando e qual linha foi o autor do apocalipse.

É simples, no terminal escreva:

Controlando um projeto

Pelo terminal mesmo, entre na pasta do projeto que você quer iniciar o controle e use o comando:

Esse comando vai criar um diretório invisível dentro do projeto chamado .git. Ele contém todos os arquivos necessários do seu repositório. Aqui, neste ponto, nada dos seus arquivos ainda estão sendo controlados. Você apenas criou um “lugar” (branch) para o Git colocar os arquivos.

O próximo comando vai inserir os arquivos que você quer controlar. Normalmente a gente controla TUDO o que está no projeto. Mas isso tem que ser combinado com a equipe antes. Em um projeto que envolve um CMS com o WordPress, por exemplo, é normal controlar tudo, até os arquivos do WordPress. Mas se em um projeto você guarda pastas de layouts, pastas de wireframes, protótipos e etc, é interessante não colocar isso no Git. Mas aí vai de equipe para equipe, de projeto pra projeto.

O comando para adicionar os arquivos é:

Para você ver o status, use o comando git status, aí você verá tudo o que foi incluído no projeto. Veja o screenshot abaixo para ter uma ideia:

Feito isso você vai precisar inserir seu primeiro commit. Vamos dar mais detalhes sobre o comando commit no próximo artigo, por agora fique com essa linha:

Agora você mandou uma alteração para o Git.

Clonando um projeto

Pode ser que já exista um projeto no Git criado e você só precise clonar para seu computador. Para isso você vai usar o comando git clone.

Quando você clona um projeto, o Git recebe a cópia de todos os dados que tem no servidor. Cada versão de cada arquivo da história inteira do projeto é puxada quando você roda o comando git clone.

Para clonar um projeto você precisa ter a URL do Git daquele projeto em específico. O comando completo fica mais ou menos assim:

Pode testar com o endereço acima. Ele é nosso diretório do Git de exemplos no GitHub.

No próximo artigo a gente mostra os comandos commit, push e pull.

Veja um vídeo que mostra os comandos básicos do GIT:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *