Come dovrei controllare le versioni del mio progetto su GitHub

Naviga le tue risposte
12

Sto cercando di trascorrere il tempo che posso su GitHub al giorno d'oggi (anche io sono l'unica persona in squadra al lavoro) per sentire veramente come sarà per un'applicazione aziendale reale.

Una domanda che ho è di controllare la versione . Diciamo che abbiamo iniziato un progetto. Quindi, i membri del team hanno creato alcune filiali e si sono sviluppate lì. Quando siamo pronti per la produzione, abbiamo unito tutti i rami con master branch. Alla fine, andiamo a vivere con la versione 1.0 .

Ora la versione 1.0 è attiva e abbiamo alcuni problemi archiviati per quella versione di quel software. Vorremmo iniziare a sviluppare per la versione 1.1 al fine di risolvere i problemi che abbiamo introdotto affrettando il progetto.

Ora la domanda è questa:

Come dovremmo controllare il controllo delle versioni qui?

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

C'è una convenzione là fuori per quel tipo di situazioni?

    
posta tugberk 08.01.2012 - 10:15
fonte

2 risposte

18

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

(immaginedall'articolo)

Cisonomoltebuonepraticheeregoleseveredescritteinquell'articolo,loconsigliovivamente.

Puntidiinteresse:

  • Ilramoprincipaleèilpuntoincuitagghiletueversioni.Nessunsviluppoaccadequi.Incasodiunbugcheèstatodistribuitoinproduzione,correggiilbugsuunramodell'hotfix,uniscinuovamenteetaggaunanuovaversione.
  • Losviluppoavvienesuiramidisviluppoefunzionalità.Personalmente,eseguoilbugfixingsulramodisviluppoelefunzionalitàsuiramidellefunzionalità.
  • Quandoilsoftwareiniziaaraggiungereunrilascio,midirigoperrilasciareilramo.Ilramodirilascioèdovefacciogliultimiritocchi.Eseguiilbumpdeinumeridiversione,cambiaimetadati,ecc.Altermine,louniscoamaster,taggaloelochiamounaversione.
  • Idueramiprincipali:ilmaestroèil"ramo santo"; il suo HEAD è sempre l'ultimo codice di produzione, e sviluppa è il ramo notturno; il suo HEAD riflette sempre le ultime (ma possibili instabili) aggiunte al codice.

Nel tuo caso specifico, i passaggi dipenderanno da quanto veloce è stata quella versione. Se si tratta di funzionalità che sono state tralasciate, tornerei alla versione di sviluppo e farò di nuovo il tutto. Se si tratta di bug nella versione distribuita, mi dirigo verso un ramo hotfix, correggere i bug, unire nuovamente e tag v1.1. Se sono entrambi, correggo prima i bug, quindi aggiungo le funzionalità secondo come descritto.

    
risposta data 08.01.2012 - 12:00
fonte
1

Quello che ho visto la maggior parte del tempo è:

  • Il master è per te prodotto. Alla fine tutta la tua versione futura x.0 sarà su master.
  • Si crea un tag / ramo per ogni versione in produzione in modo da poterli comunque supportare per qualsiasi cliente che lo richieda.
  • L'unione di correzioni da una o l'altra è da trattare in base al singolo caso.
risposta data 08.01.2012 - 10:41
fonte

Leggi altre domande sui tag

Cosa devo fare se il membro Scrum parte a metà? È possibile compilare un linguaggio di livello superiore a C ++ leggibile? [chiuso]