Può il cherry picking commettere molto vecchio da un ramo separato a problemi di causa principale?

Quando aggiungi un nuovo codice a un'applicazione esistente, può contenere bug - no, è un eufemismo, contiene bug. Inoltre, questo ha anche un certo rischio di causare problemi nella parte esistente dell'applicazione, non solo nella parte nuova. E non importa se quel codice è scritto manualmente riga per riga, o se viene inserito nel tuo ramo principale usando uno strumento come Git.

Anche se hai testato la funzione in isolamento (e "in un altro ramo" conta come "in isolamento"), e non mostra più alcun bug, non vi è alcuna garanzia che l'integrazione del codice nell'app non causerà ulteriori problemi trascurati dai test isolati.

Ecco un semplice esempio: diciamo che la tua applicazione web ha una funzionalità di visualizzazione del numero di visite totali di un utente. Ora, la nuova funzione aggiunta in un ramo separato era un pulsante per azzerare il contatore utilizzato in quella funzionalità. È stato testato in quel ramo e ha funzionato in quel momento. Sfortunatamente, in mezzo al ramo master, qualcuno ha deciso di rimuovere la funzione originale, ma mantenere il contatore e dargli un significato diverso. Ora è utilizzato per il numero di tentativi di accesso consentiti, dove "zero" vieterà ogni ulteriore tentativo di accesso. Quando selezionerai la funzione, tecnicamente funzionerà, ma non nel modo previsto: il contatore verrà azzerato e la volta successiva questo particolare utente non potrà più effettuare il login. Certo, questo esempio potrebbe sembrare un po 'artificiale, ma credo che tu abbia capito il mio punto.

Quindi la risposta è sicuramente SÌ , la selezione di qualcosa nel ramo principale può causare problemi. Il mio punto è che questo non ha nulla a che fare con Git, Git non ti salva né dalla sintattica né dai problemi semantici delle integrazioni di codice.

L'unico modo per ridurre il numero di bug prima di portare il codice in produzione è un'adeguata verifica della qualità e test, che include anche test di integrazione. Forse hai una suite di test automatizzata per questo, ma per il nuovo codice con nuove funzionalità è probabilmente necessario estendere quella suite di test, e non tutto può essere gestito da test automatici. Quindi dovresti aspettarti qualche sforzo di test per questo.

Se decidi di "spedirlo comunque e attendi se compare qualche bug" è una decisione economica, che nessuno qui può portarti via. A volte "time to market" è più importante della qualità, a volte è il contrario. Tuttavia, immagino che il tuo cliente non sarà molto felice quando gli dici "ecco la funzione che ti aspettavi", e quando lo proverà per la prima volta, gli salterà direttamente in faccia.

Sì, ci sono dei rischi con la fusione o la selezione selettiva di un vecchio commit nello stato attuale delle cose.

Il primo rischio è che così tanto è cambiato nei file interessati nel frattempo che git non riesce a trovare tutte le posizioni in cui le modifiche devono essere applicate o che sono state apportate modifiche in conflitto. Ciò dovrebbe normalmente causare conflitti di unione, ma non posso garantire che ciò avvenga sempre.

Il secondo grande rischio sta nel fatto che git non capisce il linguaggio / la struttura dei file che stai unendo. Soprattutto con un commit più vecchio, è possibile che l'unione stessa non mostri conflitti, ma le modifiche siano tali che il compilatore o l'interprete non accetti più il codice o che un componente esterno faccia supposizioni sul codice che non sono più valide. Questo può essere mitigato solo testando correttamente il risultato dell'unione.

Più è vecchio il codice e più lontano dal tuo codice attuale, più è problematico scegliere e sperare per il meglio.

Ti consiglierei di comportarti come se stessi sviluppando la funzione in questo momento, e prendere il codice da quel vecchio ramo ti ha salvato il lavoro di digitarlo.

Non lo chiamerei nemmeno "trappole" se qualcosa va storto; se questo proviene da un ramo molto vecchio, sarebbe piuttosto inaspettato se funzionasse.