Fluxo de trabalho: Usando formatos binários de documentos no Git sem bloqueios (saindo do subversion)

Somos uma consultoria de software com uma infinidade de projetos para diferentes clientes. Tradicionalmente usamos o Subversion, mas atualmente estamos pensando em mudar para o Git.

Uma parte significativa dos documentos que produzimos é compartilhada com nossos clientes (requisitos, projetos globais, especificações de teste, etc.) e usamos o MS Office para produzi-los. No Subversion, poderíamos usar o recurso "Bloquear" para garantir que ninguém estivesse editando o mesmo documento ao mesmo tempo. No Git, você não pode fazer isso, pois, por sua natureza distribuída, o git não possui bloqueios.

Os bloqueios são realmente pouco mais que um mecanismo de comunicação, mas são muito eficazes.

Atualmente, nosso código e documentos voltados para o cliente estão tipicamente em subpastas diferentes de um repositório svn diferente. Ao mudar para o git, o que você recomendaria que fizéssemos? Eu vejo um conjunto de opções:

1. Nós movemos os repositórios svn para o git 1-on-1. Em vez de usar bloqueios nos arquivos do Office, fazemos o que o pessoal do git sugere e, de alguma forma, tentamos alterar nosso fluxo de trabalho para corrigi-lo. Isso pode estar funcionando em uma ramificação em qualquer edição de documento e mesclando isso na revisão. Essa abordagem é interrompida, por exemplo, em planilhas do Excel que contêm informações de gerenciamento de projetos; eles são editados facilmente pelos membros da equipe (e recomendamos que isso seja feito), mas não estão sujeitos a nenhum processo formal de revisão

2. Usamos git para código e svn para documentos e gerenciamento de projetos. Isso tem a desvantagem de que alguns documentos mais sofisticados não estarão "próximos" do código especificado, aumentando a chance de as pessoas esquecerem de atualizá-los. Além disso, todo mundo precisa usar e entender dois conjuntos de ferramentas. Dito isto, talvez seja uma ótima oportunidade para migrar para ferramentas de documentos baseadas em texto (látex, descontos, HTML, o que for) para documentos de design que não sejam voltados para o cliente.

3. Como o 1, mas criamos um git lockcomando que faz o que o svn lock faz por nós (alterne o sinalizador somente leitura de forma apropriada e sincronize com o servidor por alguns meios).

Não acredito no argumento de que os bloqueios não funcionam em um DVCS porque o sistema deve funcionar mesmo quando você está totalmente offline. Os bloqueios de SVN também podem ser substituídos; eles são um mecanismo de comunicação . Sem algum tipo de conexão de rede, o computador não se comunica muito.

Não podemos ser a única loja que está muito feliz com a forma como svn lockse encaixa no nosso fluxo de trabalho, certo?

Alguma idéia ou dicas?

Encontrei /programming/119444/locking-binary-files-using-git-version-control-system, mas a discussão é bastante técnica; Estou procurando maneiras de resolver ou evitar o problema prático de dois membros da equipe editando o mesmo arquivo binário ao mesmo tempo.

Aconselho você a ficar com o SVN para os documentos do MS Office por dois motivos:

1. Já está lá e é (na minha opinião) melhor para manter os documentos do Office (veja aqui ). Tem muito mais ferramentas de terceiros para fazer isso.
2. O bloqueio, embora possa ser alcançado no Git, não é "o tipo de maneira que Git faz as coisas". Se você precisar desses recursos, use a ferramenta que oferece a melhor solução.

Há um ditado que eu gosto que diz algo assim: "Quando você está segurando um martelo, tudo parece um prego". Só porque você está migrando para o Git para manter seu código, isso não significa que você deve usá-lo para manter seus documentos.

O controle de versão de código não é a melhor ferramenta para trabalhar com arquivos do Office, porque eles são binários e essas ferramentas funcionam na modificação no nível do arquivo.

Use uma ferramenta de colaboração, como MediaWiki (grátis) ou Atlassian Confluence (pago), da qual você pode extrair facilmente documentos do Word. Ou use o LaTex para gerar os arquivos do Office.

Deixe-me expandir ...

Se você precisar colaborar, deve adotar um modelo que destaque as modificações (por exemplo, alterou uma palavra, reformulou ou apenas mudou uma fonte) em uma unidade, por exemplo, um arquivo.

O SVN e o Git, mesmo que pensem no código, são ferramentas de baixo nível que comparam seus arquivos pelo conteúdo textual. Mas o problema é que eles podem funcionar apenas em arquivos de texto, porque não se importam com a natureza / conteúdo do arquivo para extrair um modelo de modificações de alto nível.

Um exemplo claro é um arquivo de imagem . Embora o TortoiseMerge seja uma ferramenta que ajuda os usuários do SVN comparando as imagens com suas modificações reais, o normal VCSé executado por correções de conteúdo nos arquivos. Deixe-me explicar. Uma ferramenta como o TortoiseMerge pode dizer que uma nova versão de um arquivo de imagem é alterada apenas por alguns pixels, ou luminância, se implementar uma análise HSV mais complexa dos dois arquivos. Você pode adicionar uma marca d'água ou mudar a cor níveis, uma ferramenta que compara os arquivos de imagem irá destacar-lhe as diferenças se implementa bom algoritmo de comparação. Mas, para verificar o novo arquivo em seu cliente, é necessárioproduza um delta. Um delta é um conjunto de linhas removidas e adicionadas ao arquivo. Arquivos binários não têm quebras de linha se não acontecer de ter \r\n, ou similar, em sua carga útil, e em um delta se você mudar um único caractere que você está substituindo uma linha inteira.

Então aqui está o problema. Os arquivos binários não são bons para o controle de versão, pois você pode estar quase substituindo o arquivo inteiro para cada revisão. Considere ao escrever arquivos do Office usando o MS Office e o seu colaborador edite com o OpenOffice. Se eles implementarem uma versão ligeiramente diferente do algoritmo de compactação dos arquivos OpenXML, você terminará em arquivos completamente diferentes, mesmo que tenha alterado uma única vírgula no documento.

Os softwares de colaboração processam documentos internamente em um formato baseado em texto, porque o texto é realmente significativo para sua empresa e pode calcular as diferenças ou lidar com conflitos. LaTex, ou Markdown, se você preferir, é uma maneira de armazenar um documento como um arquivo de texto com marcação avançada, portanto, não como o arquivo TXT clássico que não tem controle de fonte / formatação.

Mas obviamente seus clientes não vão gostar de abrir arquivos Markdown, vão? Ok, você pode simplesmente, e realmente quero dizer, simplesmente usar qualquer software que eu esteja com preguiça de procurar no Google para converter um documento de origem em PDF, Word ou qualquer outra coisa.

Resumindo

Se você começar a verificar arquivos de texto em seu controle de origem, terá maior controle sobre o histórico de arquivos e poderá gerenciar facilmente conflitos, especialmente sem usar bloqueios VCS.

Antes de compartilhar um documento oficialmente, você precisa de uma rotina para exportar o documento de texto de origem para um arquivo do Office

Separar as duas etapas deixa as pessoas felizes à custa de uma curva de aprendizado.

Você pode usar o git para esses documentos sem adicionar bloqueio. Escolha um fluxo de trabalho git que bloqueie os envios para a ramificação principal, se não estiver na master. (Existem vários fluxos de trabalho para escolher.) Isso impedirá que as pessoas substituam as modificações umas das outras em arquivos de documentos binários. Suponha que duas pessoas modifiquem o mesmo documento binário. O primeiro que o pressiona para o mestre obtém as alterações. O segundo será bloqueado porque a cópia está atrás do ramo mestre. Eles precisam sincronizar primeiro. Então a segunda pessoa sincroniza. Ele mostrará um conflito de mesclagem para o documento binário. Essa pessoa salva sua versão em algum lugar e resolve o conflito retirando a versão do master (que foi enviada pela primeira pessoa). Nesse ponto, os arquivos da segunda pessoa estão atualizados com a ramificação principal. Eles mesclam suas alterações no último documento binário (à mão), que conterá as alterações da primeira e da segunda pessoa. Em seguida, a nova versão é empurrada para mestre e se torna o novo ramo mestre. A fusão é uma dor, mas só acontece quando há um conflito. Além disso, as alterações não são perdidas ou substituídas. Os conflitos são detectados e os usuários podem resolvê-los de maneira limpa.

Coloque suas duas primeiras soluções juntas e você não precisa de uma terceira.

Se você salvar suas planilhas em disco como CSVs, o Excel ainda as editará e o git ficará feliz em mesclá-las para você.

Da mesma forma, você pode abrir, editar e salvar seus arquivos no Word se eles forem HTML ou (Deus nos ajude) RTF. É claro que o Word adicionará mais inchaço do que o texto útil, mas ainda é apenas o texto que o git terá prazer em mesclar para você.

É verdade que essas soluções pressupõem que você não faz uso ou pode se afastar dos recursos específicos do MS, o que é realmente apenas um problema no lado do Excel.

A menos, é claro, que você também exija que o Word seja instalado em um sistema para poder ler sua documentação, o que em si é uma perspectiva terrível para mim ...