In attesa di più GitHub PR Merges

Question

In attesa di più GitHub PR Merges

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

1

Scenario: I fork di un progetto e invio di un PR su Feature A, e poi un altro su Feature B. Voglio continuare a lavorare con entrambe le funzionalità mentre aspetto che i PR vengano uniti (teoricamente potrebbero non esserlo se l'upstream è abbandonato).

Requisito aggiornato: dovrò spingere le modifiche al mio fork remoto in modo che l'elemento di configurazione lo prelevi.

Ho pensato a due possibilità: 1. Creare un ramo nella mia forcella che considero come master fino a quando upstream/master raggiunge e può essere sincronizzato con la mia forcella, ma esiste una convenzione standard per nominare un ramo di questo tipo? 2. Unire i rami funzione in master sulla mia forcella, il che semplificherebbe il caricamento, ma richiederebbe una spinta forzata per unire upstream/master in seguito, che so essere disapprovato.

Qual è il modo migliore per gestire questa situazione?

git github pull-requests

posta Sean DeNigris 08.09.2018 - 21:39

fonte

3 risposte

Leggi altre domande sui tag git github pull-requests

Come memorizzare post di blog nel database: React e GraphQL Come posso trasformare la mia applicazione di database CRUD in un'applicazione REST?

score 3 · Answer 1

Crea il tuo ramo "continua a lavorare" (qualunque cosa si chiami) e seleziona le altre modifiche al PR. (Potresti unire, ma diventerà disordinato se in seguito dovrai rivolgere i commenti di revisione in quelle Filiali PR.)

---- upstream/master
    \_ origin/pr-a
     \_ origin/pr-b
      \___ origin/continue-working

Successivamente, quando i PR vengono uniti, puoi rebase continue-working e continuare come se nulla fosse accaduto.

--------- upstream/master
    \_/| \  origin/pr-a
     \_| |  origin/pr-b
         \_ origin/continue-working

score 0 · Answer 2

Non esiste un approccio particolarmente valido per risolvere questo problema. Quando il progetto upstream si fonde, schiaccia o ridimensiona le tue funzionalità A e B, stanno creando nuovi commit che non fanno parte di nessun ramo su cui puoi lavorare al momento. Pertanto, se si continua a lavorare sulle funzionalità, sarà necessario unire o rebase in futuro. Un push forzato ad un certo punto è probabilmente inevitabile se si desidera tracciare il master upstream, ad esempio per creare una richiesta pull per una funzione futura C che dipende da A e B.

Nota che le spinte di forza non sono di per sé cattive. Spingere la forza rende la vita difficile per le altre persone che stanno seguendo il tuo ramo. Per esempio. forzare la spinta su un ramo principale che altre persone potrebbero aver clonato è un no-no. Spingere forzatamente su un ramo di una caratteristica sotto lo sviluppo attivo è perfettamente a posto. Soprattutto durante una revisione della richiesta di pull, l'uso della forza di spinta per ripulire i commit nella richiesta di pull a volte può essere una buona pratica.

Potrebbe essere meglio evitare di utilizzare il ramo master per il tuo sviluppo. Se possibile, utilizza un ramo di funzionalità che verrà rebase in seguito, ad es. caratteristica-C. Se ti serve un ramo pseudo-master personale, lo nominerei da solo. Tuttavia, non esiste alcuna convenzione generale per questo caso.

score 0 · Answer 3

In una situazione come questa, di solito creo un ramo di lancio locale. Non importa come lo chiami perché è privato e non vive a lungo. In questo ramo si uniscono entrambi i rami da PR A e PR B. È quindi possibile continuare a lavorare. Se crei più commit in questo ramo throw-away, possono essere facilmente raccolti in PR C una volta che sono stati uniti PR A e PR B.