Compositore & compositore.blocco in GIT e i conflitti di unione
Ecco la nostra situazione :
Abbiamo 3 diversi Laravel progetti e tutti e 3 i progetti si basano sul nostro Core progetto.
Questo Nucleo centrale del progetto è separato Laravel pacchetto ospitato nella nostra repo e viene utilizzato come un dipendenza per altri progetti.
Prima, ogni volta che qualcosa potrebbe cambiare nel “cuore” del progetto si accendevano basta eseguire un compositore di aggiornamento ourvendor/ourcorepackage sui nostri server, per ogni progetto, per tirare le modifiche principali. Tuttavia, come ultimamente compositore sembra soffrire di gravi problemi di memoria quando si tenta di eseguire l’aggiornamento sul nostro Digital Ocean ambiente di gestione temporanea con 512 MB di Ram. Vedere : https://github.com/composer/composer/issues/1898
La soluzione che ho sempre incontrato è gente che dice che si dovrebbe sempre eseguire compositore installare sul vostro server di produzione. Posso riferire che in termini di sicurezza, perché può essere pericoloso se si esegue l’aggiornamento a una nuova versione di alcuni 3rd party pacchetto che può rompere il vostro codice. Ma nel nostro caso abbiamo solo aggiornare il proprio pacchetto di base, quindi sappiamo quello che stiamo facendo, ma questo problema di memoria ci impone di usare il compositore metodo di installazione perché è meno memoria esigenti.
Quindi, in pratica questo è il nostro flusso di lavoro corrente :
- Quando qualcosa cambia nel nostro pacchetto di base di cui abbiamo bisogno per eseguire un compositore
aggiornamento ourvendor/ourpackage su ogni progetto a livello LOCALE, Questo genera un
compositore.file di blocco - Ci impegniamo compositore.blocco di file nella nostra repo
- Sul server per ogni progetto, abbiamo una git pull ed eseguire un compositore
installare. Questo sarà solo un aggiornamento del pacchetto di base e corre molto più veloce
e non ha problemi di memoria vs compositore aggiornamento
Tuttavia questa soluzione genera 2 problemi :
- Dal momento che stiamo lavorando con più sviluppatori sullo stesso progetto che abbiamo, a volte, finiscono per avere conflitti di unione per il compositore.file di blocco quando si tira in modifiche a livello locale.
- Esecuzione di un git pull sul server dà un errore : le modifiche locali alle seguenti file verrà sovrascritto da unire: compositore.blocco
Si prega di eseguire il commit delle modifiche o stash prima di poter unire.
Quindi cosa dovrei fare qui? Prima di tirare su il server rimuovere il compositore.file di blocco?
Come gestire i conflitti di unione per il compositore.file di blocco?
È un peccato che il compositore aggiornamento soffre di problemi di memoria, perché tale metodo sembra molto più logico. Basta aggiornare il pacchetto che si desidera e senza problemi con il compositore.file di blocco..
Si prega di consulenza come un flusso di lavoro corretto con GIT e compositore dovrebbe essere, nel nostro caso, e come risolvere i conflitti di cui sopra ?
Molte grazie per il vostro input
Correlate: Dovrebbe compositore.blocco di impegnarsi per il controllo di versione?
InformationsquelleAutor cenob8 | 2014-09-08
Come si può verificare che un aggiornamento di base (o di qualsiasi altra dipendenza che viene aggiornato) non rompere le cose in progetti utilizzando, se lo sviluppatore non fare questo passo?
Ecco perché il solito flusso di lavoro è previsto il
composer update
essere eseguito su una macchina di sviluppo, di avere abbastanza RAM (cioè probabilmente più di 1GB di impostare come limite di memoria PHP), e l’aggiornamento dovrebbe essere attivato manualmente dal committente (e se attivato automaticamente da una continua integrazione di costruire, i requisiti di memoria di applicare per questa macchina).Non vi è alcun modo per aggirare questo requisito di memoria. Un server web con solo 512 MB di RAM installata potrebbe essere in grado di funzionare come un server di gestione temporanea con a malapena qualsiasi concorrente utenti presenti, ma non dovrebbe essere utilizzato per aggiornare il Compositore dipendenze.
Personalmente posso risolvere i conflitti di unione in
composer.lock
con un sistema molto semplice: Eliminare il file di blocco ed eseguirecomposer update
. Questo consentirà di aggiornare tutte le dipendenze per le ultime versioni che soddisfano i requisiti di versione, e creare un nuovo lavorocomposer.lock
file che si impegna durante la fusione.Non ho paura di aggiornare potenzialmente tutto, perché funziona come previsto, o il mio test di cattura rapidamente gli errori.
Faccio selezionare la 3 ° festa di pacchetti che uso con attenzione:
Questo funziona con circa 270 pacchetti serviti da locale Satis istanza (probabilmente anche un fattore da considerare quando si cerca di ridurre l’ingombro di memoria – solo i pacchetti noto Compositore può finire in memoria: Confrontare le decine di migliaia di pacchetti potenzialmente disponibili su packagist.org con 270 pacchetti locali). 60 pacchetti di 270 sono sviluppati a livello locale da 20 sviluppatori, e in modo casuale il rilascio di nuove versioni. L’aggiornamento fallimenti negli ultimi 2 anni sono molto rari, e dovrebbe essere trattato come gli altri bug: Se una versione codificata è rilevato di essere incompatibile il rilascio di una versione di bugfix annullando i cambiamenti, e tag originale cambiare con una nuova major release, se incompatibile il cambiamento è necessario.
In modo che il flusso di lavoro si chiedono è probabilmente in questo modo:
composer update
sulla propria macchina locale.composer.lock
file Gitcomposer install
e utilizzare esattamente le versioni che lo sviluppatore usato la sua macchina.Fusione tra una già impegnata versione su un altro sviluppatori macchina sarà probabilmente mostrare i conflitti di unione con
composer.lock
.composer.lock
il file deve essere eliminato.composer update
sulla sua macchina locale.Il compositore.bloccare il file deve essere eliminato. Che ne dite di un nuovo pacchetto aggiunto? Eliminazione di compositore.blocco portare a perdita di lavoro da un altro sviluppatore.
Per gestire correttamente i conflitti di unione con il compositore.la serratura è difficile. Eliminare il file non, poiché questo si possono installare diverse versioni, da quello che altri gli sviluppatori stanno utilizzando. Il compositore.file di blocco è stato progettato per tenere traccia di quali versioni sono installati e devono essere impegnati a git. Vedi: blog.theodo.fr/2013/03/resolving-composer-merge-conflicts
anni dopo quella risposta era scritto, migliori pratiche di emergere. D’altra parte, i progetti di aggiornare regolarmente le loro dipendenze e di avere abbastanza prove per trovare la risultante bug sono meno probabilità di essere colpiti da un conflitto di unione, anche se il rullo compressore tattiche di eliminare il file di blocco durante il merge è applicato.
Se un pacchetto è stato aggiunto, dovrebbe essere in
composer.json
. Esecuzione di un aggiornamento completo, verrà creato un nuovocomposer.lock
file che include tutto, dallacomposer.json
.InformationsquelleAutor Sven
Un altro approccio (senza fare
composer update
):composer.json
in un file di testo separato.composer.json
ecomposer.lock
file.composer install
composer require vendor/package:version
composer remove vendor/package
In questo modo blocca da remoto ramo (forse
master
odevelop
rami), e solo rielabora i tuoi nuovi pacchetti.InformationsquelleAutor Xover