Sono completamente in disaccordo con la risposta accettata.
Ciò che hai descritto è in realtà molto desiderabile. Il difetto nel modo di pensare dietro la risposta è il presupposto che la cosa testata sia il codice sul ramo in isolamento rispetto ad altri lavori, ma non è vero.
Dovresti testare il codice completamente integrato ogni volta che puoi.
In altre parole, l'idea di "non il codice che era destinato" è sbagliata. Diciamo che il sistema è testato e supera tutti i test. Se passa tutti i test con il codice sia quelli commessi dal primo sviluppatore sia il codice che è stato commesso dal secondo sviluppatore, è fantastico. Hai appena salvato un ciclo di test in più per dirti che il codice di entrambi i commit va bene.
Se il codice del secondo commit fa fallire i test, allora va anche bene. Hai appena salvato un ciclo di prova in più per dirti che il codice ha bisogno di una correzione.
Se il codice del primo commit causa il fallimento del test, hai imparato ciò che dovevi sapere indipendentemente dal secondo commit.
Se il codice dall'integrazione del primo e del secondo commit fa fallire il test, allora è grandioso. Hai salvato un ciclo di prova in più per dirti che i due sviluppatori devono collaborare per risolvere il problema di integrazione.
Essenzialmente non c'è alcun svantaggio nel testare il secondo commit e il primo. Non capisco da dove nel settore sia nata questa idea da un punto di vista tecnico. L'unica ragione per cui posso pensare a qualcuno a cui interesserebbe è che vogliono essere in grado di assegnare la colpa a un particolare sviluppatore per un test fallito. E questo suona piuttosto disfunzionale per me.
Tutto quello che stai facendo con questo tipo di strategia di sviluppo e ramificazione sta rendendo il processo di sviluppo più lento e più costoso.