O
pai ta on!!
Já
falamos sobre os motivos que motivaram Linus a criar o GIT, e mostramos uma
comparação entre os repositórios de códigos. Hoje iremos colocar a mão na
massa, para iniciarmos nossos projetos com o GIT.
Para
sermos democráticos, vou mostrar a criação de novos projetos/repositórios nas
3(três) ferramentas (GitLab, GitHub e CodeCommit).
GitLab
Depois
de fazer o login no site (https://gitlab.com),
existirá algumas opções de ações (caso não existam projetos criados), ou
podemos clicar no botão com símbolo de soma (+) e escolher ‘New Project’. Nesse
exemplo utilizaremos repositórios/projetos públicos, logo escolha essa opção.
GitHub
Indo
no mesmo sentido do GitLab, também é possível criar novos repositórios públicos
no github (https://github.com), de forma bem
similar clique no botão com o símbolo de soma (+), e escolha “New repositor”,
com uma diferença: escolha a criação do README na criação do projeto.
CodeCommit
Por fim no CodeCommit, é necessário estar logado na conta AWS, e o processo é mais simples, bastando apenas clicar em “Create repository”, e passar o nome.
Estrutura do projeto
Com
os repositórios criados, vamos iniciar a mão-na-massa de fato com o GIT.
Antes
de tudo é necessário instalar o git com gerenciador de pacotes de sistema
operacional que estiver utilizando (apt, yum e etc).
Caso
esteja utilizando Windows, gosto do combo MobaXterm + Git (https://mobaxterm.mobatek.net/download.html),
contudo também é possível instalar o git de forma direta (https://git-scm.com/downloads).
Com
o git instalado vamos criar uma estrutura de pastas para trabalharmos nos
próximos artigos:
Cada
pasta secundária vai ser de um repositório, e dentro do GitLab teremos nosso projeto
principal. Nesse projeto teremos duas pessoas trabalhando em paralelo o sagara
e o thiago.
Note
que em nossos exemplos criamos repositórios públicos, que são opções onde
qualquer pessoa pode contribuir com o projeto. Quando utilizamos a opção privada,
apenas o dono e/ou convidados podem ter acesso aos arquivos.
Com a estrutura feita localmente, e o projeto criado no repositório vamos avançar.
Git Config
A
primeira ação que tomaremos é colocar nossa identificação nas configurações do
GIT. Isso é importante, pois os commits utilizam dela para identificação,
ajudando assim na organização e timestamp dos logs.
Para
isso vamos utilizar o comando:
git config –global user.name “Thiago Marques”
git config –global user.email
thiagosagara@gmail.com
Existem
outras opções que podem ser habilitadas que gosto de trabalhar, que ajudam em
tshoots e análises.
git config –global color.status auto
git config –global color.branch auto
git config –global color.diff auto
E por fim a última opção que vamos habilitar no laboratório serve para armazenar as credenciais utilizadas, assim não vai ser necessário passar as credenciais do repositório todas as vezes que formos fazer um push
git config –global credential.helper store
Podemos validar as configurações direto no arquivo (~/.gitconfig), ou via comando com:
git config -l
Git Init
O
comando git init é onde de fato as coisas começam. Com ele, criamos um
repositório local, ou seja, começamos a criar versões todos os arquivos
que estão dentro do diretório.
Note
que não precisamos necessariamente de um repositório para começar a trabalhar
com o git, ele pode ser usado de forma offline.
Com
o init, o git vai criar um subdiretório. git no diretório, que armazenará
metadados, referencias, templates e um arquivo HEAD (que basicamente é uma referência
ao commit atual.
Tenha sempre em mente que o init serve para INICIAR um repositório, é diferente do git clone, que clona (genius…) um repositório existente, assim o clone, depende de um init.
Git Add
Logo
após iniciarmos o repositório já podemos adicionar arquivos novos e/ou novas
versões de arquivos existentes, e isso é feito com o git add, que
basicamente adicionar o arquivo ao index do git.
Mais
detalhadamente o add, adiciona a alteração (ou inclusão) feita ao que
chamamos de área de staging (que seria uma localização temporária),
dizendo ao git que existem alterações que precisam de commit.
Se
pode adicionar os arquivos separadamente com o comando git add <arquivo>,
ou utilizar o “.” para adicionar todos
os arquivos.
Git Commit
Para
fechar temos o git commit, que tem a função de pegar os arquivos na área
temporária (staging) e passar para o repositório (local). Note que o commit
não envia os arquivos para o repositório remoto, isso é feito pelo comando push.
Essa
característica é algo que diferencia bem o Git de um SVN, uma vez que o commit
nesse sistema envia os dados para a central. Assim o Git garante que você
só envie os dados para o repositório principal (branch master) quando
estiver pronto para isso.
Na
utilização do commit, a documentação é obrigatória. Isso significa que
sempre será necessário adicionar um comentário referente ao commit. Isso
é feito utilizando o editor padrão (caso não se passe nenhum parâmetro), ou com
a opção “-m” se pode adicionar o comentário.
#abre
o editor padrão
git
commit
#envia o commit com o comentário (sem abrir o editor)
git
commit -m “[LOG] – Adicionado o sistema de logs”
Juntando tudo
Agora
vamos iniciar o projeto (com o init) e criar alguns arquivos no projeto
principal.
#Valida
as configurações
git
config -l
#cria
um arquivo
touch
index.html
#inicia
o projeto
git
init
#adiciona
os arquivos na área de staging
git add .
#commita os arquivos
git commit -m “[Blog] – Hello World”
No
próximo artigo veremos sobre logs, e como enviar os arquivos locais para o repositório
remoto.
That’s all folks! Be Happy!!!
thiago.marques@darede.com.br
Technical Account Manager da Darede, formato em Rede de Computadores, e pós graduado em Segurança da Informação. Possui ampla experiência em Datacenters e Service Providers, além de ser um entusiasta em DevOps e mercado financeiro.
