Rendere Git mantenere contenuto di sezione diversa tra filiali

Sto sviluppando un UserScript che i miei datori di lavoro mi hanno chiesto di iniziare a gestire tramite Git.

Al momento, ho un file stabile e un file beta, in modo che tutti i membri dell’organizzazione possano installare il codice stabile, ma possono scegliere di testare le aggiunte beta, se lo desiderano. Alcune parti di quel file dovrebbero rimanere diverse, il contenuto e le modifiche non dovrebbero essere unite tra i rami.

Ad esempio, se converto il file Beta in un Git Branch, e in seguito decido che le modifiche Beta sono stabili e unisco nuovamente la Beta nel codice Stabile (che non sarà cambiato) il processo Git Merge come ho capito sarà “utile “aggiorna le intestazioni di definizione Stable Greasemonkey sulla base dei valori presenti su quelle linee nel ramo Beta. Questo è assolutamente indesiderabile, poiché queste intestazioni contengono un URL di aggiornamento automatico che Greasemonkey controllerà per gli aggiornamenti.

// ==UserScript== (stable) // @downloadURL -- StableURL File Location // ==/UserScript== // ==UserScript== (beta) // @downloadURL -- BetaURL File Location // ==/UserScript== >Git Merge< // ==UserScript== (stable) // @downloadURL -- BetaURL File Location // ==/UserScript== 

Voglio mantenere la possibilità di avere URL distinti tra il codice Beta e il codice Stable, ma non sono stato in grado di identificare un metodo per far sì che il processo di fusione di Git ignori le righe che Greasemonkey deve fare correttamente, ma se non lo faccio t avere la Beta come una Filiale separata, non sono sicuro di come usare Git per migrare facilmente il codice modificato da Beta a Stabile, che è il motivo dichiarato per chiedermi di adottare la funzionalità Git. (Beh, l’altra ragione è rendere più facile per gli altri contribuire e identificare la storia del progetto …)

Ogni aiuto è molto apprezzato.

Tutte le modifiche devono essere unite, tranne le modifiche a tali valori, che li rendono non come gli altri, non le modifiche al contenuto intrinseco, ma le modifiche specifiche della distribuzione. Questi potrebbero essere meglio applicati nel hook post checkout. Ecco un esempio, un processore include per ramo

 cat <<\EOF >.git/hooks/post-checkout #!/bin/sh if branch=`git symbolic-ref HEAD --short -q`; then for file in `git ls-files -cix*[email protected]`; do echo "* making ${file%[email protected]} from $file with branch-specific includes" echo '/^@include-branch-specific ([az/]*)$/ { s//cat \1.'$branch'/e }' \ | sed -rf- $file >${file%[email protected]} done fi EOF chmod +x .git/hooks/post-checkout 
 # testing git checkout beta cat <<\EOF >[email protected] // ==UserScript== @include-branch-specific config // ==/UserScript== EOF echo >config.stable '// @downloadURL -- StableURL File Location' echo >config.beta '// @downloadURL -- BetaURL File Location' git add config.* # git rm --cached config git commit -m'setting up per-branch configs' git checkout git checkout stable git cherry-pick beta git checkout 

Nel tuo repository, crea tre file, chiamati header.master , header.branch e main.js Quindi puoi mantenere diverse versioni di main.js in rami diversi, ma mantenere i file di intestazione uguali – uno per ogni ramo, e tutti i file di intestazione saranno in tutti i rami.

Crea uno script di compilazione, chiamato build.sh , che assomiglia a questo:

 #! /bin/sh cat header.$(git rev-parse --abbrev-ref HEAD) main.js >myscript.js 

Entrambi gli utenti devono eseguire il tuo script di build, oppure devi fornire lo script utente predefinito da te – ma suppongo che tu stia già facendo quest’ultimo, dato che hai un URL di download!

Potresti scrivere un driver di fusione personalizzato per git e configurare git per usarlo, ma questo probabilmente sarebbe più un problema che non ne vale la pena.

Elimina la riga @downloadURL da tutti i file.

Dalla documentazione di @downloadURL , quando la riga viene omessa, Greasemonkey controllerà l’URL da cui è stato originariamente caricato lo script, per gli aggiornamenti. Gli utenti della versione verranno aggiornati dalla posizione di rilascio e gli utenti beta si aggiorneranno dalla posizione beta.

Se un utente vuole passare da un ramo all’altro, elimina solo lo script e poi carica dal ramo appropriato.

Allo stesso modo, gli script non dovrebbero avere @updateURL una riga @updateURL .