Blocco dei file binari usando il sistema di controllo della versione git

https://stackoverflow.com/questions/119444

02-07-2019
|

Domanda

Per un anno e mezzo, ho tenuto d'occhio la comunità git nella speranza di allontanarmi da SVN. Un problema particolare che mi trattiene è l'impossibilità di bloccare i file binari. Durante lo scorso anno non ho ancora visto gli sviluppi su questo tema. Comprendo che il blocco dei file è contrario ai principi fondamentali del controllo del codice sorgente distribuito, ma non vedo come un'azienda di sviluppo Web possa trarre vantaggio da Git per tenere traccia delle modifiche al codice sorgente e al file di immagine quando esiste il rischio di conflitti di file binari.

Per ottenere gli effetti del blocco, un "centrale" repository deve essere identificato. Indipendentemente dalla natura distribuita di git, la maggior parte delle aziende avrà un "centrale" repository per un progetto software. Dovremmo essere in grado di contrassegnare un file come richiedendo un blocco dal repository git di governo a un indirizzo specificato. Forse questo è reso difficile perché git tiene traccia dei contenuti dei file e non dei file?

Qualcuno di voi ha esperienza nella gestione di file git e binari che dovrebbero essere bloccati prima della modifica?

NOTA: sembra che il nuovo progetto di controllo della versione distribuita open source di Source Gear, Veracity, abbia il blocco come uno dei suoi obiettivi.

Soluzione

Git LFS 2.0 ha aggiunto il supporto per il file bloccaggio.

Con Git LFS 2.0.0 è ora possibile bloccare i file su cui si sta lavorando attivamente, impedendo ad altri di eseguire il push sul server Git LFS fino a quando non si sbloccano nuovamente i file.

Questo eviterà conflitti di unione e perdita di lavoro su file non unibili a livello di filesystem. Mentre può sembrare contraddire la natura distribuita e parallela di Git, il blocco dei file è una parte importante di molti flussi di lavoro di sviluppo software & # 8212; in particolare per i team più grandi che lavorano con risorse binarie.

Altri suggerimenti

Subversion ha i blocchi e non sono solo consultivi. Possono essere applicati utilizzando l'attributo svn: needs-lock (ma possono anche essere deliberatamente interrotti se necessario). È la soluzione giusta per la gestione di file non unibili. La società con cui lavoro per negozi praticamente tutto in Subversion e usa svn: needs-lock per tutti i file non unibili.

Non sono d'accordo con "i blocchi sono solo un metodo di comunicazione". Sono un metodo molto più efficace delle notifiche push come telefono o e-mail. I blocchi Subversion sono auto-documentati (chi ha il blocco). D'altra parte, se devi comunicare tramite altri canali di notifica push tradizionali, come l'e-mail, a chi invii la notifica? Non si conosce in anticipo chi potrebbe voler modificare il file, soprattutto su progetti open source, a meno che non si disponga di un elenco completo di tutto il team di sviluppo. Quindi quei metodi di comunicazione tradizionali non sono altrettanto efficaci.

Un server di blocco centrale, sebbene contrario ai principi di DVCS, è l'unico metodo possibile per i file non unibili. Finché DVCS non ha una funzione di blocco centrale, penso che manterrà la società per cui lavoro per l'utilizzo di Subversion.

La soluzione migliore sarebbe quella di creare uno strumento di unione per tutti i formati di file binari, ma si tratta di un obiettivo a lungo termine e in corso che non sarà mai "finito".

Ecco una lettura interessante sull'argomento.

Sono d'accordo che il blocco dei file binari sia una funzione necessaria per alcuni ambienti. Ho appena pensato a come implementarlo, però:

Avere un modo per contrassegnare un file come " needs-lock " (come la proprietà " svn: needs-lock ").
Al momento del pagamento, git contrassegnerebbe un file come di sola lettura.
Un nuovo comando git-lock contatterà un server di blocco centrale in esecuzione da qualche parte per chiedere l'autorizzazione a bloccare.
Se il server lock concede l'autorizzazione, contrassegnare il file read-write.
git-add informerebbe il server di blocco dell'hash del contenuto del file bloccato.
Il server di blocco controllerebbe che quell'hash del contenuto appaia in un commit sul repository principale.
Quando viene visualizzato l'hash, rilascia il blocco.

Questa è davvero un'idea a metà e ci sono potenziali buchi dappertutto. Va anche contro lo spirito di git, ma può certamente essere utile in alcuni contesti.

All'interno di una particolare organizzazione, questo genere di cose potrebbe forse essere costruito usando una combinazione adeguata di wrapper di script e hook di commit.

In risposta all'ulteriore preoccupazione di Mario per le modifiche che si verificano in più punti sui binari. Quindi lo scenario è Alice e Bob stanno entrambi apportando modifiche alla stessa risorsa binaria allo stesso tempo. Ognuno di essi ha il proprio repository locale, clonato da un telecomando centrale.

Questo è davvero un potenziale problema. Quindi Alice finisce prima e passa al ramo centrale alice / update . Normalmente quando ciò accade, Alice fa un annuncio che dovrebbe essere rivisto. Bob lo vede e lo recensisce. Può (1) incorporare tali modifiche da solo nella sua versione (ramificando da alice / update e apportando le sue modifiche a tale) o (2) pubblicare le proprie modifiche in bob / update . Ancora una volta, fa un annuncio.

Ora, se Alice spinge invece a master , Bob ha un dilemma quando tira master e cerca di unirsi al suo ramo locale. I suoi conflitti con quelli di Alice. Ma ancora una volta, la stessa procedura può essere applicata, solo su rami diversi. E anche se Bob ignora tutti gli avvertimenti e si impegna su di Alice, è sempre possibile estrarre l'impegno di Alice per sistemare le cose. Questo diventa semplicemente un problema di comunicazione.

Poiché (AFAIK) i blocchi Subversion sono solo consultivi, un messaggio di posta elettronica o un messaggio istantaneo potrebbero servire allo stesso scopo. Ma anche se non lo fai, Git ti consente di risolverlo.

No, non esiste alcun meccanismo di blocco in sé. Ma un meccanismo di blocco tende a sostituire semplicemente una buona comunicazione. Credo sia per questo che gli sviluppatori Git non hanno aggiunto un meccanismo di blocco.

Di recente abbiamo iniziato a utilizzare Git (precedentemente usato Subversion) e ho trovato una modifica al flusso di lavoro che potrebbe aiutare con il tuo problema, senza la necessità di blocchi. Sfrutta il modo in cui git è progettato e quanto sono facili i rami.

Fondamentalmente, si riduce a spingere verso un ramo non master, fare una revisione di quel ramo e quindi fondersi nel ramo principale (o qualunque sia il ramo di destinazione).

Il modo in cui git è " previsto " per essere utilizzato, ogni sviluppatore pubblica il proprio repository pubblico, dal quale richiede ad altri di estrarre. Ho scoperto che gli utenti di Subversion hanno problemi con questo. Quindi, invece, spingiamo verso gli alberi del ramo nel repository centrale, con ogni utente che ha il proprio albero del ramo. Ad esempio, una gerarchia come questa potrebbe funzionare:

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

Sentiti libero di usare la tua struttura. Nota sto anche mostrando rami di argomenti, un altro idioma git comune.

Quindi in un repository locale per l'utente a:

feature1
feature2

E per ottenerlo sul server centrale (origine):

git push origin feature1:users/a/feature1

(probabilmente questo può essere semplificato con le modifiche alla configurazione)

Ad ogni modo, una volta esaminata la funzionalità1, chiunque sia responsabile (nel nostro caso, è lo sviluppatore della funzionalità, potresti avere un singolo utente responsabile delle fusioni al master), procede come segue:

git checkout master
git pull
git merge users/name/feature1
git push

Il pull esegue un recupero (estraendo le nuove modifiche principali e dal ramo della funzione) e il master degli aggiornamenti in ciò che ha il repository centrale. Se un utente ha svolto il proprio lavoro e monitorato correttamente il master, non dovrebbero esserci problemi con l'unione.

Tutto ciò significa che, anche se un utente o un team remoto apporta una modifica a una risorsa binaria, viene riesaminato prima di essere incorporato nel ramo principale. E c'è una chiara delineazione (basata sul processo) su quando qualcosa va nel ramo principale.

Puoi anche far valere a livello di programmazione aspetti di questo usando git hook, ma, di nuovo, non ho ancora lavorato con questi, quindi non posso parlarne.

Quando stavo usando Subversion, ho impostato religiosamente la proprietà svn: needs-lock su tutti i file di testo binari e persino difficili da modificare. Non ho mai mai effettivamente avuto conflitti.

Ora, in Git, non mi preoccupo di queste cose. Ricorda: i blocchi in Subversion non sono in realtà blocchi obbligatori, sono semplicemente strumenti di comunicazione. E indovina un po ': non ho bisogno di Subversion per comunicare, posso gestirmi bene con e-mail, telefono e messaggistica istantanea.

Un'altra cosa che ho fatto è sostituire molti formati binari con formati di testo semplice. Uso reStructuredText o La & # 932; _{& # 917;} & # 935; invece di Word, CSV invece di Excel, ASCII-Art invece di Visio, YAML invece di database, SVG invece di OO Draw, abc invece di MIDI e così via.

Vale la pena esaminare il flusso di lavoro corrente per vedere se è davvero necessario bloccare le immagini. È relativamente insolito per due persone modificare autonomamente un'immagine e un po 'di comunicazione può fare molto.

Ho discusso di questo problema sui gruppi di discussione di Git e ho concluso che al momento non esiste un no metodo concordato per il blocco centralizzato dei file per git.

TortoiseGit supporta il flusso di lavoro git completo per i documenti di Office delegando diff a Office stesso. Funziona anche delegando a OpenOffice per i formati OpenDocument.

Non mi sarei mai aspettato che il blocco dei file lo rendesse una caratteristica di Git. A quale tipo di file binario sei interessato principalmente? Ti interessa davvero bloccare i file o semplicemente prevenire i conflitti causati dal fatto di non poterli unire.

Mi sembra di ricordare qualcuno che parla (o addirittura implementa) il supporto per la fusione di documenti OpenOffice in git.

E i file cad? Se i file non sono bloccati, per essere mantenuti di sola lettura, la maggior parte dei programmi cad li aprirebbe semplicemente cambiando bit arbitrari, visti come un nuovo file da qualsiasi vcs. Quindi, a mio avviso, il blocco è un mezzo ideale per comunicare l'intenzione di modificare alcuni file particalur. Inoltre, impedisce ad alcuni software di ottenere l'accesso in scrittura in primo luogo. Ciò consente gli aggiornamenti dei file locali, senza la necessità di chiudere il software o almeno tutti i file interamente.

Basta inserire un file di testo in cc con il file che si desidera bloccare e quindi rifiutare l'hook dell'aggiornamento.

Potrebbe essere vero, la riorganizzazione di un progetto può aiutare a evitare i blocchi, ma:

Le squadre sono organizzate anche in base ad altre priorità (posizione, clienti, ...)
Gli strumenti sono anche selezionati da altri target (compatibilità, prezzo, facilità d'uso da parte della maggior parte dei dipendenti)
Alcuni strumenti (e quindi i file binari) non possono essere evitati, in quanto non esiste semplicemente un sostituto che possa fare lo stesso lavoro, adattando lo stesso alle esigenze dell'azienda allo stesso prezzo.

Richiedere che un'intera azienda possa riorganizzare il proprio flusso di lavoro e sostituire tutti i suoi strumenti che producono file binari, solo per essere in grado di lavorare con git, a causa della mancanza di blocchi, sembra abbastanza inefficiente.

I lock non si adattano alla filosofia git (che non è mai stata fatta per i binari), ma ci sono situazioni non trascurabili, in cui i lock sono il modo più efficiente per risolvere un simile problema.

Questa non è una soluzione ma piuttosto un commento sul perché sono necessari meccanismi di blocco. Ci sono alcuni strumenti usati in alcuni campi che usano formati solo binari che sono assolutamente mission-critical e che "usano strumenti migliori / diversi" non è solo un'opzione. Non ci sono strumenti alternativi praticabili. Quelli con cui ho familiarità non sarebbero candidati per la fusione anche se hai archiviato le stesse informazioni in un formato ASCII. Un'obiezione che ho sentito è che vuoi essere in grado di lavorare offline. Lo strumento particolare a cui sto pensando in realtà non funziona comunque offline a causa della necessità di ottenere le licenze, quindi se ho i dati su un laptop non è come se potessi eseguire lo strumento su un treno comunque. Detto questo, ciò che git fornisce se ho una connessione lenta, posso ottenere licenze e anche abbattere le modifiche ma avere la copia locale veloce per guardare diverse versioni. Questa è una cosa carina che il DVCS ti offre anche in questo caso.

Un punto di vista è che git non è semplicemente lo strumento da usare, ma è bello per tutti i file di testo che sono anche gestiti con esso ed è fastidioso avere bisogno di strumenti di controllo della versione diversi per file diversi.

L'approccio del tipo di consulenza-blocco-via-posta puzza davvero. L'ho visto e sono stanco di un flusso infinito di e-mail di " lo sto modificando " " Ho finito di modificare " e ho visto i cambiamenti persi a causa sua. Il caso particolare a cui sto pensando è stato quello in cui una raccolta di file ASCII più piccoli sarebbe stata molto più bella ma a parte questo.

Non sto suggerendo di usare git nella mia compagnia per lo stesso problema. Utilizziamo EA per tutti i nostri progetti e Microsoft Word per la documentazione, non sappiamo in anticipo chi potrebbe modificare un determinato file, quindi il blocco esclusivo è la nostra unica opzione.

git funzionerà molto bene in un ambiente non di gruppo in cui ogni sviluppatore è l'unico responsabile di un pezzo di codice o file, perché in quel caso non è necessaria la comunicazione sui blocchi.

Se la tua organizzazione richiede un ambiente di squadra (di solito per rimuovere gli sviluppatori dalla sicurezza del lavoro), usa svn, git non fa per te. Svn fornisce sia il controllo del codice sorgente sia la comunicazione tra gli sviluppatori sui blocchi.

Git non fornisce alcun comando per bloccare i file, ma ho finanziato un modo per ottenere quella funzione usando git hook. È necessario un server ausiliario per memorizzare le informazioni sul blocco. È possibile utilizzare un hook di pre-commit per verificare se uno dei file di commit è bloccato. E se qualcuno blocca un file, un programma dovrebbe comunicare al server ausiliario le informazioni sull'armadietto e sul file bloccato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow