Qual è il modo corretto di organizzare e revisionare una richiesta di pull

1

Sto lavorando a un progetto open source per la prima volta e sto aggiungendo una funzionalità alla fonte. Il modo in cui sto andando in giro, è che ho schiacciato i miei singoli commit sul commit pulito per la funzione. Ora ogni volta che ho bisogno di correggere il codice qualcosa nel codice perché fallisce il test, sto modificando il codice e ridefinendo git rebase -i HEAD~2 e squash nella modifica nel commit della feature originale. Funziona, tuttavia ogni correzione incrementale viene persa. C'è un'opzione quando rebasing per estendere il commento per avere i messaggi di ciascuno dei commit precedenti ma le diff di codice sono andate perse e sono git push origin master --force ogni volta che devo aggiornare, il che non è molto buono per il controllo della versione. C'è un modo migliore per farlo?

    
posta ThomasReggi 04.08.2015 - 18:53
fonte

1 risposta

1

In qualsiasi progetto in cui condividi il codice dovresti essere molto riluttante a modificare la cronologia e forzare la spinta. Questo è particolarmente vero per il codice open source.

Non ho capito bene la tua domanda, ma sembra che quando cerchi di aggiustare qualcosa finisci per rompere qualcosa, che è rivelato da una sorta di suite di test automatizzata.

Una buona pratica è aprire una richiesta pull al codice, anche se la possiedi. In questo modo, qualsiasi servizio di integrazione continua può eseguire test sul tuo codice. Inoltre, è necessario eseguire la suite di test sul proprio codice prima di eseguire il push. In questo modo sai che la correzione non ha infranto nulla.

Una correzione dovrebbe essere un commit separato in quanto non è una funzionalità. Questo perché all'avvio della versione del codice, la gente si aspetta un determinato comportamento da una determinata versione del codice. Se hai cambiato la cronologia, quelle aspettative non possono corrispondere. Inoltre, le persone che usano una particolare versione del codice potrebbero aver incontrato il bug che hai risolto. Si aspetteranno che una nuova versione del codice risolverà il problema. Se rebase e schiacci il codice, inserirai la correzione in un posto che non si aspetteranno.

Se stai scoprendo che devi implementare troppe correzioni per funzionalità, forse dovresti rallentare, scrivere test più completi e cercare di coinvolgere il tuo pubblico nelle revisioni del codice in modo da catturare i bug prima che diventino parte di il codice.

Infine, schiacciare la tua funzionalità in un singolo commit è una buona igiene. Il messaggio di commit dovrebbe includere solo informazioni pertinenti. Molti cambiamenti che avvengono mentre scrivi il codice non sono importanti. Se rinomina un metodo che nessuno ha ancora usato, nessuno deve saperlo. Tuttavia, se si rinomina un metodo in codice già pubblico, si dovrebbe menzionarlo come una modifica potenzialmente inoppugnabile, specialmente nel caso di metodi pubblici.

    
risposta data 05.08.2015 - 04:35
fonte

Leggi altre domande sui tag