ha senso creare una richiesta pull senza codice

Question

ha senso creare una richiesta pull senza codice

#1 da (7 voti)
#2 da (2 voti)

3

Sfondo

Nella nostra documentazione di start-up, abbiamo ottenuto questo:

Difference between a pull request and an issue page

In a nutshell, an issue page should only include information and discussion about the issue itself (ie clarifying requirements, suggesting edits to the requirements etc) It should never include any information or data about the actual solution.

The PR page, on the other hand, should only include data/discussion about the solution. It should never include any information about the nature of the requirements, that should only be in the issue page.

Why?

b/c the issue and its solution are two different things. Issue requirements should be fixed and clear, whereas the same requirement may have many different solutions and solution paths. So a proposed solution should be hosted separately from the issue page, as we don’t want a proposed solution to influence the requirements of an issue. For example we can assign a task to an engineer, and they can spend a week and present a solution that’s absolutely not acceptable. With that solution being hosted on a separate PR page, we can cleanly reject that solution and simply assign the same task to another engineer etc.

Domanda

Considerato quanto sopra, ha senso essere in grado di creare un PR senza avere rami? Mentre nessuno dei principali git basati su strumenti di project management online lo consente (ho controllato github / gitlab e bitbucket), in teoria si può fare se io manchi il codice di gitlab.

Aggiornamento (aggiunta alla risposta di seguito)

Mi è veramente piaciuta la risposta di Karl Bielefeldt. Volevo solo aggiungere questo: dal progetto siamo lavorando su ha un rilascio molto aggressivo e un ciclo di distribuzione, c'è poca tolleranza per il codice stubbed che viene aggiunto al ramo principale. Per risolvere il problema, penso abbia senso creare R & D PR su un ramo argomento, in cui l'output sarebbe una discussione, google docs, oltre a qualche codice stubbed, e alla fine quando l'implementazione avviene (che dovrebbe quindi rimuovere lo stub codice e sostituirlo con codice reale) .. il PR può essere fatto contro il ramo principale .. e tutti vincono:)

git project-management pull-requests gitflow

posta abbood 14.03.2017 - 12:42

fonte

2 risposte

2

No. Il punto principale di ciò che hai citato sembra essere quello di mantenere separate la soluzione e il problema. Questo non richiede una vera richiesta di pull prima che il codice sia scritto; qualsiasi discussione sulla proposta può essere tenuta in un documento separato (che sospetto possa essere quello che i documenti intendono con la pagina ).

risposta data 14.03.2017 - 14:37

fonte

Leggi altre domande sui tag git project-management pull-requests gitflow

Programmazione dichiarativa per il controllo deterministico in tempo reale Le ricorsioni sono intrinsecamente meno sicure delle iterazioni?

score 7 · Accepted Answer

Non hai bisogno di code modificato per aprire una richiesta pull, ma hai bisogno di un ramo , perché l'intento è di spingere un po 'di codice, anche se l'intento non si materializza sempre.

L'uso di una richiesta pull per comunicare i dettagli dell'implementazione prima di iniziare la codifica ha un paio di grandi vantaggi rispetto a una mailing list. Ti consente di iscriverti solo ai bug o alle funzionalità che ti interessano. Ciò è utile sia per i manutentori di progetti di grandi dimensioni che devono suddividere il lavoro sia per terze parti che sono interessate solo a una o due funzionalità imminenti o correzioni di bug. Non è necessario filtrare l'intera mailing list solo per vedere cosa ti interessa.

Inoltre, la discussione sull'implementazione è sempre associata al commit del controllo della versione, quindi se le persone hanno domande sul perché è stato progettato in quel modo o su quali alternative sono state discusse e scartate, è facile trovare la discussione a cui fare riferimento.

Per questi due motivi, l'apertura di una richiesta di pull con un ramo vuoto sta diventando sempre più comune nei nuovi progetti open source più ampi, almeno per le funzionalità che richiedono una vasta discussione sull'implementazione. Kubernetes è un buon esempio. Github ha anche funzioni come elenchi di attività che rendono questo tipo di flusso di lavoro più facile.