Criando um repositório git de um conjunto de arquivos manuais

Question

Estou lidando com um aplicativo que foi criado sem um sistema de gerenciamento de conteúdo adequado. Em vez disso, os arquivos de origem foram salvos em um arquivo ZIP e submetidos a backup toda vez que uma nova versão foi lançada.

Eu gostaria muito de colocar esse projeto em um repositório git para ter uma visão adequada das mudanças ao longo do tempo, mas estou longe de ser claro sobre como fazer isso, já que criei apenas novos repositórios git ou trabalhei com os existentes.

Seria simples criar um repositório a partir do arquivo mais recente e trabalhar a partir daí, mas como incluir o histórico de alterações?

    

Answer 1

It would be simple to just create a repository from the most recent archive and work from there, but how do I include the history of changes?

Bastante fácil. Existem duas maneiras de abordar isso, dependendo da limpeza da base de código de um arquivo ZIP para outro: Cumulative UnZIP Commits ou Clean Up após cada commit .

Commits UnzIP cumulativos: UnZIP, Commit, UnZIP outro, Commit Outro, Etc…

A solução é primeiro criar um repositório git baseado no arquivo mais antigo, confirmá-lo, adicionar as coisas subsequentes / progressivamente mais recentes, confirmar e assim por diante. Por exemplo, digamos que você tenha três arquivos nomeados / datados da seguinte forma:

• archive_20150801.zip
• archive_20150804.zip
• archive_20150806.zip

Agora eu começaria descompactando archive_20150801.zip e criando o repositório git inicial com base nisso. Então eu descompactaria archive_20150804.zip e arrastaria / copiaria - ou apenas descompactar no lugar - para que as coisas substituíssem as antigas archive_20150801.zip e assim por diante. Idem com archive_20150806.zip .

Limpar após cada confirmação: UnZIP, Confirmar, Excluir, Descompactar outro, Confirmar outro, Excluir outro, Etc…

Mas se você quiser ser mais preciso em sua fusão de arquivos mais recentes com arquivos antigos em cada arquivo ZIP, eu recomendaria fazer isso:

1. Descompacte um arquivo e confirme.
2. Em seguida, após a conclusão do commit, manualmente - não via git rm - remova todos os arquivos do diretório que contém o repositório. Certifique-se de não remover o material específico do git, como .git , .gitignore e tal.
3. Feito isso e com um diretório relativamente vazio, descompacte o próximo arquivo e coloque o conteúdo no diretório do repositório git.
4. Agora, com novos arquivos, faça um git add -A e faça um novo commit.
5. Feito isso, volte ao primeiro passo para o próximo arquivo ZIP que você deseja adicionar ao mix.

O benefício desse método "commit coisas, excluir coisas, adicionar novas coisas, cometer novas coisas" é que você não vai acabar com arquivos perdidos que só existiam em uma versão inicial do código no repositório final. Cada commit é um puro reflexo do que o ZIP contém e não uma pilha cumulativa de arquivos e diretórios expandidos uns sobre os outros.

Mantendo datas de confirmação

Quanto a manter um pouco de aparência de um histórico de data / hora, você pode fazer um footwork sofisticado e forçar datas reais de confirmação do git a se adequar às datas reais do arquivo como explicado nesta resposta de estouro de pilha . Mas eu pessoalmente acho isso excessivamente complexo e propenso a riscos; Eu prefiro manter tarefas assim tão simples quanto possível. Em vez disso, eu configuraria uma mensagem de commit que afirma claramente como cada commit é:

Commit of 2015-08-01 ZIP release archive.

Dessa forma, você pode facilmente saber o que a origem do arquivo confirmar no futuro, apenas navegando no histórico de comentários de commit.

Eu mesmo fiz isso para arquivos antigos que gerenciei por meio desse antigo método de "copiar o diretório e criar um não-gerenciado-arquivo-ZIP" e é uma dor, mas ajuda na longo prazo para manter alguma aparência de um histórico de codificação para um projeto.