Utilizzo di Gitflow e Semantic Versioning: come evitare i conflitti tra numeri di versione durante l'unione?

Question

Utilizzo di Gitflow e Semantic Versioning: come evitare i conflitti tra numeri di versione durante l'unione?

#1 da (3 voti)

4

Voglio usare gitflow in combinazione con il versioning semantico. In gitflow, esegui il bump dei numeri di versione su ogni release o ramo di aggiornamento rapido. Ciò porta inevitabilmente a conflitti di versione se viene avviato un nuovo ciclo di sviluppo (con un nuovo numero di versione) mentre il processo di rilascio corrente è ancora in corso.

Diciamo che 1.0.0 è su master, e su sviluppo avvio la nuova versione 2.0.0. Ora, si verifica una correzione dal master (1.0.1). Quando unisci l'aggiornamento rapido al ramo di sviluppo, si verificherà un conflitto.

C'è una domanda un po 'simile qui su SE @ Stackexchange, con una differenza sostanziale: poiché i miei strumenti di valutazione gradle e maven fanno molto affidamento sui numeri di versione, devo memorizzarli nel mio codice e non possono solo generarli durante la creazione di un rilascio. E devo aumentare il numero di versione in sviluppo per un nuovo ciclo di rilascio, altrimenti gli artefatti verranno sovrascritti.

Quindi, come posso gestire i miei rami e i numeri di versione in modo che non possano verificarsi conflitti di unione?

git gitflow semantic-versioning

posta Franz Wimmer 24.08.2018 - 11:17

fonte

1 risposta

Leggi altre domande sui tag git gitflow semantic-versioning

Quali sono le soluzioni e i compromessi per mantenere la consistenza dei risultati di ricerca in un'applicazione web Quali competenze aggiungere per un laureato CS più anziano che vive in aree rurali? [chiuso]

score 3 · Accepted Answer

Non puoi ragionevolmente evitare questo conflitto di fusione. Ma è un conflitto molto minore e facile da risolvere durante l'unione, ma assicurati che il numero di versione sia scritto solo nel file sorgente one .

Gli hotfix sono probabilmente abbastanza rari che una risoluzione manuale è sufficiente. Tuttavia, potrebbe essere sensato aggiungere un tipo di test per il mantenimento del numero di versione corretto, ad es. uno script per verificare che il numero di versione in un commit aumenti monotonicamente da tutti i commit principali. L'unione delle versioni 1.0.1 e 2.0.0 potrebbe comportare un > = 2.0.0.

Si noti che Git-Flow non è sempre un modello di diramazione applicabile. È orientato verso scenari che hanno rilasci chiari, piuttosto rari, in cui potrebbe essere necessario supportare le vecchie versioni. Questo può essere adatto per le applicazioni o le librerie off-the-shelf.

Git-Flow non si adatta bene quando puoi aggiornare tutte le distribuzioni / utenti alla versione più recente, ad es. per software in-house, SaaS o app web / mobile. Quindi, un diverso modello di ramificazione senza rami di rilascio potrebbe essere più appropriato. Ciò implica che il tuo ramo di sviluppo è sempre in uno stato rilasciabile, che a sua volta significa che tutte le funzionalità che sono state unite sono pronte per il rilascio O sono protette da un interruttore di funzionalità. Una correzione è quindi una funzionalità ordinaria per la prossima versione e non è necessario il backport / l'unione dell'aggiornamento rapido.