O Problema do Backup

Imagine que você tem um projeto grande. Você está codificando e, em um certo momento, atinge um ponto de conclusão lógica e lança a versão 1.0, que os usuários começam a utilizar.

No entanto, o trabalho não para por aí e você lança a versão 1.1 com correções de bugs e acréscimos, depois a versão 1.2, depois 1.3, e então reescreve tudo do zero e anuncia o lançamento da versão 2.0. E assim por diante - o trabalho em um projeto normalmente nunca termina.

Durante o desenvolvimento, no entanto, há o risco de quebrar algo no código, ou acidentalmente excluir o projeto ou parte dele. Para não perder todo o trabalho, você periodicamente salva o código do projeto em uma pasta separada. Você simplesmente numera seus backups em sequência, adicionando algum comentário ao backup sobre quais alterações você fez ou qual funcionalidade já estava implementada no momento do salvamento.

No entanto, de repente, percebe-se que não é possível simplesmente lançar a versão 2.0, porque os usuários da primeira versão reclamam - eles não estão prontos para migrar para a segunda. Ok, você diz, e começa a trabalhar na segunda versão, enquanto lança atualizações para a primeira em paralelo. Seu projeto se divide em duas pastas - uma para a primeira versão e outra para a segunda. A pasta de backup também se divide. Além disso, parte do código da primeira e da segunda versão é igual. Ao fazer ajustes nesse código em uma versão do projeto, você precisa lembrar de fazer os mesmos ajustes na outra versão. No entanto, às vezes você esquece de fazer isso. Bugs estranhos aparecem. O trabalho fica parado.

Durante o trabalho na versão 2.0, você decidiu adicionar um novo recurso. No entanto, leva muito tempo para desenvolvê-lo e você decide dividir a segunda versão em duas pastas, duplicando o código. Na primeira pasta, você continuará o desenvolvimento do seu projeto, e na segunda, implementará o novo recurso. Finalmente, o recurso está pronto. Nesse meio-tempo, o projeto principal já se tornou a versão 2.3. Agora você precisa mesclar o código com o novo recurso ao código principal do projeto. Você começa a copiar os arquivos de código para a pasta principal, resolvendo ao mesmo tempo os conflitos entre o novo código e o antigo. Isso leva três dias de trabalho. O trabalho fica parado.

O projeto cresceu. Você decide pedir ajuda a um amigo. Você dá uma tarefa ao amigo e envia a ele um arquivo compactado com o projeto. O amigo conclui a tarefa e devolve a você o arquivo com os novos arquivos, bem como com os antigos, nos quais ele fez alterações. Você gasta meio dia para separar os novos arquivos dos antigos. Em seguida, gasta mais um dia integrando as alterações em seus próprios arquivos.

Você chama mais dois amigos para ajudar. Agora são quatro. Diariamente, você recebe arquivos compactados com o trabalho concluído. Você integra as novas partes ao projeto e envia a todos os arquivos do projeto com as alterações. O trabalho avança lentamente, pois, enquanto você integra uma alteração, seus amigos aguardam você enviar a nova versão do projeto e não podem continuar trabalhando, para não dessincronizar completamente.

A pasta de backups já contém gigabytes de código. Sendo que, basicamente, há principalmente duplicatas, pois, ao alterar uma pequena parte do código, você ainda assim salva o projeto inteiro. Você decide limpar essa pasta, excluindo as primeiras cem versões. Uma semana depois, descobre-se que nas versões excluídas havia o código de um recurso específico, do qual você havia desistido na época, mas agora decidiu recuperar. Mas o código desse recurso já foi excluído e não está em lugar nenhum. Você reescreve esse recurso do zero. O trabalho fica parado.

Parece ruim, não é? No entanto, os desenvolvedores realmente trabalhavam assim, como eu descrevi acima. Era, obviamente, muito inconveniente. Por isso, surgiu um sistema especial chamado Git, cujas capacidades discutiremos na próxima lição.