Flusso di lavoro: utilizzo di formati binari di documenti in Git senza blocchi (passaggio da sovversione)

Siamo una società di consulenza software con una moltitudine di progetti per clienti diversi. Tradizionalmente utilizziamo Subversion, ma al momento stiamo valutando la possibilità di passare a Git.

Una parte significativa dei documenti che produciamo sono condivisi con i nostri clienti (requisiti, progetti globali, specifiche di prova, ecc.) E utilizziamo MS Office per produrli. In Subversion, potremmo usare la sua funzione "Blocca" per assicurarci che nessuno stesse modificando lo stesso documento contemporaneamente. In Git, non puoi farlo poiché per sua natura distribuita, git non ha i blocchi.

Le serrature sono in realtà poco più che un meccanismo di comunicazione, ma sono molto efficaci.

Attualmente, il nostro codice e i documenti rivolti al cliente sono in genere in diverse sottocartelle di un repository svn diverso. Quando passi a Git, cosa consiglieresti di fare? Vedo una serie di opzioni:

1. Spostiamo i repository svn su git 1-on-1. Invece di usare i blocchi sui file di Office, facciamo ciò che le persone git suggeriscono e in qualche modo proviamo a cambiare il nostro flusso di lavoro per risolverlo. Questo potrebbe funzionare in una succursale su qualsiasi modifica del documento e unire la revisione. Questo approccio interrompe, ad esempio, i fogli Excel che contengono informazioni sulla gestione del progetto; sono facilmente modificabili dai membri del team (e lo incoraggiamo a farlo), ma non sono soggetti a alcun processo di revisione formale

2. Usiamo git per il codice e svn per i documenti e la gestione dei progetti. Questo ha lo svantaggio che certi documenti più designati non saranno "vicini" al codice specificato, aumentando la possibilità che le persone dimentichino di aggiornarli. Inoltre, tutti devono usare e comprendere due set di strumenti. Detto questo, forse questa è una grande opportunità per passare a strumenti per documenti basati su testo (latex, markdown, HTML, qualunque cosa) per documenti di progettazione non rivolti al cliente.

3. Come 1, ma hackeriamo un git lockcomando che fa ciò che fa svn lock per noi (attiva il flag di sola lettura in modo appropriato e sincronizzalo con un server in qualche modo).

Non compro l'argomento secondo cui i blocchi non funzionano in un DVCS perché il sistema dovrebbe funzionare anche quando sei completamente offline. Anche i blocchi Svn possono essere ignorati; sono un meccanismo di comunicazione . Senza una sorta di connessione di rete, il tuo computer non comunicherà molto.

Non possiamo essere l'unico negozio a essere molto soddisfatto di come si svn lockadatta al nostro flusso di lavoro, giusto?

Qualche idea o consiglio?

Ho trovato /programming/119444/locking-binary-files-using-git-version-control-system ma la discussione è piuttosto tecnica; sto cercando modi per risolvere o evitare il problema pratico di due membri del team che modificano lo stesso file binario allo stesso tempo.

Ti consiglierei di rimanere con SVN per i documenti di MS Office per due motivi:

1. È già lì ed è (secondo me) migliore per conservare i documenti di Office (guarda qui ). Ha molti più strumenti di terze parti per farlo.
2. Il blocco, sebbene possa essere raggiunto in Git, non è "il tipo di modo Git di fare le cose". Se hai bisogno di queste funzionalità, segui lo strumento che ti offre la soluzione migliore.

C'è un detto che mi piace che dice qualcosa del genere: "Quando hai in mano un martello, tutto sembra un chiodo". Solo perché ti stai trasferendo su Git per conservare il tuo codice, ciò non significa che dovresti usarlo per conservare i tuoi documenti.

Il controllo della versione del codice non è lo strumento migliore per lavorare sui file di Office, perché sono binari e questi strumenti funzionano sulla modifica a livello di file.

Utilizzare uno strumento di collaborazione, come MediaWiki (gratuito) o Atlassian Confluence (a pagamento), da cui è possibile estrarre facilmente documenti Word. Oppure utilizza LaTex per generare i file di Office.

Fammi espandere ...

Se è necessario collaborare, è necessario adottare un modello che evidenzi le modifiche (ad esempio una parola cambiata, riformulata o semplicemente modificata un carattere) in un'unità, ad esempio un file.

SVN e Git, anche se pensati per il codice, sono strumenti di basso livello che confrontano i loro file in base al contenuto testuale. Ma il problema è che possono funzionare solo su file di testo, perché non si preoccupano della natura / dei contenuti del file per estrarre un modello di modifiche di alto livello.

Un chiaro esempio è un file di immagine . Sebbene TortoiseMerge sia uno strumento che aiuta gli utenti di SVN confrontando le immagini per le loro reali modifiche, le normali sono VCSgestite da patch di contenuto sui file. Lasciatemi spiegare. Uno strumento come TortoiseMerge può dirti che una nuova versione di un file di immagine viene modificata solo di pochi pixel o luminanza se implementa un'analisi HSV più complessa dei due file. Puoi aggiungere una filigrana o cambiare i livelli di colore, uno strumento che confronta i file di immagine ti metterà in evidenza le differenze se implementa un buon algoritmo di confronto. Ma per controllare il nuovo file nel tuo client deveprodurre un delta. Un delta è un insieme di linee rimosse e di linee aggiunte al file. I file binari non hanno interruzioni di riga se non accadere di avere \r\n, o simili, a loro carico, e in un delta se si cambia un singolo carattere si sta sostituendo un'intera linea.

Quindi qui è il problema. I file binari non sono utili per il controllo della versione perché potresti quasi sostituire l'intero file per ogni revisione. Considerare quando si scrivono file di Office utilizzando MS Office e le modifiche del proprio collaboratore con OpenOffice. Se implementano anche una versione leggermente diversa dell'algoritmo di compressione dei file OpenXML, finirai in file completamente diversi anche se hai modificato una singola virgola nel documento.

I software di collaborazione rendono i documenti internamente in un formato basato su testo, poiché il testo è ciò che è veramente significativo per la tua azienda e può calcolare le differenze o gestire i conflitti. LaTex, o Markdown, se lo desideri, è un modo per archiviare un documento come file testuale con markup avanzato, quindi non come il classico file TXT che non ha controllo di font / formattazione.

Ma ovviamente i tuoi clienti non vorranno aprire i file Markdown, vero? Ok, puoi semplicemente, e intendo semplicemente, usare qualsiasi software per il quale sono attualmente troppo pigro per google per convertire un documento sorgente in PDF, Word o altro.

Riassumendo

Se inizi a controllare i file di testo nel controllo del codice sorgente, hai un maggiore controllo sulla cronologia dei file e puoi gestire facilmente i conflitti, specialmente senza usare i blocchi VCS.

Prima di condividere ufficialmente un documento, è necessaria una routine per esportare il documento di testo di origine in un file di Office

Separare i due passaggi rende le persone felici al costo di una curva di apprendimento.

Puoi usare git per quei documenti senza aggiungere il blocco. Scegli un flusso di lavoro git che blocchi gli push al ramo principale se non sul master. (Esistono diversi flussi di lavoro tra cui scegliere.) Ciò impedirà alle persone di sovrascrivere le reciproche modifiche ai file binari di documenti. Supponiamo che due persone modifichino lo stesso documento binario. Il primo che lo spinge al master riceve le modifiche. Il secondo verrà bloccato perché la loro copia è dietro il ramo master. Devono prima sincronizzarsi. Quindi la seconda persona si sincronizza. Mostrerà un conflitto di unione per il documento binario. Quella persona salva la propria versione da qualche parte e risolve il conflitto prendendo la versione dal master (che è stata spinta dalla prima persona). A questo punto i file della seconda persona sono aggiornati con il ramo principale. Si uniscono nelle loro modifiche all'ultimo documento binario (a mano), che conterrà le modifiche sia della prima persona che della seconda persona. Quindi la nuova versione viene inviata al master e diventa il nuovo ramo master. La fusione è un dolore, ma succede solo quando c'è un conflitto. Inoltre, le modifiche non vengono perse o sovrascritte. I conflitti vengono rilevati e gli utenti sono in grado di risolverli in modo pulito.

Metti insieme le tue prime 2 soluzioni e non hai bisogno di un terzo.

Se salvi i tuoi fogli di calcolo su disco come CSV, Excel li modificherà comunque e git sarà felice di unirli per te.

Allo stesso modo, puoi aprire, modificare e salvare i tuoi file in Word se sono HTML o (godici) RTF. Word ovviamente aggiungerà più spazio di testo utile, ma è ancora solo testo che Git è felice di unire per te.

Certo, queste soluzioni presuppongono che non si faccia uso o che si possa allontanarsi dalle funzionalità specifiche per MS che è davvero solo un problema sul lato Excel.

A meno che ovviamente non sia necessario che Word sia installato su un sistema per poter leggere la documentazione, che è di per sé una prospettiva terrificante per me ...