O que é Git e GitHub para que serve?

Apenas poder acessar o código dos outros colaboradores não é suficiente. Precisamos manter o histórico dos nossos arquivos, ou mais: das nossas modificações, pois muitas vezes mudamos arquivos em grupo, num movimento único (um commit). Dessa forma, podemos voltar atrás e recuperar o estado do sistema como ele era ontem, ou no ano passado, e comparar as mudanças, para encontrar bug e estudar otimizações.

Todos os nossos arquivos, assim como seus históricos, ficam em um repositório e existiam vários sistemas que gerenciavam repositórios assim, como CVS e SVN. O Git é uma alternativa com um funcionamento mais interessante ainda: ele é distribuído e todo mundo tem uma cópia inteira do repositório, não apenas o "servidor principal". Isso traz grandes vantagens que você não precisa aprender nesse exato momento.

Então, o que é a ferramenta Git exatamente?

O Git é um sistema de controle de versão distribuído e amplamente adotado. O Git nasceu e foi tomando espaço dos outros sistemas de controle. Seu criador principal é o mesmo que o do Linux: Linus Torvalds, e ganhou o coração das pessoas que trabalham com open source.

Qual é a linguagem do Git?

Desde seu lançamento, o Git foi sendo gradualmente adotado pela comunidade de desenvolvimento devido à sua robustez como sistema de gerenciamento de versões e características como ser distribuído e rápido. Por este motivo, muitas pessoas que desenvolvem se perguntam em algum momento: "Do que é feito o Git"?

Inicialmente, por ser desenvolvido com o Linux em mente como plataforma, o Git foi desenvolvido em Shell Script que, apesar de funcionar como o esperado, amarrava a ferramenta a sistemas Linux, que tinham os utilitários necessários para interpretar o Shell Script. Com a popularidade da ferramenta, outros sistemas buscaram dar suporte a ela, através da emulação de um sistema Linux, que ficava responsável por executar o Git.

No entanto, o uso da emulação de um sistema Linux tinha impacto na performance da ferramenta nos sistemas operacionais que usavam essa estratégia. Com isso em mente, muitos comandos do Git, inicialmente escritos em Shell Script, foram reescritos na linguagem C, que resultou em ganho de performance em plataformas que não usam o Shell Script como linguagem de linha de comando oficial, como é o caso do Windows.

Quais são os principais comandos do Git?

O Git é uma ferramenta bastante robusta e oferece diversos utilitários para gerenciar as versões de um projeto em linha de comando. Confira os principais comandos da ferramenta:

1. Git init;

2. Git clone;

3. Git status;

4. Git add;

5. Git commit;

6. Git log;

7. Git branch;

8. Git checkout;

9. Git diff.

1) Git init

git init

É utilizado para inicializar um repositório Git dentro de um diretório do sistema. Após sua utilização, a ferramenta passa a monitorar o estado dos arquivos no projeto.

2) Git clone

git clone <-caminho-do-repositório->

É utilizado para criar uma cópia de um repositório remoto em um diretório da máquina. Este repositório poder ser criado a partir de um repositório armazenado localmente, através do caminho absoluto ou relativo, ou pode ser remoto, através do URI na rede.

A partir de um repositório clonado, é possível acompanhar o estado de um projeto e suas modificações, além de contribuir com o projeto, a partir do envio das suas modificações ao repositório central.

3) Git status

git status

É utilizado para verificar o status de um repositório git, bem como o estado do repositório central. O comando mostra informações sobre se o projeto local está sincronizado com o central, quais arquivos estão sendo monitorados pelo Git e em qual branch você está no projeto.

4) Git add

git add <-arquivo->

É utilizado para adicionar arquivos ao pacote de alterações a serem feitas. É possível adicionar um único arquivo, múltiplos arquivos de uma vez, como git add <-arquivo1-> <-arquivo2-> ..., ou até mesmo um diretório, a partir de seu caminho. Uma vez que um arquivo é adicionado ao pacote de alterações com o comando add, ele está pronto para entrar no próximo commit.

5) Git commit

git commit -m "mensagem do commit"

É utilizado para criar uma nova versão do projeto a partir de um pacote de alterações. O commit pega o pacote de modificações adicionado através do comando git add, fecha essas alterações num pacote e o identifica através de um Hashcode. Além disso, para cada commit é necessário escrever uma mensagem para identificá-lo, com uma mensagem clara de quais alterações foram feitas neste commit.

6) Git log

git log

É utilizado para ver o histórico de alterações do projeto, onde aparecerão todos os commits feitos, com suas respectivas mensagens e códigos identificadores. O comando é muito útil quando precisamos rastrear o andamento de um projeto e verificar em qual ponto cada funcionalidade foi implementada. Além disso, o comando conta com várias opções para mostrar o histórico de forma resumida, gráfica e até mesmo mostrando a diferença entre os commits, que podem ser vistas na documentação oficial do comando.

7) Git branch

git branch <-nome-da-branch->

É utilizado para criar novos ramos de desenvolvimento, bem como visualizar quais são os ramos existentes. Para criar um novo ramo, basta utilizar o comando git branch seguido do nome do novo ramo, e para visualizar quais os ramos existentes a utilização do comando é bem similar: basta não informar um nome para a nova branch, e serão listadas todas as já criadas.

8) Git checkout

É utilizado para navegar entre as versões do projeto, bem como entre as diferentes ramificações criadas.

Para navegar entre as versões, basta usar o comando:

git checkout <- Hashcode do commit ->

E todo o estado do projeto se modificará ao estado no qual o commit foi feito.

Similarmente, para navegar entre as ramificações podemos usar o comando:

git checkout <- nome da branch ->

E a branch será alterada. O comando também permite criar uma branch e imediatamente mudar para ela, através do comando:

git checkout -b <- nome da branch ->

Que vai criar a ramificação e navegar até ela.

9) Git diff

É utilizado para visualizar modificações feitas entre commits, sejam eles entre um commit arbitrário e o estado atual do projeto, dois commits arbitrários, ou até mesmo todas alterações entre dois commits distintos.

Para visualizar as alterações entre um commit distinto e o atual, basta usar o comando:

git diff <- Hashcode do commit anterior ->

E serão listadas todas as diferenças no projeto entre os dois commits.

Quais os três objetos internos do git?

Internamente, o Git cria conjuntos de dados e metadados para armazenar o histórico de um projeto monitorado pela ferramenta. A esses conjuntos de dados damos o nome de objetos git, e eles podem ser de 3 tipos:

1. Blobs;

2. Trees;

3. Commit.

1) Blobs

São objetos criados para armazenar dados de arquivos, porém não guardam seus metadados. Na prática, a partir do conteúdo de um arquivo é gerado um Hashcode de identificação para ele, que será usado para guardar seu estado em um determinado ponto (Caso duas pessoas diferentes criem arquivos com exatamente o mesmo conteúdo, o git criará um blob idêntico para os dois arquivos, pois ele só se baseia no conteúdo do arquivo e não guarda metadados sobre quem criou o arquivo ou quando).

2) Trees

São objetos criados para armazenar dados de pastas, como blobs e até mesmo outras trees, podem ser entendidos como a representação de uma pasta dentro do git. Similar ao blob, a tree não guarda metadados e gera um Hashcode de identificação baseado em seu conteúdo.

3) Commit

São objetos que guardam o snapshot de um momento do projeto. Dentro de um commit são guardadas trees e blobs, que por sua vez identificam o estado dos arquivos e pastas no momento em que o commit é criado, assim como metadados como quando ele foi criado e por quem. O Hashcode que identifica um commit é justamente o que aparece ao utilizar o comando git log, e é essencial para controlar as versões do projeto.

Qual a vantagem de utilizar o Git?

Com o acesso facilitado a computadores, trabalhar com arquivos tornou-se uma forte alternativa às pilhas de papéis, afinal, ao guardar as informações em memória, menos espaço físico é ocupado. As grandes salas de arquivos com toneladas de papéis passaram a ser substituídas por computadores e servidores com grande capacidade de armazenamento. Assim se tornou possível, também, que múltiplas pessoas acessem um mesmo arquivo através de um servidor central, responsável por arquivar os documentos.

O acesso de muitas pessoas a um arquivo, no entanto, podia ser problemático. Imagine que três pessoas, que estão trabalhando no mesmo projeto, precisam editar o mesmo arquivo, cada uma em sua parte de responsabilidade. Se as pessoas tentarem fazer alterações ao mesmo tempo, poderiam ocorrer duas coisas:

1. O arquivo ser sobrescrito e perder informações do trabalho de uma pessoa; ou

2. O arquivo ficar bloqueado para edição a partir do momento em que a primeira pessoa começar a editá-lo, que apesar de não perder informações, prejudica a produtividade da equipe.

Além disso, não se tinha controle sobre quem era responsável por cada alteração, pois não era mantido um histórico de alterações do documento.

Com isso em mente, passaram a surgir ferramentas para controlar as versões de um projeto, que eram capazes de manter todo o histórico das alterações nos arquivos, bem como as pessoas responsáveis por elas, como o CVS e o Subversion. Dessa maneira, além de ter o controle do histórico de um projeto, era possível reverter alterações que introduziram funcionalidades indesejadas ao projeto, ou voltar a um estado do projeto onde existia um arquivo que não existe mais na versão atual.

Apesar de já fornecer o controle do histórico de versões, estas ferramentas costumavam se tratar de ferramentas centralizadas de controle de versão, ou seja, ferramentas que controlavam o versionamento do estado de um repositório central, em um servidor. Sendo assim, existia uma vulnerabilidade no modelo: caso existisse alguma falha no servidor, não seria possível utilizar o controle de versão enquanto a falha existisse, e no caso de um disco corrompido, isso poderia significar a perda de todo o histórico, caso não existisse nenhum backup.

Com isso, surgiram os sistemas de gerenciamento de versões distribuídos, nestes, além de existir um repositório central em servidor, cada pessoa terá uma cópia do repositório central em sua máquina, e através do repositório local, poderá comunicar-se com o armazenado no servidor. Com esse modelo, é mais fácil restaurar o estado de um servidor defeituoso, pois cada cliente tem uma cópia exata do repositório central, e basta copiá-la para o servidor para restaurá-lo. Além disso, permite trabalhar com diversos repositórios remotos, o que aumenta as possibilidades de fluxo de trabalho com diferentes grupos de pessoas.

O Git surgiu justamente sendo um sistema de gerenciamento de versões distribuído (SGVD), bastante robusto, que permite utilizar todas as vantagens do modelo. Mas por que o Git se popularizou tanto, e outras alternativas como o Mercurial e o Helix Core não?

O Git se tornou bastante popular por, além de ser um SGVD, se tratar de uma ferramenta de código aberto gratuita, e ser fácil de começar a utilizar. Além disso, trata-se de uma ferramenta muito veloz, devido à sua arquitetura, suporta desenvolvimento não-linear, com milhares de ramificações e funciona muito bem com projetos grandes, afinal, foi pensado para suportar o controle de versões do Linux, um dos sistemas operacionais mais adotados no mundo.

Ainda assim, talvez o principal motivo do Git ser tão adotado pela comunidade dev, desde devs iniciantes até experientes, seja a existência da plataforma GitHub. A plataforma, que permite compartilhamento de código através da criação de repositórios, se tornou muito forte dentro da comunidade do open-source, devido à facilidade de compartilhar e contribuir em projetos abertos.

Sendo assim, o Git se destaca por, além de ser um sistema completamente distribuído, ser muito performático, oferecer suporte a desenvolvimento em grandes projetos, com múltiplas ramificações. Além de ser completamente compatível com a maior rede de compartilhamento de código da atualidade, o GitHub.

O que é GitHub?

O Github tem sim muita relação com o Git. GitHub é uma plataforma para gerenciar seu código e criar um ambiente de colaboração entre devs, utilizando o Git como sistema de controle. Ele vai facilitar o uso do Git, escondendo alguns detalhes mais complicados de setup. É lá que você provavelmente vai ter seu repositório e usar no dia a dia.

O sistema web que ele possui permite que você altere arquivos lá mesmo, apesar de não ser muito aconselhado, pois você não terá um editor, um ambiente de desenvolvimento e de testes. Para se comunicar com o github e mexer nos arquivos do seu repositório, você pode usar a linha de comando, usando o comando do git e suas diretivas de commit, pull e push. Parece assustador? Há uma alternativa: usar um aplicativo desktop mais intuitivo, o GitHub Desktop, veja a seguir.

Github Desktop: usar Git sem precisar configurar e manter um servidor

O Github Desktop é uma casca para o comando do git, que esconde alguns termos que podem ser assustadores para quem está começando. Eu indico fortemente seu uso como primeiro passo, pois o sistema inteiro dá uma cara de "sincronizador de código". Ele facilita as visualizações, o envio e o recebimento das modificações, além dos famosos conflitos de merge, que você não precisa se preocupar nesse primeiro instante.