Come posso riorganizzare il codice altrui condiviso nel repository di controllo del codice sorgente, solo per il mio scopo?

1

Quando diverse persone lavorano insieme su un progetto condiviso in repository in github, capita abbastanza spesso che ritengo che il codice di qualcun altro sia difficile da leggere, e voglia cambiare e riorganizzare il suo codice e aggiungere altri commenti. È per migliorare la leggibilità solo per il mio scopo, e non voglio chiedere ad altri di cambiare il loro codice nello stesso modo in cui lo cambio.

Se tengo una copia locale del loro codice e modifico il loro codice per aiutarmi a capirlo meglio, non sono sicuro di come gestire la copia locale mentre il progetto va avanti e ho bisogno di cambiare il loro codice ancora e ancora e quindi avere sempre più copie locali del loro codice che sono state modificate per il mio scopo di comprensione.

Che cosa devo fare con il problema sopra riportato?

Grazie.

    
posta Tim 27.01.2017 - 04:53
fonte

2 risposte

4

If I keep a local copy of their code and modify their code to help me better understand it, I am not sure how to manage the local copy as the project goes on and I need to change their code again and again and thus have more and more local copies of their code that are modified for my understanding purpose.

L'onere della manutenzione è forse la ragione numero 1 per cui questo non viene fatto. Le persone che aggiungono funzionalità a un software open source sono molto ansiosi di integrare le loro modifiche a monte in modo che non debbano affrontare un flusso infinito di conflitti per le loro patch.

Lo strumento corretto per mantenere un set di patch, indipendentemente dalle tue motivazioni per farlo, è git rebase. Vedi qui: link .

    
risposta data 27.01.2017 - 05:38
fonte
1

È possibile mantenere un patchset creando un ramo separato e periodicamente ribasando o unendo master al suo interno. Se ti allontani da esso per fare qualsiasi lavoro che invierai a monte, devi rebase --onto master prima di premere. Le persone utilizzano questo approccio per mantenere le patch nei progetti open source che non possono o non invieranno a monte.

Il grosso problema con questo approccio è che richiede una molto comprensione approfondita del tuo ramo e del ramo upstream, perché questo sistema produce talvolta conflitti di fusione pazzi difficili. Questo lo rende poco adatto al tuo caso d'uso.

Ecco perché raccomanderei di apportare modifiche in un ramo come esercizio di apprendimento, ma non preoccuparti di mantenerle nel tempo. Inoltre, ti preghiamo di considerare se ci sono veri cambiamenti di manutenibilità e non solo cambiamenti di stile, sottoponendoli a beneficio di tutti. Molto spesso, il mio modello di commit va:

  • Riforma codice esistente in modo da poterlo capire meglio.
  • Implementa la funzione.
  • Rifatta la nuova funzione in modo che sia più pulita.
risposta data 27.01.2017 - 14:56
fonte

Leggi altre domande sui tag