Come ridurre le possibilità di ottenere conflitti di merge che si verificano in due progetti della stessa base di codice clonato

Question

Come ridurre le possibilità di ottenere conflitti di merge che si verificano in due progetti della stessa base di codice clonato

#1 da (3 voti)

2

Ho due applicazioni A e B .

L'applicazione A è stata scritta prima dell'applicazione B , in realtà B era inizialmente lo stesso fork di A , quindi ciascuna applicazione conteneva gli stessi moduli e lo stesso codice.

La struttura di aggiornamento della base di codice di entrambi i progetti è stata tale che: l'aggiornamento della base di codice di A eseguirà l'unione automatica nella base di codice di B .

Ma a causa di alcuni requisiti specifici, uno dei moduli di B deve essere diverso da quel modulo in A . Quindi le persone possono anche cambiare direttamente il codice in B .

Inoltre, a causa di alcuni requisiti urgenti per B le persone hanno apportato modifiche direttamente nella base di% di B . Così nel tempo, questo ha creato alcune differenze in quasi tutti i moduli del progetto.

Questo sta causando numerosi conflitti di merge durante il processo di unione automatica, ovvero quando un utente ha aggiornato la base di codici di A e quindi nel processo di unione automatica, i conflitti di unione si verificano a causa delle differenze correnti presenti in esso.

Per risolvere questo problema, ho creato una classe statica che contiene i dettagli del prodotto e usiamo quella classe statica per apportare alcune modifiche specifiche dell'applicazione. Ad esempio:

public static class ApplicationDetails
{
    public boolean isApplicationA(){ /*.....*/ }
    /*.... other details.... */
}

Ora, se abbiamo alcune modifiche specifiche per l'applicazione usiamo questa classe ApplicationDetails.

Ma la base di codice ora è cresciuta e un modulo di esso ha un sacco di classi e di logica in esso. Fare questo per entrambi i progetti sembra un sacco di compiti e richiede molto tempo.

Quale approccio dovrei usare per risolvere questo problema? Dividere completamente il codebase (cioè rimuovere automerge) non è un'opzione perché ci sono ancora molti moduli comuni.

git design java github

posta Amit Upadhyay 28.08.2018 - 07:52

fonte

1 risposta

Leggi altre domande sui tag git design java github

CQRS di Sourcing di eventi e richiesta di eventi che terminano su Richiesto Se è possibile memorizzare BigInts in un modo più ottimale di un array

score 3 · Accepted Answer

Penso di poter ricomporre automaticamente per funzionare dovresti:

cambia il codice
cambia il processo

Cambia il codice

Per le cose che devono essere diverse nell'applicazione B, devi creare sottoclassi e sovrascrivere le funzioni necessarie (o una classe separata che implementa la stessa interfaccia). Mantieni le modifiche il più piccole possibile e prova a metterle in funzioni protette separate, se possibile.

Ora usa il tuo configuraiton del contenitore IOC per collegare queste diverse classi.

in pratica finisci con:

Alcuni file separati per l'applicazione B che sono sottoclassi di classi o interfacce dell'applicazione
1 file di collegamento / configurazione per il contenitore IOC per utilizzare queste diverse classi. (è necessario separare i file per entrambe le app senza conflitti di merge ma potrebbe essere necessario aggiungere le modifiche in config da un manuale a un b)

Modifica il processo

ora se vuoi modificare qualcosa nell'Applicazione B, non ti è più permesso di toccare le classi dell'Applicazione A, ma devi invece archiviare e RFC (richiesta di modifica) nell'applicazione A e quindi unirla nell'applicazione B. E poi scrivi le tue sottoclassi nell'applicazione B