Table of Contents
- Nota do Autor
- Introdução
- Git
- Cheat Sheet (Tabela de preguiçoso)
- Links
- Nota final
Nota do Autor
Olá pessoas, nesse texto irei falar sobre VCS (Sistema de Versionamento de Código, sigla em inglês) ou melhor, como o tema é mais conhecido - falarei sobre Git.
Introdução
Antes de falar sobre o Git precisamos entender o que seriam alguns conceitos básicos como Versionamento de Código.
Versionamento de Código
Versionamento é um conceito muito simples e usado no dia a dia de forma que nem percebemos. Por exemplo:
Estamos em um projeto onde temos dois desenvolvedores:
-
Stifler
>
-
Jim
>
Esses dois desenvolvedores estão fazendo o "Milfs Go" uma especie revolucionaria e inovadora, além do tempo sendo um app para acharem a "milfs".
Aqui está uma milf para aqueles não habituados com o termo:
Assim eles começaram a projetar o aplicativo e vão para a parte prática, Stifler decidiu ficar o backend e Jim com o frontend, então depois que um deles termina sua feature (algo novo no sistema) ele zipa e envia para o outro e assim por diante. Não só isso, eles usam o Drive para guardar as versões do software. Além disso possuem uma pasta para as versões corretas e as de teste, tudo em "zip".
Pronto, agora você sabe o que é versionamento de código, é exatamente isto que os dois estão fazendo. Versionar é manipular versões tanto criá-las como acessa-las.
Controle de Versão
Versionamento é o ato de manipular versões, agora o Controle de Versão é um sistema que vai registrar as mudanças tanto num arquivo como em um projeto gigante ao longo do tempo.
Importância
Talvez agora você levante uma questão de o porque aprender "este trem" - como diria um amigo mineiro. Logo, a resposta é simples: esse tipo de ferramenta é essencial para o desenvolvimento já que nos entrega um poder de não somente trabalhar em conjunto de forma assíncrona e sem medo de acabar perdendo o que já foi feito.
Tipos
Com tudo que foi falado em mente agora precisamos entender que existem diferentes tipos de versionamentos, em que eles variam de acordo com a sua arquitetura.
Sistemas Locais
Esse tipo de sistema é mantido em uma maquina. Por exemplo, Jim vai fazer o versionamento da sua parte do frontend, onde ele possui um arquivo de checkout que vai servir para conferir/adicionar as versões e um banco de dados (poderia ser um outro arquivo) contento as versões que ele salvou.
- Diagrama de um sistema local
Sistemas Centralizados
Estes sistemas nascem com a problemática que o Sistema Local trás que é justamente um não compartilhamento simultâneo, já que como no nosso exemplo esses dois teriam problemas de versões já que estarão em computadores diferentes
Mas se usarem um CVCSs (sigla em inglês para Sistemas Centralizados de Controle de Versão), com isso eles terão um repositório compartilhado em que todas as versões estarão e teremos os clientes que são os dois desenvolvedores.
Com isso, temos um grande ponto fraco que é justamente o fato de dependermos de um único servidor, caso o servidor caía, todas as versões iram cair.
- Diagrama de um sistema compartilhado
Sistemas Distribuídos
Com isso os DVCS (Sistemas de Controle de Versão Distribuídos) se tornam um protagonista, já que os clientes não somente clonam os estados atuais, mas também fazem uma cópia completa de todo o repositório localmente.
Assim temos:
- Os servidores, que vão guardar as versões e serviram como pilares para centralizar as versões
- Os clientes que se tornam servidores também, já que eles podem pegar tudo do servidor principal
- Diagrama de um sistema distribuído
Git
Senta que lavem história
Para começar a historia do Git é até bem curta e direta. A comunidade do Linux usava um VCS distribuído chamado BitKeeper só que ele é proprietário
Sim, um sistema open source usando um proprietário. Claramente isso era algo que causava um estranhamento na comunidade .
Que por sua vez chegou ao ápice quando o BitKeeper se tornou pago, logo a comunidade do Linux ficou alerta já que eles teriam que fazer o versionamento do núcleo do Linux em outro sistema.
Assim então a comunidade começou a criar seu próprio VCS que fosse:
- Simples
- Veloz
- Não linear, ou seja, que aceite vários ramos (branches) de modificação
- Capaz de lidar com grandes projetos, afinal, Linux é gigante
E assim nasceu o Git, exatamente em 2005 e até hoje está em evolução sendo um dos VCS mais utilizados em todo o mundo de desenvolvimento de gambiarras (softwares).
Ou seja, tudo nasceu de uma revolta popular
O básico
Vamos agora entender como o Git funciona internamente. Que por sinal trabalha de forma diferente de outros VCS.
Em um outro VCS ele terá os arquivos e quando houver alteração eles criam uma lista somente das alterações:
Agora com o Git ele faz diferente, já que vai tirando snapshots que são como fotos quando ocorre uma mudança e caso tenha algum arquivo que não foi alterado será guardado uma referencia para ele, assim pode ser recuperado.
Esta forma que o Git trabalha com os dados é chamada de stream of snapshots
Integridade
No Git todas as operações passam primeiro por uma checksum (soma de verificações) antes mesmo das alterações serem armazenadas, sendo referenciado por esse mesmo checksum. E para o checksum o Git usa o hash SHA-1.
Logo:
- É impossível que algum arquivo seja alterado sem que o Git saiba
- O SHA-1 é uma sequencia composta de 40 caracteres hexadecimais tal sequencia é calculada pela estrutura de pastas
Este hash estará em todo lugar do Git e ele não guarda o nome do arquivo e sim esse hash.
Estados
Agora vamos para uma das partes cruciais no Git, os estados (states) é como o Git está olhando para os arquivos, ou seja, como os seus arquivos vão estar.
Podendo estar em três estados:
- Commited
- Modified
- Staged
Commited
Commited (comitado) é quando os seus dados estão já armazenados (de forma segura) no teu banco de dados local.
Modified
O modified (modificado) significa que teu arquivo foi modificado, mas ainda não foi para o estado commited, ou seja, não foi salvo no banco de dados.
Staged
O staged (preparado) é o estado intermediário entre o modificado e o comitado, sendo ele quando você adiciona os arquivos para serem comitados.
Assim temos dois níveis principais:
- Diretório de trabalho
- Área de preparo
- Diretório
.gitque vai ser o repositório ou banco de dados local
Diretórios quando se trabalha com Git
- O diretório de trabalho é só uma cópia de uma versão do projeto.
- A área de trabalho é um arquivo dentro do diretório
.gitque vai armazenar as informações do seu próximo commit (o que será guardado) - O diretório
.gité onde vão ficar os metadados e o banco de dados dos objetos do seu projeto (os snapshots)
Fluxo básico
Diretorio
de Area
Trabalho de Preparo Repositorio .git
|--| |--| |--|
|--| --------> |--| -------> |--|
modified staged commited
Agora vai 1.0
Instalação
- Caso for Windows:
- Caso for distros Fedora:
sudo yum install git-all
- Caso for distros Debian:
sudo apt-get install git-all
Configuração
Você não é o Douglas, eu sou Douglas:
Agora vamos definir a sua identidade já que é preciso disso porque as informações de usuário e e-mail para carimbar essas credenciais nos commits.
- Faça assim:
git config --global user.name "Power Guido"
git config --global user.email jalinrapei@exemplo.br
O
--globalsignifica que o escopo dessas identificações serão usadas em todos os projetos
Definir a ferramenta:
Precisa apenas executar este comando em seu terminal:
git config --global core.editor vim
Pedir um help:
git help <verb>
git <verb> --help
man git-<verb>
Agora vai 2.0 versão final
Iniciar o repositório
Devemos o comando abaixo para iniciar o repositório para que o Git consiga ver os arquivos.
- Nisso primeiro acessamos a pasta que é a raiz do repositório, no caso do Jim é o
MilfsGo, então seria:
md MilfsGo # Cria a pasta
cd MilfsGo # acessa a pasta
- Em seguida já inicia o repositório Git
git init
Assim ele vai criar um subdiretório com algumas informações básicas e um esqueleto do seu projeto.
Mas ainda o Git não estará monitorando seu projeto ainda.
Fazendo alterações
Agora vamos fazer alterações básicas como adicionar um README para o projeto.
README são arquivos geralmente em markdown (.md) para registrar a documentação do repositório com informações importantes como:
- Nome
- Descrição
- Como usar
- Etc
Vamos agora primeiro verificar o status do nosso repositório, antes de criar o README:
- Vai exibir o status do repositorio como arquivos modificados ou no estado de preparo
git status
Resultado da execução do comando
Com isso vamos agora criar o arquivo README:
REDME.md
Fazendo a mesma verificação de statust teremos:
Assim temos o README.md na lista "Untracked files" que é quando ele não foi comitado ainda.
Para isso usaremos um outro comando para adiconar ele ao estado "staged":
git add .
Note que o comando add não retorna nada, mas ele adicionou todos os arquivos ao estado staged
O asterisco serve para indicar que vai ser adicionado todos os arquivos que estão modificado, mas você pode colocar o caminho do arquivo ou o nome, como:
git add README.md
Com isso podemos usar o status para ver o que temos:
Temos o README no estado de stage, ou seja, preparado para ser comitado.
Assim podemos finalizar o estado e comitar:
git commit -m "Adicionando o README"
Tome que:
- o argumento
-msignifica que você vai passar uma mensagem - o que estiver dentro das aspas é a mensagem
Como você pode ver, Jim conseguiu fazer o commit.
commit é salvar a alteração no banco de dados (repositório do git)
Agora vamos verificar o log, usando o comando abaixo:
git log
Assim veremos o histórico de commits do repositório:
Quando aparecer está tela, apenas a parteqpara sair delaLog é o registro de algo, neste caso é o log dos commits
Relembrando o fluxo do que aconteceu:
Branches
Agora vamos ver sobre branches são essenciais para o desenvolvimento quando usamos o Git, uma branch é uma ramificação do repositório, ou seja, é uma copia do independente.
E usamos elas para conseguirmos colaboração em conjunto, para testarmos alguma funcionalidade que precise estar isolada ainda de estar em uso na aplicação e etc;
Ela é independente pois o que fazemos nela não influencia em uma outra.
Todo repositório começa com uma branch principal
- Normalmente é chamada de
mainoumater
Com isso, Stifler quer ver as branchs que tem no projeto:
# Exibira uma lista de todas as branches do repositorio
# E também vai destacar em qual branch você está
git branch -a
- Para sair dessa tela basta apertar
q- A branch com asterisco é a atual
Agora vamos criar uma branch:
git branch nova-branch
Agora veremos as branches criadas:
Logo vamos trocar para essa nova branch:
git checkout -m nova-branch
- O checkout consegue fazer algumas coisas e uma delas quando passamos o argumento
-mé para criar uma nova branch baseada na que estamos
- Fizemos a troca da branch com sucesso
Para fazer uma troca de branches podemos usar o comando abaixo também:
git switch nova-branch
Agora vamos adicionar um arquivo neste repositorio:
Veremos o status:
O arquivo ainda não foi comitado então teremos que fazer isso:
Tome como nota que como foi falado as branches são independentes logo o que está na branch nova-branch não está na branch main. Vamos testar isso trocando de branch:
Como o esperado não há a pasta imagens na branch main:
Recapitulando o fluxo
-
Criação de branches:
>
-
Troca de branches
>
Juntando tudo
Agora vamos juntar as branches que é fazer um merge (ou seja, mesclar):
Isto é o fluxo de mesclagem do repositório, onde estamos em um branch e pegamos o que temos em outra branch e jogamos tudo que ela tem de novo na ramificação atual.
Deveremos usar o comando:
git merge nova-branch
- Conseguimos fazer o merge, agora tudo de novo que tem na segunda branch tem na atual
Se conectando com o mundo...
Conectar com o "mundo", ou seja, usar repositórios remotos
Repositórios são todos aqueles que não estão na sua máquina
Para esses repositórios existem sistemas como o GitLab que serve para guardarmos nossos repositórios e é onde Jim e Stifler vão guardar o "Milfs Go".
Assim precisamos fazer uma conta, nisso procure um vídeo no youtube que você acha caso precise
Criar Repositório
Com a conta criada, agora precisamos criar um repositório:
- Clicamos em "New Project"
>
- Vamos em "Create blank project":
>
- Definimos informações básicas:
>
- Definir a origem remota:
- Devemos primeiro pegar a url ssh:
>
- Depois adicionamos localmente essa origem remota:
git remote add origin git@gitlab.com:MrNulus/milfsgo.gitdar
- Usar chave SSH
- Caso não tenha rode o comando:
ssh-keygen
- Quando tiver, basta agora pegar a chave:
# Faça no diretorio raiz
cat .ssh/id_ed25519.pub
- Copie a chave que aparece na tela
- Colocar a chave no GitLab:
>
Push
- Agora vamos fazer um
pushque é emburrar os commits locais para o remoto: - Como é o primeiro
pushque daremos no GitLab precisamos rodar esses comandos, que vai todas as branches e tags
git push --set-upstream origin --all
git push --set-upstream origin --tags
- Depois dessa vez basta usar:
# Usado para quando não queremos definir a origem remota e nem a branch
git push
# Para quando definimos tanto a origem quanto a branch
git push origin main
- E pronto, agora o Stifler e o Jim tem:
>
Pull
Agora temos uma ultima questão, como fazemos para pegar as mudanças do repositório remoto (GitLab). Vamos ver isso então:
# Vai puxar tudo que tem na origem em determinada branch
git pull origin main
Como fiz alterações no README lá no GitLab, preciso pegar essas alterações e puxar para minha branch main:
Agora vamos pensar em um cenario onde não temos o Repositorio e precisamos clonar ele do GitLab, para isso copiamos a URL:
- Agora pegamos essa URL e usamos com esse comando:
git clone <url_clone>
Cheat Sheet (Tabela de preguiçoso)
Essa tabela fornece uma visão geral dos principais comandos Git e suas funcionalidades básicas.
| Comando Git | Descrição |
|---|---|
git init |
Inicializa um novo repositório Git |
git add <arquivo> |
Adiciona um arquivo modificado à área de stage |
git add . |
Adiciona todos os arquivos modificados à área de stage |
git commit -m "Mensagem do commit" |
Cria um novo commit com a mensagem especificada |
git status |
Exibe o status atual do repositório |
git log |
Exibe o histórico de commits |
git checkout <branch/commit> |
Navega para a branch ou commit especificado |
git branch <nome-da-branch> |
Cria uma nova branch |
git merge <branch> |
Mescla a branch especificada com a branch atual |
git push |
Envia os commits locais para o repositório remoto |
git pull |
Baixa as últimas alterações do repositório remoto |
git clone <url-do-repositório> |
Clona um repositório remoto para o computador local |
git reset HEAD~1 |
Remove o último commit, mantendo as alterações |
git revert HEAD |
Cria um novo commit desfazendo as alterações do último commit |
git diff |
Exibe as diferenças entre o diretório de trabalho e a área de stage |
git rm <arquivo> |
Remove um arquivo do repositório |
git mv <arquivo-original> <arquivo-novo> |
Renomeia ou move um arquivo no repositório |
Links
GIT-SCM.COM. Git - Documentation. Disponível em: https://git-scm.com/doc.
YOUTUBE. YouTube. Disponível em: https://www.youtube.com/watch?v=un8CDE8qOR8.
GITLAB. GitLab Documentation. Disponível em: https://docs.gitlab.com/.
Nota final
Adeus e até mais, espero que tenha sido útil esse conteúdo.
Top comments (0)