Opa, eae?
Se você está entrando na área de tecnologia com certeza já ouviu esses dois termos e já viu alguém ou até mesmo você já confundiu os dois e é esse o objetivo desse post, elucidar os conceitos e de quebra aprender a usar um pouco.
Porém, já aviso: esse post, por mais que utilize alguns comandos, não tem a pretensão de ser um tutorial de Git, caso você queria algo assim sugiro que consulte o Git4noobs ou a documentação.
Aqui focaremos no que são, o motivo de serem criados e para que usamos.
Git
O Git é uma ferramenta de versionamento de código (na verdade, qualquer tipo de arquivo de texto basicamente), mas o que é uma ferramenta de versionamento?
Quando você criou algum projeto seja ele texto, edição de vídeo, imagem ou código, já deve ter criado versões dele e acabou com uma pasta cheia de cópias como “certo-sem-capa.docx”, “terminado.docx”, “finalEnviar.docx”, “agoraSimFinal.docx”, “ENVIARRRR.docx”?
Eu diria que a maioria já fez algo parecido e nisso temos alguns problemas:
- Não sabemos qual realmente é o arquivo de projeto final, se alguns meses se passarem nem você que criou muito provavelmente vai saber.
- Não sabemos também qual foi a evolução, ou seja, qual arquivo fomos modificando para chegar em outro arquivo.
- No caso específico de texto (e código, claro), também é bem provável que já tenha escrito um parágrafo ou função, tenha apagado e em outro dia tenha percebido que não deveria, ai o único jeito é escrever de novo.
- Cada nova “versão” do seu projeto requer uma cópia do arquivo original com as partes que não foram modificadas e também as que foram inseridas, removidas ou modificadas, ou seja, você passa a guardar dados em redundância consumindo mais espaço que o necessário. Em um arquivo isso pode até ser desprezível considerando o custo baixo de armazenamento de hoje, mas em grandes repositórios de projetos isso pode representar uma boa perda de espaço.
Como resolver tudo isso? Git! Git, meus amigos!
E como o Git resolve isso?
A partir do momento que você já tem o git instalado no seu computador para iniciar um novo projeto basta estar na pasta/diretório e utilizar o ‘git init’.
Assim você acaba de criar um repositório Git no seu projeto. A princípio, nada ocorre, mas para os olhos mais atentos foi criado a pasta (diretório) ".git" (por padrão no linux pastas/repositórios ou arquivos iniciados com ‘.’ (ponto) são ocultos, assim para ver deve-se habilitar a visualização de arquivos ocultos no seu gerenciador de arquivos).
Você NUNCA deve mexer na “.git” caso não queira problemas, estou falando aqui mais para critério de curiosidade de onde ficam as configurações do seu repositório e as alterações commitadas do seu código. É importante saber da “.git” também caso queira copiar os arquivos para outro lugar e também queira levar o git com suas configurações de projeto e commits junto (apesar de termos formas mais elegantes de fazer uma cópia pelo git).
ps. Explicarei o que é ‘commit’ logo.
Tendo um repositório git, o próximo comando será para adicionar os seus arquivos de código nele, para isso vamos digitar o ‘*git add * *’ (git add pode receber nomes de arquivos ou os parâmetros ‘*’, ou ‘.’ para adicionar todos os arquivos possíveis presentes no diretório).
O ‘git add’ apenas lista e mostra os arquivos que receberam alterações foram adicionados ou removidos adicionando tudo isso em um local separado (chamamos esse local de “Área de staging” e você pode ver essas modificações utilizando ‘git status’), mas ainda nada foi ‘salvo’, para isso devemos usar o "git commit -m “Comentário do seu commit”".
E Pronto, o que basicamente acabou de ser feito foi uma imagem do seu repositório atual com todos os arquivos que estão presentes nele, a partir de agora quaisquer modificações que forem feitas adicionadas pelo ‘git add’ e commitadas pelo ‘git commit’ serão salvas também no seu repositório git.
Massa Marlon! Mas o que realmente acabou de ser feito?
Bora lá, quando você iniciou seu repositório pelo "git init" e após isso commitou sua primeira alteração o git salvou o primeiro estado dos seus arquivos, por exemplo:
Aqui tenho uma pasta com dois arquivos o “code.lua” e o “comentarios.txt”.
O conteúdo de “code.lua” é:
O conteúdo de “comentarios.txt” é:
Ainda não temos nenhum repositório Git criado aqui então bora lá:
Após um repositório vazio criado precisamos adicionar nossos arquivos:
Arquivos adicionados à área de staging, agora falta só commitar:
Beleza! Primeiro commit feito, mas eai?
Vamos modificar um arquivo (code.lua) para poder testar um pouco mais:
E agora vamos commitar essas mudanças:
Tudo salvo, se dermos um ‘git log’ podemos ver nossos commits aqui.
Blz, mas como eu posso ver essas modificações?
Com o ‘git diff’ podemos fazer a diferença entre dois commits e ver a evolução do código:
Pronto! Percebemos agora que todas as alterações que fazemos e commitamos ficam salvas e podem ser consultadas posteriormente, inclusive caso você queira desfazer as alterações você pode voltar a commits anteriores por meio do ‘git reset’.
Porém, acho que já joguei comandos demais para você e como o objetivo desse post não é ser um tutorial de como usar Git e sim entender como ele funciona e como usamos deixarei o resto com a documentação e o Git4noobs.
Branches (ramificações)
Todas as alterações salvas que fizemos até agora (os commits) estão localizadas em uma ramificação/branch.
A branch principal do git por padrão é chamada de “master”, também em alguns lugares e repositórios mais novos ela pode ser chamada de “main”, isso acontece pelo histórico não muito legal da palavra “master” e o que ela pode significar em outros contextos.
Inclusive caso você queria mudar o nome da sua branch utilize git branch -m “novo nome”, isso é muito comum de ser feito.
A utilização de branches serve para organizar melhor o seu repositório. Você pode, por exemplo, identificar um bug e perceber que terá que realizar vários commits para arrumá-lo, assim você cria uma branch especial com outro nome só para resolver o bug e quando estiver tudo certo realiza o ‘merg’ (de fundir mesmo), ou seja, taca as alterações que corrigem esse bug para a sua branch de origem.
Branches também são muito usadas para trabalhar em conjunto!
Até aqui só falamos de repositórios locais, mas a maioria dos repositórios locais estão relacionados a algum repositório armazenado em algum servidor, justamente para servir a várias pessoas. Dessa forma, você e seu amigo podem, ao mesmo tempo, modificar partes do código, cada um em sua branch, ao final cada um funde seu código à ‘main’ e o projeto está pronto (parece muito mais elegante que trocar arquivos por drive, né?).
Diferentes branches também são bastante utilizadas hoje, pois as branches main/master (ou qualquer outro nome da branch principal do repositório) estão muito relacionadas ao deploy. Ou seja, em alguns projetos tudo que vai a branch principal vai automaticamente ao servidor em produção, assim fica meio óbvio perceber que não é bom codar diretamente nessas branches, pois qualquer alteração será automaticamente uma atualização na aplicação.
Traduzindo em miúdos, qualquer erro commitado na main vai derrubar a sua aplicação nesse tipo de repositório, logo é bom desenvolver e testar em outra ramificação.
GitHub
Chegamos nele! O tal do GitHub!
O GitHub é, de maneira simples, o maior host de repositórios Git do mundo. Quando falei que a maioria dos repositórios locais estão relacionados a algum repositório em algum servidor, geralmente estão no GitHub. E de quebra o GitHub dá uma interface amigável para visualizar, mergear’ branches, administrar acessos a repositórios e deixar público repositórios Git abertos. Grandes projetos open source estão publicados e são mantidos por lá.
O GitHub se descreve, e de certa forma é mesmo, uma rede social. Lá você tem o seu perfil, pode deixar alguns repositórios seus abertos como uma forma de mostrar o seu trabalho, ainda pode seguir pessoas e dar estrelas (basicamente likes) em seus repositórios.
Vale lembrar que como o GitHub ainda existem outros serviços como Bitbucket e GitLab, que basicamente são concorrentes diretos.
Diferença entre Git e Github
Se você leu esse post até aqui, primeiro, obrigado! Mas espero que você entenda que querer falar de diferença entre Git e GitHub não faz sentido, a pergunta “Qual a diferença entre Git e GitHub?” não faz sentido.
Isso acontece porque eles não são nem conceitos iguais, nem diferentes, o Git se propõe a ser um software de versionamento com a possibilidade de conectar repositórios locais a remotos. Partindo dessa ideia o GitHub vem como uma rede social onde se hospeda repositórios Git podendo facilitar a disponibilidade de código e compartilhamento de projetos. O conceito do GitHub depende da existência do Git, mas não tem como compará-los, pois eles nem possuem o mesmo propósito.
Existe uma piada de que quando se pergunta “Qual a diferença entre Git e GitHub?” a resposta sempre é “É a mesma que a do Porn e do PornHub” e o maior problema é que realmente é uma boa comparação! Do mesmo jeito que existem repositórios Git, existem vídeos pornôs e do mesmo jeito que você pode compartilhar seu repositório online no GitHub, bom, existe o PornHub para o outro lado também kkkkk
Eu não sei se precisava explicar isso para você com esse nível de detalhamento, porém acredito que agora fica fácil de entender...
Bom, isso é tudo pessoal!
Meu documento de texto aqui já está na sétima página isso que ele nem possui as imagens que serão adicionadas no post final que você acabou de ler.
Espero que tenha aprendido e entendido um pouco mais sobre essas tecnologias aqui, para saber de novos posts me siga lá no Twitter: @MarlonHenq
Obrigado por ter lido!
Flw!
Este post foi originalmente postando em: blog.marlonhenq.dev - Dia 29-05-2023
Oldest comments (0)