Quanto tempo può / dovrebbe qualcuno emettere una richiesta di pull per una nuova filiale?

Question

Quanto tempo può / dovrebbe qualcuno emettere una richiesta di pull per una nuova filiale?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

4

Le richieste di pull sono un'ottima funzionalità del moderno vcs hosting. Forniscono una visione consolidata di tutto ciò che è accaduto nello sviluppo di un ramo, inclusa una differenza principale del cambiamento composito e tutta la discussione che ha avuto luogo.

La mia domanda è questa: c'è qualche svantaggio nell'emettere immediatamente una richiesta di pull da un nuovo ramo?

Suppongo che le richieste tradizionali vengano emesse quando qualcuno ritiene che il loro contributo sia pronto per essere rivisto. Rilasciarlo in anticipo può creare confusione per chi è abituato al flusso di lavoro più tradizionale.

D'altro canto, l'emissione anticipata significa che i revisori possono effettuare il check-in e vedere se i cambiamenti di qualcuno stanno andando nella direzione sbagliata prima che gli sforzi superflui siano esauriti.

Forse ci sono altri pro e contro che non ho considerato?

git version-control github pull-requests bitbucket

posta Neal Kruis 13.10.2016 - 15:43

fonte

3 risposte

Leggi altre domande sui tag git version-control github pull-requests bitbucket

E 'corretto usare PUT con contenuti multipart? Posso usare Python con JavaScript come interfaccia utente?

score 2 · Answer 1

On the other hand, issuing early means reviewers can check in and see if someone's changes are going in the wrong direction before unnecessary effort is expended.

Assumi sempre che tutti gli altri sono occupati. Non controllano casualmente le richieste di pull non richieste - hanno le proprie attività a cui prestare attenzione, e cercano di capire la direzione da un codice non finito, che può contenere un sacco di confusione (cose che si intende completare, cose che si intende rimuovere ecc. ), è un'attività che richiede tempo. Ciò renderà anche le cose più difficili per te - dovrai assicurarti che non solo il tuo codice sia presentabile anche prima che sia pronto per la revisione.

Invece, se vuoi informare gli altri della direzione che stai seguendo, considera l'uso del bug tracker. Questi moderni servizi di hosting VCS di solito hanno un bug tracker o fanno parte di un pacchetto che ha un bug tracker. I bug tracker non sono solo bug, ma puoi anche aprire ticket per funzionalità, miglioramenti e refactoring. Nel ticket puoi scrivere a parole quello che intendi fare e utilizzare la funzione menzione che molti di loro devono notificare alle persone a cui dovrebbe interessare. Capire la direzione da quella descrizione è molto più facile che calcolarla dal codice incompleto ...

score 1 · Answer 2

On the other hand, issuing early means reviewers can check in and see if someone's changes are going in the wrong direction before unnecessary effort is expended.

Questo dovrebbe essere discusso nelle riunioni di progettazione, quando vengono discusse le caratteristiche. Quindi vengono creati i rami, si implementano le funzionalità e quando si pensa di essere pronti, creare la richiesta di pull. Quindi viene esaminato, si integra il feedback e il ramo viene unito.

Fondamentalmente, un ramo con una richiesta pull di solito è visto come un insieme di codice finito, ma sotto revisione (in preparazione per unire).

Ovviamente, questo è un modo di usare gli strumenti disponibili. Alla fine, si tratta di decidere una politica su cosa fare e quando e, se tutti sono contenti, puoi provarci.

Il problema con l'apertura di una richiesta di pull non appena il ramo è stato creato (o poco dopo lo sviluppo di quel ramo) è che crea un sacco di confusione, essendo molto difficile sapere ad un certo punto cosa ha stato rivisto e cosa no e quali sono i progressi su tutto.

score 1 · Answer 3

Ti metti d'accordo con i potenziali revisori. E poi sì, ci sono due obiettivi per una richiesta di pull: dare agli altri una visione preliminare del lavoro in corso, e se i tuoi colleghi vogliono che tu faccia una richiesta di pull, e di offrire il tuo lavoro speranzoso, completo e definitivo per la revisione.

Alcune persone non vorranno mai guardare il tuo lavoro preliminare, quindi non creare richieste di pull in quella fase.