Git workflow per le versioni

Question

Git workflow per le versioni

#1 da (2 voti)
#2 da (0 voti)

0

Il nostro prodotto viene rilasciato ogni mese. Sto guardando i flussi di git popolari come quelli nel sito ufficiale di git o di Atlassian. Ad un alto livello si consiglia di:

Sviluppa nello sviluppo del ramo
Crea un ramo di rilascio
Prova e prepara
richiama la richiesta di controllo

Pur comprendendo la necessità della fase di preparazione del rilascio, sono preoccupato che la richiesta di pull per il master sia enorme (1 mese di sviluppo) - significa che questi tipi di richieste di pull vengono automaticamente approvati e uniti?

Qualche flusso migliore da suggerire?

git gitflow

posta Mattan Bitner 22.09.2017 - 10:26

fonte

2 risposte

Leggi altre domande sui tag git gitflow

A cosa serve la versione (come in GitVersion)? Se Service Layer non sta facendo nulla, basta chiamare i metodi in DAO. La mia interfaccia di servizio può estendere le interfacce DAO?

score 2 · Answer 1

Se organizzi il flusso di lavoro in modo tale che le modifiche per lo sviluppo e il rilascio delle filiali siano consentite solo tramite una richiesta di pull peer-reviewed, la richiesta pull da masterare sarà davvero massiccia, ma non deve essere rivista con attenzione .

Poiché tutte le modifiche nella richiesta pull al master avrebbero dovuto essere riesaminate almeno una volta prima, sarebbe sufficiente fare alcuni controlli a campione per vedere se il processo deve essere aggiustato (cioè vedi qualche cambiamento che non erano parte di una recensione / pull-richiesta prima).

score 0 · Answer 2

Lavora su un ramo principale per il tuo lavoro regolare. Quando sviluppi una funzione, considera un ramo di una caratteristica, quando è chiaro che farai altre cose prima che la funzione sia finita.

Per commit che producono codice che non compila (o ha altri errori ovvi) usa un ramo locale, che non viene mai spinto. Unisci le commit in un secondo momento e rebase fino a renderlo pulito, rispetto a rebase su master o come branch di feature che si fondono in master.

Per una versione, crea un commit di rilascio, ovvero modificando il numero di versione nel readme, modificando la voce ChangeLog da 1.1.0-dev () a 1.1.0 (2017-09-22) e simili. impegnalo ad esempio con il messaggio di commit "versione 1.1.0".

Se prevedi di supportarlo parallelamente alle versioni più recenti, crea un ramo per v1.1.0, in cui scegli i bugfix dal ramo principale. Per 1.1.1 , quindi, crei un commit version 1.1.1 corrispondente e tag nel ramo. Lascia i vecchi rami così come sono. Non sai mai quando sosterrai una soluzione molto importante per un cliente che vuole davvero utilizzare la vecchia versione. Si può considerare di aggiungere un commit che indica la mancanza di supporto quando una vecchia versione non viene più mantenuta. Ma un suggerimento nel readme sulla home page e sul master può essere sufficiente.

Le buone versioni non cambiano mai. Se la tua versione 1.1.0 è danneggiata, rilascia un 1.1.1 funzionante e rimuovi i pacchetti danneggiati per 1.1.0 dal tuo sito web. Alcuni siti come python pypi non ti permettono nemmeno di caricare un nuovo pacchetto con lo stesso numero di versione, perché le persone non sarebbero mai in grado di dire se hanno la versione danneggiata o funzionante.