Um dos grandes problemas ao desenvolver software é salvar o projeto feito, assim como manter rastro das modificações feitas. É muito fácil ter problemas desenvolvendo um projeto, onde códigos são frequentemente perdidos de diferentes maneiras. Um exemplo disso é, se os arquivos não forem salvos em alguma alternativa de nuvem, pode ser que com o tempo o arquivo seja perdido com formatação do computador, por exemplo.

Juntar modificações de diferentes fontes em uma

Outro problema muito comum acontece quando se trabalha com vários desenvolvedores. O que pode ser feito quando diferentes pessoas mexeram no código? É possível solucionar isso de maneira manual, mas será muito maçante e tomará bastante tempo.

Com tantos problemas, como resolvê-los?

Em problemas como esses, entre outros mais, Git e GitHub podem ser de grande valia, se corretamente utilizados. Existem também outras ferramentas de versionamento de projetos, mas especificamente o Git tem muitos recursos além de outras opções.

O Git é uma ferramenta livre que foi inicialmente desenvolvida por Linus Torvalds. Por ser livre, será sempre gratuito e aberto, onde qualquer pessoa pode colaborar em seu desenvolvimento e melhora. Com isso, não há problemas de funcionalidades inesperadas pelos usuários, como envio de dados para que uma empresa possa explorar os mesmos.

Milhares de projetos usufruem dessas ferramentas, principalmente os de código aberto, com centenas de colaboradores. Empresas também usam, logo que o versionamento nestas é primordial. Em ambiente de produção, é importante para que, em caso de erros fatais, o código possa ser retornado para a versão que estava funcionando.

Qual a diferença do Git e GitHub?

Git e GitHub podem ser usados em conjunto para o fim de versionamento e armazenamento do código, além de outras funcionalidades, mas são diferentes em conceito. Git é uma implementação de versionamento, enquanto GitHub é um servidor onde as informações versionadas são armazenadas. Consequentemente, as informações estão em um local mais seguro que seu próprio computador, que é sujeito a muito mais problemas.

Porque GitHub?

GitHub é muito popular para muitos projetos com código aberto e de software livre, e é usualmente lembrado quando se trabalha com git. Não é a única opção disponível para projetos, mas é a que será evidenciada nesse artigo. Outras alternativas são também populares, então não vá pensar que somente GitHub é viável. Além do mais, ele não é inteiramente gratuito.

Para projetos públicos, em que qualquer pessoa pode visualizar, copiar e também colaborar de diferentes maneiras. Projetos privados podem ser criados com contas de estudante (vide https://education.github.com/students), com contas gratuitas (com limitações) ou então com contas pagas sem limitações (vide https://github.com/pricing). Para uso individual, uma conta gratuita supre muito bem a necessidade, e em contas de estudante, ainda há a vantagem de alguns pacotes de parcerias com empresas (https://education.github.com/pack).

Posso colocar um serviço de git em meu próprio servidor?

Sim, é possível de diversas maneiras, mas nenhuma terá a interface online igual à do GitHub para explorar. Claro que outras também implementam interface web, mas, nesse caso, é cada um por si. Outras opções que podem ser utilizadas são o GitLab e GitBucket, também muito utilizadas. Cada um tem suas vantagens, desvantagens e preços.

Especificamente sobre o GitHub há os seguintes recursos disponíveis que complementam o versionamento:

• Issues: Qualquer pessoa pode acessar um projeto para criar e/ou comentar Issues (problemas) no software. Comumente são colocadas até dificuldades de uso do software ou biblioteca em questão. Originalmente, é utilizada para postar bugs e possíveis melhoramentos no projeto. Issues tem diferentes status e metadados, entre eles, podem estar abertas ou fechadas, ou então ter tags que identificam para diferentes propósitos, ou até designar um colaborador para resolver a mesma.
• Projects: É uma aba mais recente do GitHub, e eu acho particularmente útil. Ela é bastante integrada com issues e é facilmente utilizada como uma ferramenta de kanban. Não é tão avançada quanto o Trello, por exemplo, mas ainda tem a vantagem de ter as informações do projeto centralizadas em somente um local.
• Pull Requests: Normalmente no desenvolvimento de projetos grandes, são criadas diferentes branchs para desenvolvimento do código (serão explicadas posteriormente). Eventualmente, estas são enviadas para a branch master, e isto normalmente é feito por meio de um pull request. Este deve ser aberto para que então seja analisado sua viabilidade, já que provavelmente terão diversos conflitos no desenvolvimento, e também são abertos comentários, até que em algum momento seja aceito e seja enviado para a branch master.
• Wiki: Serve para desenvolvimento de documentação e páginas sobre o projeto. Não acho particularmente bem organizado, já que não pode ser separado em grupos de maneira expansível, mas várias bibliotecas fazem bom uso deste para que outras pessoas consigam utilizá-la melhor.
• Insights: Alguns gráficos são disponibilizados nessa tela, entre eles: contribuição de cada colaborador, acessos ao projeto, frequência de commits, cópias do projeto (forks), evolução de dependências de commits do projeto (network), entre outros.
• Edições online: É possível editar os arquivos do projeto pelo site, mas não é muito recomendado, logo que será um commit para cada edição e não é possível testar a execução do projeto. Pode ser muito bom para editar arquivos como o README, que não é crítico ao projeto.

Funcionamento do Git:

O git em si é movido por commits, que são como “snapshots” do código desenvolvido. Entre os metadados relacionados a um commit, há as seguintes informações: momento em que foi realizado, usuário que o fez, título e descrição. É possível fazer commits sem colocar um título, mas se tiver um texto pertinente no título, será melhor de manter um rastro das modificações feitas.

É importante saber que quando um commit é feito, ele está somente na sua máquina, e ainda não foi enviado online. Para que seja enviado, é necessário então que seja executado um comando chamado de “push“, que necessita de credencias para ser executado. Em projetos com mais colaboradores, normalmente ocorrem problemas ao tentar enviar um código online, já que diferentes alterações no código podem acarretar em conflitos.

Conflitos são um mal necessário para o versionamento. Imagine diferentes pessoas que editaram a mesma função, qual a versão deve ser utilizada? Uma solução seria selecionar uma versão arbitrariamente, mas isso geraria maiores problemas. O melhor é deixar que os conflitos aconteçam para então resolvê-los.

Na resolução de conflitos, podem ser consideradas três possibilidades:

• manter a versão que está sendo enviada;
• manter a versão que estava disponível no servidor; ou
• manualmente combinar as duas versões em códigos funcionais.

Ainda podem ocorrer outros problemas no código além dos conflitos mas esses são erros lógicos que as ferramentas de versionamento não conseguem prever.

Um exemplo disso é alterar os parâmetros de uma função e não alterar o local do código onde essa função é utilizada. Para que isso seja diagnosticado, o ideal é utilizar ferramentas de testes de código, mas isso é assunto para outro artigo.

Conceito de Branches

Um conceito importante para aprender ao fazer uso do Git é o de branch(es). Essas podem ser pensadas como linhas de código, que podem ser posteriormente juntadas. Este conceito é bastante abstrato, mas algo assim pode ser visualizado na aba “network” do GitHub.

Quando você edita código, você está necessariamente digitando para uma branch específica, e assim que fizer commit, e push, este será vinculado a esta branch. Outras branches não terão este código disponível. Isso é muito útil para isolar edições de código, mantendo online. Por padrão, a edição de código será na branch master, e não é obrigatório criar outras.

Um exemplo de quando utilizar branch, é o seguinte:

1. Imagine duas equipes trabalhando no desenvolvimento de um software, cada uma responsável por implementar uma funcionalidade separada. Se o código estiver em somente uma branch, edições de uma equipe facilmente atrapalharão a outra equipe, que não está focada nesta funcionalidade, e acabará por ter de se preocupar com seções de código não relacionadas, e perderá o foco.
2. Se estiver em duas branches separadas, uma para cada funcionalidade, ao enviar alterações no código, estará somente na branch específica que trata somente dessas alterações, e gerará somente problemas para colaboradores trabalhando em código relacionado.
3. Claro que, assim que ambas estiverem desenvolvidas, será necessário que seja feita uma junção dos códigos, que pode ser especialmente massante e pode necessitar de pessoas de ambos os times envolvidas para que não ocorra erros inesperados. Nesse caso, é esperado que ocorram vários conflitos.

Como utilizar o Git

Para utilizar o Git, pode ser utilizado o cliente de linha de comando, que é mais pura implementação do mesmo, mas existem muitas opções com interface gráfica que são muito mais simples, até para resolver conflitos.

Elas podem ser visualizadas no site do próprio Git (https://git-scm.com/downloads/guis/). Já que estamos comentando do GitHub, há o cliente desenvolvido pela própria equipe: o GitHub desktop (https://desktop.github.com/), que infelizmente não está disponível para linux.

O GitHub desktop consegue abstrair vários comandos executados do git, colocando um simples botão “sync” para sincronização do código e já aparece todos os conflitos que ocorreram para que possam ser resolvidos.