Manual de Sobrevivencia:Git/GitHub    
Tags: github, git, java, braziliandevs
Published: 2021-06-25 22:10:26

100 em cada 100 desenvolvedores preferem utilizar o Git/GitHub para controle e hospedagem dos arquivos fontes(se você não leu o artigo anterior onde apresento e dou uma breve explicada sobre controle e versionamento de código corre lá [https://dev.to/rs_marinheiro/controle-de-versao-versionamento-de-codigo-1hg].
Criado por Linus Trovalds em 2005(isso mesmo o mesmo cara que criou o Linux) o git acabou se tornando a ferramenta de versionamento open-source mais utilizada por empresas e desenvolvedores ao redor do mundo, além de funcionar bem em várias IDEs ,Sistemas Operacionais, permite integração com softwares de terceiros como Jira por exemplo.
Este artigo tem como objetivo de apresentar ao leitor  esta poderosa ferramenta,de versionamento de código,e mostrar aos leitores comandos essenciais do dia a dia para quem deseja sair do ponto inicial.
   
Como já mencionamos no artigo anterior o Git trabalha de forma distribuída e por trabalhar de forma distribuída o git se divide em 4 áreas diferentes conforme podemos ver na figura abaixo:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/quedqvznla1qfnra302x.PNG)


Working Directory(Diretório Trabalho) : como o próprio nome já diz é o diretório onde você utiliza para trabalho, sem correr o risco de estragar nada, é como se você estivesse usando um localHost da vida para editar seus arquivos.

Stagging Area(Area de Estagiamento): é o cara que faz o meio de campo entre seu diretório local e o repositório local,é nessa área onde ficam os arquivos que estão aptos a serem salvos no repositório local.De forma análoga é como se estivéssemos usando esta área para colocar numa caixa aquilo que desejamos subir para produção.

LocalRepo(RepositorioLocal): local onde os seus fontes ficam salvos, todas as alterações ficam em uma pasta compacta dentro do diretório .git.De forma análoga é como se estivéssemos fechando a caixa com os itens que colocamos no passo anterior.

RemoteRepo(Repositorio Remoto):local responsável por centralizar em um só lugar todos os repositórios de todos os desenvolvedores envolvidos do projeto. Essa centralização é feita através do uso de servidores remotos como mais popular temos o GitHub.

Agora que você conheceu um pouco a forma de funcionamento do git vamos por a mão na massa.

**Instalação**

Caso você ainda não tenha o git instalado a seguir disponibilizo link que te ajudara a instala-lo na sua máquina Linux/Windows/Mac (sua instalação é bem simples nada que faça você perder o sono)
[https://git-scm.com/]

Após instalação abra o terminal de sua preferência(caso você esteja utilizando o Windows você pode utilizar o Git Bash Here vá em qualquer pasta com o botão direito abra o Git Bash Here) rode o seguinte comando **git --version** com na imagem abaixo:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a2ktgvlo2wn0vtszqsf9.PNG)

Se o resultado for igual o da imagem parabéns o git foi instalado corretamente.

**Configurações Iniciais**

Após a instalação do git é necessário que você configure seu usuário e coloque seu endereço de email afinal de contas as pessoas precisam saber quem é você e quem fez determinada alteração no código para isso no seu terminal digite o seguintes comandos:
    
**git config --global user.name “Seu Nome”**
**git config --global user.email “Email que você vai utilizar”**

Pronto após essa configuração o próximo passo será a criação de um repositório local para que possamos realizar nossos commits e em seguida possamos hospedar no github.
Para isso na pasta  onde encontra-se o seu projeto rode o seguinte pela linha de comando o comando **git init**.:


Aqui vale uma ressalva ao rodar esse comando o git cria uma pasta oculta .git dentro do diretório  conforme imagem abaixo(caso você não esteja visualizando este arquivo na pasta onde foi rodado o comando é necessário habilitar a visualização de arquivos ocultos no Painel de Controle do Windows ou do sistema operacional que estiver usando)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7yo59xlyiicl46jjn028.PNG)


**Comandos Básicos**

Após rodar o comando git init na pasta onde se encontra o seu projeto, você agora pode querer visualizar quais arquivos que estão no seu projeto e que você deseja coloca-los na área de stage(como já mencionamos acima) para isto pelo terminal  na pasta onde você criou seu repositório local rode o seguinte comando **git status**:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rk1jem9of0vj8v1tqb1p.PNG)

Verifique que após rodarmos esse comando foi possível visualizar que o arquivo que eu tinha acabado de adicionar no repositório(novo_documento.txt) ficou com a cor vermelha isto significa que este arquivo já está apto para ser colocado na área de stage, para isto vamos rodar o seguinte comando **git add .** (como o próprio git nos sugere na imagem acima) e como podemos visualizar na imagem abaixo:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lgl6bcqcz3zk8yvpbr8k.PNG)

Após rodarmos esse comando e dermos novamente um git status você verá o seguinte resultado:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b4ruvbqtbkebo3byfau0.PNG)

O arquivo que eu criei que antes estava na cor vermelha agora aparece na cor verde isto significa que  este arquivo agora está pronto para ser commitado.

Para commitarmos basta dar o seguinte o comando **git commit -m “Comentário Qualquer”** conforme vemos na imagem:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vtw8uc46l3jsb9f446ho.PNG)

**OBSIMP:** Sempre procure ser o mais sucinto possível na hora de adicionar um comentário lembre-se que você está trabalhando em equipe e as pessoas precisam entender o que você fez ninguém trabalha por adivinhação.**

Pronto você acaba de fechar o seu pacote de alterações/mudanças e agora você já pode mandar pro gitHub, mas caso você precise vê um log de tudo que foi feito no projeto você tem a opção de rodar o comando **git log** conforme vemos na imagem a seguir.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l7n8010ysy9ncxvxijfz.PNG)


Aqui vale uma breve ressalva no destaque em amarelo mostra um código hash criado pelo git após realizarmos o commit. Esse código é criado pelo git toda vez que commitamos algo é através desse código hash que o git identifica  cada commit realizado no seu projeto.

**Criação do Repositório Remoto**

 Nesse passo é necessário que você já esteja com a conta no GitHub criada, após a criação da conta clique na foto do seu perfil e selecione a opção Your Profile como podemos vê na figura.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wrizrsvn66ka7znhs4rx.PNG)

E em seguida selecione a opção new conforme imagem abaixo:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v01j7awzbks9bcc598sy.PNG)

Na tela seguinte crie um nome para o seu repositório conforme destaque da  imagem 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uhr6xigkabqmzzcuxqtv.PNG)


Aqui vale outra ressalva caso você queira deixar seu projeto privado e só marcar a opção private

**Configurando o SSH**

Antes de subir o projeto para o servidor GitHub é necessário configurar as chaves SSH, mas afinal o que é isso?

A chave ssh é um protocolo de segurança exigido pelo GitHub que permite que somente a maquina na qual você configurou tenha acesso aos repositórios remotos, isso quer dizer que se você tentar acessar algum repositório remoto de uma outra maquina diferente da que você configurou, o GitHub não permitirá 

**OBSIMP:** Aqui vale um ponto de atenção desde o dia 13 de Agosto de 2021 o GitHub não permite mais que  usuários entre com usuário e senha via linha de comando, daí a necessidade de configurarmos a chave SSH.

Pelo terminal do GitBash digite o seguinte comando:

ssh-keygen -t ed25519 -C "your_email@example.com"

-Logo após que você digitar esse comando de enter até o fim no processo de geração das chaves. Após esse passo vá até a pasta onde as chaves foram gerada(no meu caso ele gerou na pasta .ssh dentro do diretório C:/Usuarios/rafael do windows), e copie o conteúdo contido no arquivo de extensão .pub.

**Adicionando a Chave no GitHub**

1. Acesse sua conta no GitHub e no canto superior clique na setinha ao lado da foto e escolha a opção settings;

2. No canto esquerdo selecione a opção(SSH and GPG Keys);

3. E depois clique no botão New SSH Key

4. Na tela Seguinte coloque um nome qualquer para sua chave e no campo key cole a chave publica que você obteve no topico anterior e clique no botão Add SSH Key.

5. Logo na sequencia você verá a chave recém configurada na sua conta GitHub, porém se faz necessário reiniciar a maquina (principalmente se você estiver utilizando Windows para que o Windows consiga reconhecer suas credencias)


**Enviando seu Arquivo Para o GitHub**

Bem agora chegou a hora de mandar os nosso pacotinho pro servidor remoto para isto você verá que após a criação do repositório remoto o git apresenta a seguinte tela que nada mais que é uma espécie de colinha para mandar seus fontes pro servidor remoto:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lf1bak7flnjqna87tmr8.PNG)

Para isto basta roda no seu terminal os dois últimos comandos(fazendo uma breve explicação desses comandos podemos perceber):
O comando **git remote** associa o repositório remoto ao repositório local da sua maquina;
O comando **git push** de fato pega todos os commits que foram realizados e manda lá pra main(este é o nome que o git coloca para determina que este cara é o repositório principal do seu projeto).

Após rodarmos esse comando e em seguida irmos lá no gitHub e clicarmos no nome do nosso repositório você já verá que as alterações já estão contidas dentro do servidor do gitHub conforme imagem abaixo:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f9rh0toqntyleaut4p78.PNG)


Bem pessoal essa foi uma pequena introdução de como trabalhar com git/github além de apresentar alguns comandos básicos do dia a dia para que você comece a sair da inércia. 
Nos próximos artigos iremos nos aprofundar um pouco mais no fluxo do git.