Come distribuire un programmatore junior

I normally develop and push straight on the development branch.

Con tutto il rispetto, questo è un problema. Nessuno dovrebbe spingere direttamente sullo sviluppo, certamente non se stai usando gitflow - tutto dovrebbe andare su un ramo di funzionalità e quindi essere unito allo sviluppo una volta che la funzionalità è completa. Che cosa fai se sei a metà strada nello sviluppo di una funzionalità e le priorità cambiano in modo che una funzione diversa debba essere completata per prima?

Inoltre, ora hai un altro sviluppatore che lavora al progetto, dovresti ottenere anche il tuo codice revisionato e non puoi farlo se stai andando direttamente a sviluppare.

How do other teams manage this workflow?

Ad un certo punto lungo la linea, devi eseguire lo sviluppo di test (o un altro ramo che contenga le tue release candidate), altrimenti non vedrai alcuna interazione tra le tue funzionalità.

Se disponi anche di risorse per eseguire alcuni controlli sui singoli rami prima che vengano uniti per lo sviluppo, è grandioso farlo, ma in genere dovrebbero essere verifiche rapide sulle modifiche per tale funzione piuttosto che test di tipo completo di regressione.

Per aggiungere all'eccellente risposta di @ Philip, penso che anche tu debba guardare questo da un punto di vista umano.

Se stratificherai le tue pratiche lavorative, denigrerai le abilità del tuo Junior Developer. Certo è bello avere porte di qualità; ma dovrebbero applicarsi allo stesso modo a tutti se si desidera promuovere il lavoro di squadra e l'auto organizzazione.

La mia sensazione è che si tratti più di te che ti aggrappi al codice piuttosto che impostare buone pratiche. Chiediti, se tu avessi assunto uno sviluppatore con più esperienza di te stesso, saresti felice di farli esaminare e approvare tutto il tuo codice?

Come già sottolineato @Philip, idealmente non dovresti aver lavorato direttamente sul ramo di sviluppo.

Questa risposta mi riassume bene il motivo per cui utilizzare i rami di funzionalità, anche su una piccola o una squadra di persone, è una buona idea.

Suggerirei di creare spazi di sviluppo personali per te e il nuovo sviluppatore (e anche per ogni futuro sviluppatore, ovviamente), dove puoi lavorare sulla tua funzione in un ramo separato, una volta terminato, imposta una richiesta pull (che è sia un bel punto di ingresso per i test automatici, sia anche un'opportunità per mostrare il tuo lavoro allo sviluppo junior / dare un'occhiata al suo lavoro) e una volta superati i test, elaborare il PR e mettere la funzionalità su il ramo di sviluppo in modo che il team addetto al controllo qualità possa verificarlo e fare le sue cose.

Questi spazi di sviluppo personale possono essere localmente, utilizzando la finestra mobile / vagabondo, un server separato, ... È una questione di preferenza.

Il vantaggio di questo approccio è il futuro del tuo flusso di lavoro. Stai mettendo in atto un sistema in cui la quantità di sviluppatori che lavorano su un progetto non cambia il flusso di lavoro. Tutti hanno il proprio ambiente di sviluppo, lavorano su una funzione e creano un PR che alla fine arriverà al ramo di sviluppo per essere elaborato dal QA.

In questo modo il team addetto al controllo qualità ha ancora solo 1 punto da considerare, riducendo la complessità da parte loro (poiché non è necessario tenere traccia degli URL separati per funzioni / devs separati).