Git è più utile per il controllo delle versioni dei file binari rispetto ai file di testo delle versioni? [chiuso]

Git non si preoccupa del contenuto dei file. Affatto. Memorizza un albero di directory ^* . Questo è tutto.

Memorizza i nomi di directory e file e il loro contenuto ma senza mai guardando il contenuto. Lo memorizza semplicemente e lo recupera, non ne sa nulla.

Esistono strumenti di livello superiore che consentono di mostrare le differenze tra le diverse versioni di un file o di unire modifiche divergenti tra rami diversi; questi strumenti di livello superiore ovviamente do devono conoscere il contenuto dei file. Git stesso viene fornito con alcuni strumenti che possono farlo efficacemente ed efficientemente con file di testo semi-strutturati, ma è banale configurare Git per avviare altri strumenti per altri tipi di file, ad es. MS Word per diffondere e fondere Office OpenXML Documenti di testo, avviare un programma di unione XML per file XML, avviare un programma di immagine diff per immagini, ecc.

^* In realtà, nemmeno questo è vero, Git è ancora più astratto e generale di così: Git immagazzina alberi di blob, questi blob non hanno realmente bisogno di corrispondere a file e alberi alle directory o cartelle.

git è principalmente un sistema di controllo del codice sorgente. La nicchia è che è davvero, davvero eccezionale per tenere traccia delle modifiche apportate ai file di testo e riuscire a reinserire tali cambiamenti logicamente quando i rami vengono uniti. Non può farlo con i file binari.

Pertanto, data la scelta, usa git per il controllo di file di testo su file binari. A volte non avrai scelta, ma il potere di Git risiede nella sua capacità di conciliare le modifiche del testo attraverso rami drammaticamente divergenti.

A volte si sente parlare di auto bloccate mentre si guida fuori strada. Non hai mai sentito parlare di case bloccate in quel modo. Significa che le case hanno una migliore mobilità delle auto? Ovviamente no! Non puoi bloccare la tua casa in un fuoristrada perché non puoi guidare la tua casa affatto .

A volte si ottengono conflitti di linea nei file di testo quando si uniscono i rami di Git, ma in realtà Git tenta effettivamente di fondere le righe per i file di testo. Non ottieni mai questi conflitti con i file binari perché Git non tenta mai di unirli in primo luogo.

Prova:

• Aggiungi una linea a un'immagine JPG in un ramo
• E aggiungi un'altra linea a un'area completamente diversa della stessa immagine in un altro ramo.
• Uniscali

Git era in grado di produrre un JPG con entrambe le nuove linee? No, semplicemente ti dice che c'è un conflitto e ti aspetta che tu faccia le cose manualmente. Se hai provato la stessa cosa con i file di testo, Git avrebbe cercato di unirli automaticamente. Potrebbe aver fallito, ma solo perché ci ha provato.

Come ha detto Jörg W Mittag nella sua risposta, puoi configurare Git per utilizzare gli strumenti di diff per determinati tipi di file. Se imposti il tuo Git per usare uno strumento di diff immagine per i file JPG, potrebbe essere in grado di produrre un JPG con entrambe le nuove linee - ma in alcuni casi potrebbe anche fallire e richiedere una risoluzione dei conflitti manuale, proprio come con i file di testo. Questo significa che installando questo strumento hai reso Git meno utile per JPG?

BTW: questa domanda non è così significativa. Di solito non dici "Ho un repository Git, ora ho bisogno di trovare i file alla versione". Di solito è il contrario: i file di cui hai bisogno per la versione e devi scegliere quale controllo del codice sorgente è meglio per loro. Quindi la questione non è come la gestione di Git dei file binari sia comparabile alla sua gestione dei file di testo - la domanda è come la gestione di Git dei file binari è paragonabile alla gestione dei file binari di altro sistemi di controllo della versione.

La versione che controlla i file binari nei sistemi di controllo della versione come GIT non è il miglior uso del software. Anche modifiche apparentemente minori possono portare a importanti cambiamenti nel file binario. Ciò aumenta significativamente la differenza tra il vecchio e il nuovo file, che è ciò che viene monitorato dal software.

GIT, SVN, CVS ecc. sono i migliori usati come sistemi di controllo del codice sorgente. Questi gestiscono i file sorgente che di solito hanno modifiche minori. Questi possono essere memorizzati in un set di modifiche relativamente piccolo. Cose come la riformattazione di un albero di sorgenti possono essere estremamente dirompenti in quanto le diverse dimensioni possono aumentare drasticamente, e diventa difficile trovare cambiamenti semantici tra le versioni.

GIT è molto più capace di gestire dati binari. Tuttavia, non sarà in grado di estrarre la differenza semantica da questi file. Ha poco senso agli artefatti generati dal controllo della versione come i file .class.

Per i file di documentazione, può essere più sensato usare un file di testo in un linguaggio di marcatura comune. Questi possono essere facilmente gestiti con un sistema di controllo del codice sorgente. Riduce inoltre i problemi relativi alle discrepanze tra la versione del documento e il software che la legge.