Como controlar a versão de um autor solo que cria documentos que não são de programação?

Question

Sou escritor, não programador. Estou apenas agora, pela primeira vez, aprendendo sobre o controle de versão e como ele funciona, e estou me perguntando como o controle de versão poderia agilizar meu fluxo de trabalho.

Durante anos, usei minha própria versão de controle de versão. Minhas pastas estão repletas de arquivos como resume-2012-06-01.doc, resume-2012-06-15.doc, letter.txt, letter-old.txt, carta-v2.txt, story-notes.txt, story -notes-with-character-sketches.txt story_draft1.txt, story_draft2.txt, story_draft2-short.txt, etc.

Como eu trabalho sozinho, eu nunca estarei ramificando ou mesclando - apenas comprometendo-me à medida que vou e, ocasionalmente, referenciando uma versão mais antiga de um arquivo.

Quais são as melhores práticas para usar o controle de versão para gerenciar o fluxo de trabalho de gravação de um autor solo?

Estou no OSX e estou planejando usar o Git ou o Mercurial (ainda decidindo qual).

1. Devo controlar por versão toda a minha pasta Documentos como um único repositório? (Contém subpastas como Documentos / histórias / angústia / personagens /, Documentos / histórias / angústia / rascunhos /, Documentos / histórias / angústia / brainstorming, Documentos / currículo /, Documentos / cartas /, etc). Ou devo criar repositórios separados para cada projeto? Ou até mesmo repositórios separados para cada subpasta dentro de um projeto de escrita (/ entrevistas /, / web-research /, / story-draft /, etc)?
2. Existem vantagens em ter vários repositórios menores em vez de um grande?
3. Ainda devo manter alguma versão do controle de versão manualmente? Como draft1.txt, draft2.txt, draft2-short.txt, etc? Ou devo deixar o sistema de controle de versão fazer tudo isso por mim?
4. No passado, tentei nunca excluir nada e, em vez disso, coloquei arquivos antigos em pastas chamadas backups /, archives / ou old-version. Agora que estou usando o controle de versão, posso me sentir livre para excluir arquivos dos quais não preciso mais?

Answer 1

Should I version-control my entire Documents folder as a single repository?

Eu sugeriria strongmente uma abordagem de repositório por projeto (Assumindo que os projetos sejam independentes uns dos outros).

Pense nisso da seguinte forma: se você for olhar para uma versão de 3 meses atrás de algum projeto - você também deseja obter todos os outros projetos para a mesma data? Quando você quiser ver todas as alterações feitas desde o último commit - você faria isso em um projeto ou em todo o diretório Documents [1]?

Você não deve dividir mais do que o nível do projeto: Mantenha seus subdiretórios atuais como diretórios em cada repo. Dessa forma, um único commit pode conter, por exemplo, uma alteração em um arquivo de rascunho, a introdução de um novo back-story para algum personagem e uma atualização do arquivo de biografia do mesmo personagem, com este novo back-story detalhado nele. . Mais tarde, se você quiser remover ("reverter") essa história, você terá um único commit com tudo já vinculado.

Essa capacidade de manter juntas alterações logicamente relacionadas a muitos arquivos (com um comentário extra explicando a alteração) é provavelmente o argumento mais importante que tenho para usar um controle de versão para um único usuário (em um simples backup baseado em data) ). Mais tarde, quando vejo algo estranho e me pergunto "O que eu estava pensando", é uma pergunta muito fácil de responder.

Mais alguns comentários sobre coisas que você não perguntou:

• Ramificação - você pode achar isso útil para "testar o jogo" uma ideia - não sei como isso é comum por escrito. Na programação, eu poderia tentar algo que leva muitos commits, e não ter certeza de que funcionaria - então, explicitamente, o branch se sente "mais seguro" do que ter que voltar ao tempo em que eu acho que comecei.

• Git (e presumivelmente Mercurial) são principalmente projetados para código-fonte; Eles geralmente comparam arquivos em uma base de linha, o que provavelmente significa parágrafos inteiros para você. Mais importante, se os arquivos não forem de texto simples (por exemplo, se você usar o Word), configurá-los para "entender" as alterações feitas será muito difícil e, em alguns casos, poderá ser impossível. Se o seu sistema de controle de versão não puder ver as alterações feitas, você perderá muitos dos seus benefícios.

[1] Você pode realmente fazer isso por subdiretório, mesmo se você usar um único repo para tudo, e não é muito mais trabalho; Mas se você sempre fizer isso, mantenha-os separados.

    

Answer 2

Should I version-control my entire Documents folder as a single repository?

Eu começaria assim sim. Conforme o tempo passa, se você sentir que o repositório é muito pesado, você pode dividi-lo em alguns repositórios. Um único repo teria o benefício de ver suas alterações em toda a pasta Documentos de uma só vez. Com repos separados, você teria que ir a cada pasta para fazer commits.

Are there advantages to having multiple smaller repositories rather than one big one?

Ter repos menores significa tamanho menor para cada repo. Se você quisesse compartilhar alguns documentos, seria mais fácil, talvez, se você tivesse alguns repos em vez de um. Ou talvez um repositório "privado" e um repositório "público".

Should I still maintain some version of version control myself, manually? Like draft1.txt, draft2.txt, draft2-shorter.txt, etc? Or should I let the version control system do all this for me?

Com o git você poderia fazer ramos de tópicos para levar um documento em diferentes direções.

A--B--C--D--E--F  (master)
       \
        X--Y--Z  (shorter)

In the past I tried to never delete anything, and instead stashed old files in folders called backups/, archives/, or old-version. Now that I'm using version control, can I feel free to delete files I don't need anymore?

O git armazena inteligentemente todas as alterações que você já fez em qualquer arquivo. Então, se você quiser voltar um dia ou ano, você pode. Se, por algum motivo, você precisar excluir um arquivo, poderá

git rm draft1.txt
git commit -m 'remove unused file'

    

Answer 3

Should I version-control my entire Documents folder as a single repository? (It contains subfolders like Documents/stories/anguish/characters/, Documents/stories/anguish/drafts/, Documents/stories/anguish/brainstorming, Documents/resume/, Documents/letters/, etc). Or should I create separate repositories for each project? Or even separate repositories for each subfolder within a writing project (/interviews/, /web-research/, /story-drafts/, etc)?

Normalmente, você cria um repositório por projeto, mas, no seu caso, não acho que isso importe. Basicamente, se você é o único que vai trabalhar em tudo isso (você não está compartilhando partes com outras pessoas), então um repo provavelmente está bem.

Are there advantages to having multiple smaller repositories rather than one big one?

Principalmente, parar desastres em um repositório afetando outro:)

Should I still maintain some version of version control myself, manually? Like draft1.txt, draft2.txt, draft2-shorter.txt, etc? Or should I let the version control system do all this for me?

Definitivamente, o último.

In the past I tried to never delete anything, and instead stashed old files in folders called backups/, archives/, or old-version. Now that I'm using version control, can I feel free to delete files I don't need anymore?

Faça o backup de todo o repo. Guarde-o com segurança na nuvem em algum lugar. Certifique-se de saber como recuperar versões antigas conforme necessário.

    

Answer 4

Should I version-control my entire Documents folder as a single repository?

Não. Para "Posso" a resposta do tipo de pergunta não será tão imperativa, mas "repositório por projeto" tem muitas vantagens

• Histórico comum para todos os objetos no repositório significa que a evolução em um projeto não afeta outros projetos
• No caso de projetos com vários arquivos, você pode dividir e separar arquivos facilmente em subprojetos (quando e se for necessário)

Are there advantages to having multiple smaller repositories rather than one big one?

Capacidade de gerenciamento, tamanho de (possíveis) transferências no clone | pull | push, tamanho de cada repositório

Should I still maintain some version of version control myself, manually?

Você pode usar marcações / marcadores para ter rótulos mais informativos | memoráveis, do que hash-id, no histórico do repositório para qualquer conjunto de alterações (para qualquer situação de trabalho, em termos práticos)

Now that I'm using version control, can I feel free to delete files I don't need anymore?

Sim, se você salvar repositórios de trabalho concluído (em algum local de backup), terá resultado antigo ("arquivos") com valor agregado "histórico completo de alterações, não apenas estado final"