Azioni del collaboratore dopo la richiesta di pull rifiutata

Question

Azioni del collaboratore dopo la richiesta di pull rifiutata

#1 da (4 voti)

3

Immagina, c'è un progetto open-source con un Maintainer e un Contributor. Entrambi hanno i loro repository esportati in qualche repository hosting (github, bitbucket, sourceforge --- qualunque cosa, ma sono pubblici).

Immaginate ulteriormente, Contributor ha fatto diversi commit, li ha spinti nel suo repository e ha inviato una richiesta di pull al Maintainer. Maintainer ha fatto una revisione, ha fatto diversi commenti sui commit (risolvi questo problema, aggiustalo, semplificalo, blah-blah-blah) e respinto la richiesta di pull. Nota:

Per Contributor è ovvio che è meglio correggere patch / commit piuttosto che riscrivere da zero.
Per favore considera la situazione, quando ci sono molti commit e le correzioni devono essere sparpagliate tra loro.

Cosa dovrebbe fare il collaboratore in questa situazione prima di effettuare la prossima richiesta di pull? Rimuovere il repository non valido, riscrivere la cronologia e spingerne una nuova? Effettua un commit di correzione in quello corrente?

Può la domanda del Maintainer, che la cronologia in entrata dovrebbe essere pulita? Cioè è tecnicamente abbastanza semplice da fare?

version-control

posta hate-engine 04.03.2013 - 18:57

fonte

1 risposta

Leggi altre domande sui tag version-control

Qual è la differenza tra un principio e una buona pratica? Gli sviluppatori di database sono considerati in lavori DBA?

score 4 · Accepted Answer

La maggior parte delle volte incorpora semplicemente le modifiche in un nuovo commit che viene aggiunto alla stessa richiesta di pull. Principalmente questo è così che non perdi la cronologia delle recensioni quando le correzioni vengono riviste. I revisori vorranno essere in grado di confrontare facilmente l'invio originale alla versione fissa. Se il manutentore desidera una "cronologia pulita" (per definizione una cronologia imprecisa, ma questa è una sfuriata per un'altra volta), allora di solito squash la richiesta di pull quando lo accettano.

Tuttavia, alcuni manutentori potrebbero chiederti espressamente di ripulire la cronologia. In tal caso, un contributore dovrebbe fare ciò che chiede, il che potrebbe richiedere una nuova richiesta di pull, a seconda dello strumento che si sta utilizzando. Se stai inviando contemporaneamente più funzioni dipendenti, puoi tenerle in rami separati a livello locale per semplificare la pulizia in questo modo.