fluxo de trabalho git + LaTeX

Estou escrevendo um documento muito longo no LaTeX. Eu tenho meu computador de trabalho e meu laptop, e trabalho com os dois. Eu preciso manter todos os arquivos sincronizados entre os dois computadores e também gostaria de manter um histórico de revisões. Eu escolhi o git como meu DVCS e estou hospedando meu repositório no meu servidor. Também estou usando o Kile + Okular para fazer a edição. O Kile não possui um plug-in git integrado. Também não estou colaborando com ninguém neste texto. Também estou pensando em colocar outro repositório privado no codaset, se meu servidor, por algum motivo, não estiver acessível.

Qual é a prática recomendada de fluxo de trabalho nesse caso? Como a ramificação pode ser ajustada neste esquema de trabalho? Existe uma maneira de comparar duas versões do mesmo arquivo? Que tal usar um esconderijo?

Alterações no seu fluxo de trabalho LaTeX:

A primeira etapa no gerenciamento eficiente de um fluxo de trabalho do Git + LaTeX é fazer algumas alterações nos seus hábitos do LaTeX.

• Para iniciantes, escreva cada frase em uma linha separada . O Git foi gravado no código fonte do controle de versão, onde cada linha é distinta e tem um propósito específico. Quando você escreve documentos no LaTeX, geralmente pensa em termos de parágrafos e os escreve como um documento de fluxo livre. No entanto, no git, as alterações em uma única palavra em um parágrafo são registradas como uma alteração no parágrafo inteiro.

  Uma solução é usar git diff --color-words(veja minha resposta a uma pergunta semelhante Como usar o Mercurial para controle de versão de documentos de texto? Onde mostro um exemplo). No entanto, devo enfatizar que dividir em linhas separadas é uma opção muito melhor (eu apenas mencionei isso de passagem nessa resposta), pois eu achei que isso resultou em conflitos mínimos de mesclagem.

• Se você precisar olhar para o código diff, use o diff nativo do Git. Para ver a diferença entre duas confirmações arbitrárias (versões), você pode fazer isso com os shade cada uma das confirmações. Consulte a documentação para obter mais detalhes e também Mostrando quais arquivos foram alterados entre duas revisões .

  Por outro lado, se você precisar examinar o diff da sua saída formatada , use latexdiffum excelente utilitário (escrito em perl) que use dois arquivos de látex e produza uma saída diferenciada em pdf como esta ( fonte da imagem ):

  

  Você pode combinar gite latexdiff(além disso, latexpandse necessário) em um único comando usando git-latexdiff (por exemplo, git latexdiff HEAD^para visualizar a diferença entre sua árvore de trabalho e o último mas um commit).

• Se você estiver escrevendo um documento longo no LaTeX, sugiro dividir capítulos diferentes em seus próprios arquivos e chamá-los no arquivo principal usando o \include{file}comando Dessa forma, é mais fácil editar uma parte localizada do seu trabalho, e também é mais fácil para o controle de versão, pois você sabe quais alterações foram feitas em cada capítulo, em vez de precisar descobrir isso a partir dos registros de um grande Arquivo.

Usando o Git com eficiência:

• Use ramos! . Talvez não haja conselhos melhores que eu possa dar. Eu achei as ramificações muito úteis para acompanhar "idéias diferentes" para o texto ou para "estados diferentes" do trabalho. A masterramificação deve ser o seu corpo principal de trabalho, no estado "pronto para publicar" mais atual, ou seja, se dentre todas as ramificações, se houver uma que você queira colocar seu nome nela, ela deverá ser a ramificação principal.

  As filiais também são extremamente úteis se você é um estudante de graduação. Como qualquer aluno de graduação atesta, o orientador é obrigado a fazer várias correções, a maioria das quais você não concorda. No entanto, é esperado que você os altere pelo menos por enquanto, mesmo se eles forem revertidos mais tarde após as discussões. Portanto, nesses casos, você pode criar uma nova ramificação advisore fazer alterações ao seu gosto, mantendo ao mesmo tempo sua própria ramificação de desenvolvimento. Você pode mesclar os dois e escolher o que você precisa.

• Eu também sugeriria dividir cada seção em um ramo diferente e focar apenas a seção correspondente ao ramo em que você está. Crie uma ramificação quando você criar uma nova seção ou seções fictícias quando fizer seu commit inicial (sua escolha, na verdade). Resista ao desejo de editar uma seção diferente (por exemplo, 3) quando você não estiver no ramo. Se você precisar editar, confirme este e faça o checkout do outro antes de ramificar. Acho isso muito útil, pois mantém o histórico da seção em seu próprio ramo e também informa rapidamente (da árvore) quantos anos tem uma seção. Talvez você tenha adicionado material à seção 3 que requer ajustes na seção 5 ... É claro que eles provavelmente serão observados durante uma leitura cuidadosa, mas acho útil ver isso de relance para que eu possa mudar de marcha. se eu'

  Aqui está um exemplo de minhas ramificações e mescla de um artigo recente (eu uso o SourceTree no OS X e o Git na linha de comando no Linux). Você provavelmente notará que eu não sou o comentarista mais frequente do mundo nem deixo comentários úteis o tempo todo, mas isso não é motivo para você não seguir esses bons hábitos. A principal mensagem de referência é que trabalhar em filiais é útil. Meus pensamentos, idéias e desenvolvimento prosseguem de maneira não linear, mas posso acompanhá-los por meio de ramificações e mesclá-las quando estiver satisfeito (eu também tinha outras ramificações que não levaram a lugar algum que foram posteriormente excluídas). Também posso "marcar" os commits se eles significarem algo (por exemplo, envios iniciais para periódicos / envios revisados ​​/ etc.). Aqui, eu marquei a "versão 1", que é onde está o rascunho a partir de agora. A árvore representa uma semana '

  

• Outra coisa útil a ser feita é fazer alterações em documentos amplos (como alterar \alphapara \betaqualquer lugar) por conta própria. Dessa forma, você pode reverter as alterações sem precisar reverter outra coisa (existem maneiras de fazer isso usando o git, mas ei, se você pode evitá-lo, por que não?). O mesmo vale para acréscimos ao preâmbulo.

• Use um repositório remoto e faça as alterações com upstream regularmente. Com provedores de serviços gratuitos como GitHub e Bitbucket (ambos permitem criar repositórios particulares com uma conta gratuita), não há razão para não usá-los se você estiver trabalhando com Git / Mercurial. No mínimo, considere-o como um backup secundário (espero que você tenha um primário!) Para seus arquivos LaTeX e um serviço que permita continuar editando de onde você saiu em uma máquina diferente.

Eu tenho um fluxo de trabalho semelhante também. Embora um ramo esteja sendo trabalhado por vez, acho benéfico ter ramos separados para diferentes estados de trabalho. Por exemplo, imagine enviar um bom rascunho do seu artigo ao seu orientador. Então, você tem uma ideia maluca! Você quer começar a mudar alguns conceitos principais, refazer algumas seções principais etc. etc. Então, você se ramifica e começa a trabalhar. Seu ramo mestre está sempre em um estado "liberável" (ou o mais próximo que você está naquele momento). Portanto, enquanto seu outro ramo é louco e tem algumas mudanças drásticas, se outro editor quiser ver o que você tem ou se você é um aluno que está se submetendo a uma conferência, o ramo principal é sempre liberável, pronto para ir (ou pronto para mostrar seu orientador). Se o seu orientador de doutorado quiser ver o rascunho logo de manhã,

Digamos que seu ramo mestre tenha o estado "liberável" do seu trabalho. Agora você deseja enviá-lo para vários periódicos revisados ​​por pares, cada um com diferentes requisitos de formatação para o mesmo conteúdo e espera que eles voltem com várias pequenas críticas diferentes sobre como editar o artigo para caber em seus leitores, etc. Você pode criar facilmente uma ramificação para cada diário, fazer alterações específicas no diário, enviar e, quando receber o feedback, fazer as alterações em cada ramificação separada.

Também usei o Dropbox e o git para criar o sistema que você descreveu acima. Você pode criar um repositório básico na sua pasta dropbox. Você pode pressionar / puxar de qualquer computador para sua caixa de depósito para manter-se atualizado em todas as extremidades. Esse sistema geralmente só funciona quando o número de colaboradores é pequeno, pois existe a possibilidade de corrupção se as pessoas tentarem enviar para o repositório da caixa de depósito ao mesmo tempo.

Tecnicamente, você também pode manter UM repositório dentro da pasta dropbox e fazer todo o seu trabalho a partir daí. No entanto, eu desencorajaria isso, pois as pessoas mencionaram que o dropbox tem alguns problemas para sincronizar arquivos que estão constantemente mudando (arquivos internos do gits).

Tentei implementar isso como uma função bash, incluí-o no meu ~/.bashrcpara torná-lo sempre disponível.

function git-latexdiff {    
    if [[ $# != 2 ]];    
    then      
        printf "\tusage: git-latexdiff <file> <back-revision>  \n";    
    elif [[ $2 -lt 0 ]];     
    then     
        printf "\t<Back-revision> must be positive\n";   
    else      
        dire=$(dirname $PWD/$1);      
        based=$(git rev-parse --show-toplevel);      
        git show HEAD~$2:$(echo $dire| sed 's!'$(echo $based)'/!!')/$1 > $1_diff.tmp;      
        latexdiff $1 $1_diff.tmp > $1_diff.tex;      
        pdflatex $1_diff.tex;     
        okular $1_diff.pdf;      
        rm $1_diff*;   
    fi; 
}

Observe que essa função precisa latexdiffser instalada (e encontrada no caminho). Também é importante encontrar pdflatexe okular.

A primeira é a minha maneira preferida de processar o LaTeX, para que você possa alterá-lo latextambém. O segundo é o meu leitor de PDF, suponho que você queira usar evinceno gnome ou em alguma outra solução.

Esta é uma versão rápida, feita com um único documento em mente, e porque, com o git, você perderá muito tempo e esforço rastreando um documento LaTeX com vários arquivos. Você também pode deixar o git executar essa tarefa, mas se quiser, também pode continuar usando\include

Outra opção é usar o Authorea, que é algum tipo de Github para artigos científicos. Todo artigo no Authorea é um repositório Git. E o LaTeX que você compõe é renderizado em HTML5 (assim como em PDF, quando você compila).

use-o para a versão diff , caso esteja no Windows, sem parcelas, apenas um simplesbat script Ele funciona perfeitamente no windows10, miktex2.9:

https://github.com/redreamality/git-latexdiff