Risorse, fusione di rami Git e rilasci
Ognuno ha un flusso di lavoro git diverso, ma ai fini di questo post, supponi di avere qualcosa di simile al seguente:
- Una filiale in cui risiedono tutti i tuoi beni, non costruiti.
- Un sistema di integrazione continua che costruisce gli asset e crea un nuovo ramo o forse una nuova versione.
- Un ramo creato dal sistema di integrazione continua che contiene gli asset costruiti.
Il componente principale di questo flusso di lavoro è il sistema di integrazione continua. Cioè, se fallisce, il lavoro responsabile della costruzione degli asset e della creazione di una nuova filiale non funziona più.
E quando ciò accade, dobbiamo farlo manualmente. È noioso, certo, ma non difficile. Se ti trovi in questa posizione, ecco come puoi creare risorse, unire rami git e creare una versione con versione.
Unire rami Git
Per questo post, supponi di avere uno strumento di creazione configurato responsabile della compilazione delle tue risorse. Questo può essere uno degli strumenti disponibili, ma ne userò vari npm
per dimostrare il punto.
1 Configurare il ramo di origine
Il ramo di origine include tutte le risorse non costruite. Essenzialmente, questi sono tutti i sorgenti JavaScript grezzi, i fogli di stile e qualsiasi altro componente correlato al front-end che non è stato creato.
Una volta che il codice è pronto, può essere compilato e assegnato a qualsiasi ramo su cui stai lavorando. Per il bene di questo articolo, lo chiameremo develop
.
Dopo aver eseguito tali modifiche, è necessario modificare i rami nel built
ramo.
2 Unire il ramo di origine nel ramo costruito
Una volta che siamo sul ramo creato, possiamo costruire tutte le risorse (di nuovo, usando lo strumento che funziona meglio per te). Ma prima di farlo, dobbiamo assicurarci di portare il lavoro nel built
ramo dal develop
ramo.
In altre parole, dobbiamo unirci develop
anche develop-built
se il codice develop-built
potrebbe essere – o probabilmente non sarà aggiornato dopo l’unione.
Quindi eseguiamo effettivamente i comandi necessari per costruire gli asset, aggiungerli e inviarli al ramo e quindi spingiamo il nuovo lavoro:
Questo ora ci dà un ramo, develop
con tutti i sorgenti grezzi e un ramo, develop-built
che possiamo usare per taggare i nostri rilasci.
3 Tagga il ramo costruito
A questo punto, potresti semplicemente voler taggare develop-built
come una versione con versione, potresti voler unirla master
o qualunque sia il caso. Se, tuttavia, desideri mantenere due tag separati, uno per il tag di origine e uno per il tag di rilascio effettivo, potresti volerlo fare taggando develop
e develop-built
prima di eseguire qualsiasi ulteriore unione.
In particolare, puoi taggare develop
come fonte con versione:
E develop-built
come la versione taggata:
A questo punto, puoi unirlo al master
ramo o qualunque sia il ramo principale che scegli di mantenere. Se stai usando Composer, tuttavia, probabilmente vorrai fare riferimento alle versioni con versione, quindi è qui che puoi utilizzare la scheda.
Nota finale
Tieni presente che il tuo flusso di lavoro può, e probabilmente lo fa, variare. Forse usi rami, forse usi tag, forse usi una combinazione dei due come sopra.
Il punto non è dire come dovresti farlo ma, in definitiva, come unire i rami git in modo che il tuo ramo di origine possa farsi strada nel ramo costruito in modo da poter creare le risorse e modificarle secondo necessità.