Definizione di una funzione nel modello GithubFlow?

Question

Definizione di una funzione nel modello GithubFlow?

#1 da (2 voti)
#2 da (-1 voti)

2

Ho utilizzato git per un po 'ora principalmente su CLi. Sono l'unica persona lavorando finora a questo progetto. Ho solo il 1% dimaster di diramazione e l'1% diproduction ramo. Il ramo production è denominato così che tutti i test in quel ramo passaggio. Lavoro direttamente sul ramo principale.

Recentemente ho avuto un problema che mi ha indotto a pensare che forse non stavo usando le migliori pratiche. Ho finito di lavorare su featureA e ho iniziato a lavorare su %codice%. Mentre lavoravo su featureB , ho apportato alcune modifiche al codice per featureB , ma non ha eseguito i test per featureA . Più tardi durante l'esecuzione del prova per featureA , ho anche deciso di verificare che featureB funzioni e test per featureA ha smesso di funzionare. Questo mi ha spinto a pensare a come sto definendo una funzionalità e forse dovrei essere in grado di isolare il lavoro che faccio su ogni funzione. Questo mi aiuterebbe a capire rapidamente quali cambiamenti hanno portato a questo bug. È solo a posteriori che sto definendo questi come featureA e featureA .

Mentre parlavo con altre persone, mi sono reso conto che dovevo usare rami per ogni caratteristica, e quindi unirli mentre completo ogni feaure.

Per capire un flusso di lavoro appropriato, mi sono imbattuto in 2 flussi di lavoro principali: featureB proposto da Vincen: link

e

gitflow proposto da Github: link

e hanno anche esaminato più altri documenti come:

revisione del codice con git-flow e github ,

confronti dei 2 workslows: link

Da questi, sembra che github-flow sia troppo di a in testa, dal momento che sto lavorando da solo. Quindi penso di usare gitflow .

Domanda

Capisco che dovrei creare rami fuori dal master, nel flusso github flow modello di lavoro. Tuttavia, come si definisce una funzionalità? Perché sto lavorando da solo su questo codebase, ho considerato l'intero pacchetto come una funzione, e che mi ha portato a lavorare su un singolo ramo. Tuttavia, dopo aver letto il GitHub e Githhub flow modelli, sembra che la definizione di funzionalità sia molto più granulare. Non ho trovato una definizione di cosa a caratteristica sta per questi e altri documenti che ho letto finora. Una funzione è una funzione, una classe? Io uso anche il github rilascia periodicamente di archiviare i cambiamenti che ritengo sarebbero utili, ma non lo sono avere tempo ora Dovrei usare i problemi di gitflow per creare problemi, e poi usali per creare funzionalità da loro?

git workflows github gitflow

posta alpha_989 14.04.2018 - 18:50

fonte

2 risposte

Leggi altre domande sui tag git workflows github gitflow

Problemi di concorrenza DB con ID modello di dominio Come posso mantenere le funzioni di bash senza le nuove righe sfuggite?

score 2 · Answer 1

Non c'è una definizione chiara. Di solito, l'ambito delle funzionalità dipende dal processo di sviluppo del team. Una funzionalità potrebbe essere una correzione di errore o una completa reimplementazione di un modulo. Dipende.

Una buona approssimazione: una caratteristica è quella che può essere ragionevolmente esaminata come richiesta di pull, e comunque essere "completa" . I piccoli cambiamenti frequenti sono fastidiosi, ma un'enorme richiesta di pull è totalmente non verificabile. Come una classe, una richiesta di pull dovrebbe essere coesa e non fare molte cose debolmente correlate. Una funzionalità deve essere sufficientemente completa in modo che possa essere unita senza rompere nulla.

Questo non significa che una funzione debba essere immediatamente spedibile! Molti problemi Git scompaiono o si riducono se si uniscono in anticipo, si uniscono spesso . Ciò significa che le funzionalità dovrebbero essere piccole e devono essere unite anche prima che siano completamente pronte. Un modo per gestirlo è utilizzare i pulsanti di attivazione : parti della funzione sono già nel ramo principale (e possono quindi essere integrate con altre modifiche), ma devono essere attivate esplicitamente da qualche opzione. Quindi queste funzioni incomplete non saranno usate in produzione.

Dato che sei uno sviluppatore solista, tutto questo non si applica realmente. In genere puoi sviluppare una funzionalità alla volta, senza dover ramificarti e unirla affatto. Questo è un processo totalmente valido. Il modello di ramificazione dovrebbe soddisfare le tue esigenze, non il contrario.

È quindi un po 'sorprendente che tu stia cercando di implementare sia GitFlow che GitHub Flow. Questi due suoni simili, ma hanno obiettivi molto diversi.

GitFlow è un modello di ramificazione abbastanza pesante che tenta di coordinare più sviluppatori e presuppone che tu abbia un concetto chiaro di una versione rilasciata che poi sosterrai per qualche tempo.
GitHub Flow è un modello di ramificazione abbastanza leggero che tenta di mostrare le funzionalità di GitHub come i commenti di richiesta di pull e presuppone che tu faccia la distribuzione continua dal tuo ramo principale.

La sovrapposizione tra questi due modelli di ramificazione è "il ramo principale rappresenta ciò che è stato rilasciato" e "lo sviluppo avviene sui rami delle funzionalità". Queste sono idee buone ma non necessarie . Per esempio. è anche comune utilizzare il ramo master come ramo di integrazione, ma non necessariamente distribuire / rilasciare questo stato. Le versioni sarebbero invece contrassegnate con tag. Quindi potrebbe essere sensato esaminare i modelli di branching esistenti, quindi metterli da parte e creare un processo che funzioni per te.

Un aspetto che non sembra funzionare nella tua esperienza è stato testing . Dove si presuppongono questi workflow test?

In GitFlow, durante il merging del ramo di funzionalità nel ramo di sviluppo e in un controllo di qualità più approfondito durante la preparazione di un ramo di rilascio, in genere viene eseguito un test.
In GitHub Flow, la richiesta pull viene esaminata e i test automatici vengono eseguiti come parte della pipeline di distribuzione. La distribuzione procede solo se i test hanno esito positivo.

In tutti i casi è ragionevole eseguire i test localmente prima di commettere e / o spingere le modifiche. Questo aiuta a rilevare i problemi in anticipo. Un approccio generalmente ragionevole: ogni commit dovrebbe essere realizzato con successo! È abbastanza semplice impostare un server di build (ad es. Con Jenkins) che costruisca il nuovo commit ogni volta che si preme il codice. In questo modo, puoi eseguire test rapidi prima del check-in e lasciare che una suite di test completa venga eseguita successivamente.

Se utilizzi i cavicchi delle funzioni, i test dovrebbero tener conto di ciò. Se i test vengono eseguiti per verificare se il codice integrato funziona, tutte le funzionalità dovrebbero probabilmente essere abilitate. Se esegui i test per il rilascio di un QA, devi ovviamente testare la configurazione che stai per rilasciare. Generalmente non è possibile testare separatamente tutte le combinazioni di levette caratteristiche, motivo per cui dovrebbero essere rimosse non appena la funzione è abilitata in modo permanente.

Riassumendo: non c'è una definizione chiara. Una "caratteristica" è spesso una sorta di cambiamento che si trova tra "commit individuale" e "rilascio". Quando si lavora da soli, non è probabilmente necessario mantenere una chiara distinzione. Quando si lavora con altre persone, è più importante seguire un processo comune che soddisfa le proprie esigenze piuttosto che seguire un processo esistente. Ma qualunque cosa tu faccia, i test automatici sono molto utili.

score -1 · Answer 2

Usiamo featurebranches molto. Una caratteristica in questo contesto sarebbe il delta che risulterebbe in un prodotto spedibile. Un PBI potrebbe essere una caratteristica, a volte un paio di PBI insieme, se davvero non ha senso spedire uno di loro senza l'altro. (ad esempio, non ha senso visualizzare un report fiscale senza poter inserire le informazioni pertinenti e viceversa)

Esempi di questo sarebbe una nuova funzionalità per il tuo prodotto (da qui il gioco). Una nuova schermata, un nuovo modello di esportazione, un nuovo pulsante sullo schermo (inclusa ovviamente la funzionalità dietro al pulsante).

La decisione di andare effettivamente in produzione dipende dal proprietario del prodotto (in mischia) o dagli accordi stipulati con il cliente. Ma il maestro conterrebbe sempre un lavoro che potrebbe andare in produzione se gli fosse richiesto di farlo. E una funzione dovrebbe essere la minima quantità di lavoro per ottenere di nuovo il codice in quello stato.