Come devo controllare le versioni del mio progetto su GitHub

Sto cercando di passare più tempo possibile su GitHub al giorno d'oggi (anche io sono l'unica persona in squadra al lavoro) a sentire davvero come sarà per un'applicazione aziendale nel mondo reale.

Una domanda che sto avendo è di controllare la versione . Diciamo che abbiamo avviato un progetto. Quindi, i membri del team hanno creato alcune filiali e si sviluppano lì. Quando siamo pronti per la produzione, abbiamo unito tutti i rami con il masterramo. Alla fine, andiamo in diretta con la versione 1.0.

Ora quella versione 1.0è in diretta e abbiamo alcuni problemi archiviati per quella versione di quel software. Vorremmo iniziare a sviluppare la versione 1.1per risolvere quei problemi che abbiamo introdotto affrettando il progetto.

Ora, la domanda è questa:

Come dovremmo controllare il controllo delle versioni qui?

Dovremmo creare un nuovo ramo v1.0e mantenere 1.0lì la versione del software e svilupparci su alcuni rami (o no), unirli con loro master, andare in diretta con la versione 1.1?

Esiste una convenzione là fuori per questo tipo di situazioni?

— tugberk
fonte

Risposte:

Ho trovato (e iniziato ad adottare) il seguente modello di filiale :

Immagine da nvie.com

^{(immagine dall'articolo)}

Ci sono molte buone pratiche e regole rigorose descritte in quell'articolo, lo consiglio vivamente.

Punti di interesse:

Il ramo principale è dove tagghi le tue versioni. Nessuno sviluppo accade qui. In caso di un bug che è stato distribuito in produzione, si corregge il bug su un ramo di hotfix, si unisce nuovamente e si tag una nuova versione.
Lo sviluppo avviene sullo sviluppo e sui rami delle caratteristiche. Personalmente, correggo i bug sul ramo di sviluppo e le funzioni sui rami di funzionalità.
Quando il software inizia a raggiungere un rilascio, mi dirigo per rilasciare il ramo. Il ramo di rilascio è dove faccio gli ultimi ritocchi. Bump numeri di versione, modifica metadati ecc. E correzioni di bug minori. Quando è finito, lo unisco a master, tag e lo chiamo una versione.
I due rami principali: il maestro è il "ramo santo"; il suo HEAD è sempre l'ultimo codice di produzione e lo sviluppo è il ramo notturno; HEAD riflette sempre le ultime (ma possibili instabili) aggiunte al codice.

Nel tuo caso specifico, i passaggi dipenderebbero da quanto era affrettata quella versione. Se sono le caratteristiche che sono state lasciate fuori, tornerei alla versione di sviluppo e farei di nuovo tutto. Se si tratta di bug nella versione distribuita, vorrei passare a un ramo di hotfix, correggere i bug, ricollegarli e taggare v1.1. Se è entrambe le cose, correggo prima i bug, quindi aggiungo le funzionalità secondo come descritto.

— Tamás Szelei
fonte

Molto informativo e dettagliato. E anche una pratica perfetta. Ha anche molto senso. Avere padrone per il prod rende solo facile da mantenere. Non ho familiarità con l'etichettatura di un ramo (o il commit?). Puoi darmi qualche dettaglio a riguardo? come possiamo fare secondo il modello sopra?

— rimorchiatore

In git, l'obiettivo del tagging è un commit. Significa che dici: "ecco questo commit, e lo chiamo 'v1.3' da ora in poi". In pratica ciò significa che si passa al ramo principale, unendo il ramo di sviluppo (ora stabile), commit e tag. Quindi puoi elencare tutti i tag, ripristinare quel codice nel caso in cui hai bisogno di vedere cosa è andato in produzione in una versione passata. C'è un po 'più di tag rispetto a quello (che è utile per lo sviluppo distribuito su larga scala come il kernel Linux). Se sei interessato, ti suggerisco il libro dei programmi .

— Tamás Szelei,

ProGit è uno dei libri che leggerò sicuramente da zero. Per ora sto solo leggendo le parti che mi interessano per portare a termine il lavoro. Finora ci siamo sviluppati sul ramo principale e penso che dovrei mantenerlo. Ma aprirò un altro ramo chiamato productione lo userò come masterramo secondo il modello sopra.

— Tugberk,

mentre sto provando questo modello, una cosa che sto lottando è che: ci sono alcuni rami di supporto come discusso in un articolo, funzionalità e rami di rilascio. possono esserci più filiali future. Ad esempio, FeedbackForm è un ramo futuro e ContactForm è un altro. Questo va bene per questo modello immagino? Dovrebbero esserci anche più filiali di rilascio? e se sì, come dovrei nominarli?

— rimorchiatore

Prima di tutto, non è necessario seguirlo alla lettera, basta avere regole stabilite che si mantengono. Fai ciò che è meglio per te e lo stile della tua squadra. In secondo luogo, sì, più rami di funzionalità e rilascio sono normali a meno che tu non abbia un progetto di breve durata con una funzione e un rilascio :). La denominazione, secondo l'articolo, è release- * e feature- *. Immagino che tu abbia inserito il numero della versione futura al posto dell'asterisco per il rilascio e l'id del tracker dei problemi nel caso dei rami delle funzionalità.

— Tamás Szelei,

Quello a cui ho assistito la maggior parte delle volte è:

Master è per il tuo prodotto. Alla fine tutta la tua futura versione x.0 sarà sul master.
Si crea un tag / ramo per ogni versione in produzione in modo da poterle ancora supportare per qualsiasi cliente che lo richieda.
Unire le correzioni dall'uno o dall'altro significa trattare in base al caso.

— xsace
fonte

Grazie! quindi pensi che sia ragionevole mantenere un ramo chiamato v1.0, v1.2 è ragionevole?

— Tugberk

@tugberk fintanto che esiste il software corrispondente in quella versione, ha senso mantenere i rami in giro in modo da essere in grado di eliminarli rapidamente se è necessario un ramo di hotfix specifico. Quando il software non esiste più a quella versione (non è più supportato, quindi non può più verificarsi alcun lavoro) può avere senso eseguire un'unione finale del ramo e quindi eliminarlo. Puoi persino creare un commit vuoto finale (lo faccio spesso all'inizio del ramo), solo per dire "Chiusura ramo XXXX", altrimenti non manterrai la cronologia del ramo (reflog può aiutare un po ', ma questo è per repository)

— Patrick Mevzek,