È corretto chiedere ai contributori di rifare le loro richieste pull su github

Mantengo un repository github relativamente popolare.

Quando una richiesta pull è buona da unire, di solito chiedo all'autore di reimpostarla in un unico commit prima di unirla (specialmente quando ci sono state più piccole modifiche).

Questa è una buona pratica git? Questa etichetta GitHub è accettabile / standard?

Quindi alcuni vantaggi:

Ho una bella cronologia di commit pulita nei registri di commit
Non ho bisogno di modificare il commit da solo
Delega parte del lavoro

Alcuni possibili inconvenienti:

Non sono sicuro che questa sia una buona etichetta
Non sono sicuro se questa è una buona pratica git
Di solito ho già chiesto alcune altre modifiche: questa è un'altra e non voglio scoraggiare i collaboratori.

github etiquette

— Pablojim
fonte

Puoi descrivere alcuni vantaggi e svantaggi che vedi nel fare il processo in questo modo?

— Alex Feinman,

Alcuni vantaggi e svantaggi aggiuntivi da considerare. buono: git-bisect e altre inversioni sono più facili quando ogni commit produce uno stato costruibile o comunque completo, e questo approccio è un modo semplice per garantirlo. cattivo: piccole modifiche con semplici messaggi di commit vengono convertite in mega commit. Ad esempio, "Modificata questa riga per correggere i casi angolari" potrebbe essere inserita in "Aggiunta di funzionalità foo, grande elenco di modifiche ". Questo rende un po 'più difficile trovare la ragione di un cambiamento specifico.

— Gankro

Niente di sbagliato nel definire gli standard. Metti in chiaro ciò che è previsto. Esempio: symfony.com/doc/current/contributing/code/patches.html Scorri verso il basso fino al passaggio 3: invia la tua patch

— Cerad

@Granko: "Rebase" e "rebase in un singolo commit" sono due problemi separati.

— Matthew Scharley

Se viene chiesto a un contributore di fare questo, dovrebbe sovrascrivere il ramo della richiesta pull git push -f?

— Flimm

Per quanto riguarda Git, è una sorta di guerra santa se si debbano semplicemente unire i rami o rebase si impegni sull'ultima versione del ramo in cui ci si sta fondendo. Ci sono molte conversazioni su quale sia meglio se fai una rapida ricerca su Programmers.SE .

Per quanto riguarda l'etichetta alla base, affrontiamo questo dal punto di vista pratico. Quando si ha a che fare con un nuovo codice proveniente da qualcun altro, è sempre meglio convincerli a unire le ultime modifiche dalla succursale o rifondarle di nuovo prima di fondersi per garantire un'unione pulita. Ricorda, hanno scritto il codice in modo che di solito siano di gran lunga i più qualificati per gestire eventuali conflitti di unione / rebase. Personalmente non vedo alcun problema e vedo questa richiesta continuamente da altre persone. Per me, se non ci sono conflitti, spesso lo farò da solo poiché è un aggiornamento di due secondi che git può applicare da solo. Ma se ci sono conflitti, chiederò sempre all'autore originale del codice di gestirlo da solo.

Inoltre, per GitHub (come minimo) in particolare, visualizzeranno un link al tuo CONTRIBUTINGfile sopra qualsiasi tentativo di pubbliche relazioni in modo che sia un buon posto per delineare le tue aspettative e molti progetti prevedono che si uniranno solo rami aggiornati.

— Matthew Scharley
fonte

+1 per aver portato il pragmatismo nella discussione. Sì, questo è il punto. Può essere abbastanza difficile risolvere conflitti complessi in grandi richieste pull, specialmente quando è coinvolto un certo numero di commit. Questo è il punto in cui dovrebbe essere chiesto all'autore originale di intervenire. I conflitti facili non sono il problema, non lo sono mai stati e mai lo saranno.

— JensG,

+1 per aver effettivamente fornito una risposta e non solo commenti!

— Pablojim,