I file in vari sistemi di controllo delle versioni di codice in genere ottengono bug in un commit e rimangono intercettati fino a quando non vengono corretti in un altro commit. Questo perché ci sono due metodi popolari per usare il controllo delle versioni: i blocchi dei file e le unioni. Nel caso di un blocco di file, gli sviluppatori bloccano i file su cui stanno lavorando in modo che nessun altro possa apportare modifiche. Dopo lo sblocco, gli altri sviluppatori devono quindi eseguire il checkout dello stesso file, assicurandosi che tali modifiche non vadano perse.
In un sistema di controllo delle versioni del codice di unione, il ramo principale memorizza tutti i commit di tutti i rami uniti in esso, creando una cronologia lineare. Questo di solito funziona sui concetti di diff / patch, il che significa che un commit che introduce un bug da un ramo non verrà automaticamente cancellato da un commit in un altro ramo che verrà unito in seguito. In alcuni rari casi, si verificano conflitti e quindi è necessaria una risoluzione manuale. I bug di solito sopravvivono anche a tali fusioni, quindi continuano ad apparire continuamente attraverso la timeline del ramo principale.
Indipendentemente dal numero di filiali o sviluppatori che hai lavorato su un progetto, puoi praticamente garantire che semplicemente identificando l'ultimo commit valido noto prima del bug e l'ultimo commit errato noto per un bug (di solito l'attuale posizione di riferimento), puoi chiaramente isolare il commit che ha causato il bug, indipendentemente dal ramo in cui si è verificato. Si tratta di un effetto collaterale della natura lineare dei log e di come si integrano al ramo principale.
È sempre possibile identificare il tempo massimo di ricerca per trovare un bug contando il numero di commit dall'ultimo valore conosciuto all'ultima commit errato noto e la ricerca di log2 (x). Puoi spesso cercare la cronologia dell'intero repository per un bug in ben meno di 20 iterazioni (16.000 commit, ad esempio, sono solo 14 iterazioni). Se conosci la versione in cui è apparso un bug, di solito è nell'ordine di circa 5-10 iterazioni (il tuo chilometraggio può variare).
Ho solo esperienza con SVN e Git, ma è chiaro che qualsiasi sistema che utilizza qualcosa di meglio di "comprimere tutti i file nel repository in una cartella di commit nascosta" (ad esempio utilizzando le istantanee del file system letterale) dovrebbe avere all'incirca lo stesso prestazioni logaritmiche per la ricerca di bug. Ci sarà sempre un solo log lineare che deve essere letto, ignorando tutti i rami, anche quelli che sono stati successivamente scartati o ribattezzati, perché la linea temporale apparirà sempre lineare.
Per un esempio pazzesco, dai un'occhiata a questa immagine:
Inquestaimmagine,mostranocomefunzionaGit.EmentreGitstafacendoillavorocheglièstatodato,questanonèunabellavista.Tuttavia,noteraicomeognicommitsiallinealinearmente,nonostantelafusionedaunatonnellatadiramidiversiinmomentidiversi.Naturalmente,cisonostrumentipercorreggerequestastoria,quindiènuovamenteleggibile(adesempio, questo articolo su come sono finiti in quel casino).
Il punto è che il sistema di controllo delle versioni manterrà le cose per te, quindi una semplice ricerca binaria in una semplice cronologia lineare è davvero tutto ciò che è richiesto.