Cos'è l'etichetta corretta e il flusso di lavoro GitHub raccomandato per contribuire e divergere simultaneamente dal repository upstream?

Sono nuovo di GitHub e VCS in generale. Ho programmato in varie lingue per anni, ma ho sempre lavorato da solo su progetti personalizzati (senza pubblicazioni pubbliche). Di recente ho iniziato a utilizzare un widget dell'interfaccia utente jQuery che ho scaricato da GitHub in un progetto a cui sto lavorando. Il repository non è più gestito dall'autore originale. Un altro fork ha incorporato alcune delle richieste pull originali. Questo è quello da cui ho biforcato.

Ho trovato un paio di bug e ho trovato le soluzioni per loro. Vorrei contribuire con queste correzioni, ma ho anche molte altre modifiche che voglio apportare, per nostro uso, che romperanno alcune delle funzionalità esistenti. Inoltre, vorrei incorporare un'idea da un'altra forcella.

Sto ancora imparando GIT e GitHub e sto cercando di capire il modo migliore per fare tutto. Ho fatto molte letture (qui, SO, pagine di aiuto di GitHub, Pro Git) su diversi concetti / attività: flussi di lavoro, fusione, richieste pull, raccolta delle ciliegie, rebasing, ramificazione. La mia materia grigia sta nuotando e devo iniziare a fare così posso capire meglio cosa ho letto.

Problemi principali:

1. Penso di aver letto (da qualche parte) che puoi avere una sola richiesta pull su un ramo alla volta. Questo significa che dovrei avere un ramo separato per ogni bug e quindi fare una richiesta pull separata per ognuno?

2. Voglio risolvere i problemi relativi agli spazi bianchi e mi sembra di ricordare di aver letto che è meglio farlo in un commit separato. Dovrei farlo nel mio master o in un ramo separato? Non voglio fare una richiesta pull per qualcosa di così banale , ma se apporto modifiche agli spazi bianchi prima della ramificazione, ciò influenzerà la richiesta pull per le correzioni di bug? Alcune forcelle hanno fatto la pulizia degli spazi bianchi e ha reso la diff piuttosto inutile.

3. Stavo pensando di creare problemi contro il mio fork come un modo per documentare i bug anche se ho già la soluzione per loro. È una buona idea? Come posso fare per collegare il problema, il commit e l'unione da padroneggiare? Se invio una richiesta pull a monte, il mio problema verrà visualizzato anche a monte o il collegamento alla documentazione andrà perso? Non riesco ad aprire un problema con il repository upstream (non esiste una scheda Problema).

4. Qual è il modo migliore per dare credito all'altro autore della forchetta per l'idea del suo che voglio usare? Non riesco a usare esattamente il suo codice, soprattutto perché la sua modifica viene applicata a una versione precedente dell'upstream e non è compatibile con le altre mie modifiche così come sono. Ma voglio usare l'idea e voglio dare credito quando il credito è dovuto. Devo solo collegarmi al suo repository (o profilo o commit specifico) nel mio messaggio di commit?

5. Qual è l'etichetta per quanto riguarda la modifica del file Leggimi e il DocBlock nella parte superiore del file principale? Va bene apportare modifiche, aggiungere il mio nome, aggiungere collegamenti al mio repository e demo, rimuovere i collegamenti alla demo originale (poiché il mio fork finirà per essere incompatibile con l'originale)? Naturalmente, lascerò il nome dell'autore originale e le informazioni sulla licenza. Per la cronaca, è concesso in licenza con la licenza MIT.

Come sviluppatore solista che non ha mai usato VCS, sono abituato a riscrivere la storia . Sono un perfezionista e mi piace che le cose siano pulite e ordinate. L'idea della storia registrata mi sta rendendo un po 'nervoso e voglio farlo bene la prima volta . Ho creato un nuovo repository con cui giocare / imparare, ma sono ansioso di iniziare a sistemare il widget dell'interfaccia utente jQuery in modo da poter continuare con il mio progetto.

1. Corretto: una richiesta pull è collegata a un ramo nel repository. Se modifichi il ramo, stai anche modificando ciò che stai inviando come richiesta pull.

   Quindi sì, devi creare un ramo (e pull-request) per la correzione di bug. Potrebbe essere saggio iniziare con uno e vedere come il manutentore reagisce a quello prima di continuare a fare il resto. L'open source è un processo intrinsecamente sociale.

2. Fai una richiesta pull per le tue modifiche agli spazi bianchi! Parlando come qualcuno che a volte è un manutentore, adoro questi tipi di richieste pull: o le approvo o no, e impiegano poco tempo per l'elaborazione.

   Ciò che potresti anche incontrare è che il manutentore non è d'accordo con le tue modifiche agli spazi bianchi! Quindi, attenzione ..

3. Hmm .. Non è chiaro cosa stai cercando di ottenere qui. Sembra un'eccessiva documentazione e non una buona idea - forse puoi chiarire perché vorresti farlo?

4. Il collegamento al suo repository nel messaggio di commit (o anche in un commento nel codice) è un ottimo modo per dare credito. Fai attenzione però: rendi esplicito che lo stai ringraziando per le sue idee e non per il suo codice. Se hai copiato il codice, lo invierei via e-mail a riguardo, a meno che non sia molto chiaro quale licenza sta usando per il suo codice. Se la licenza è chiara (ed è una licenza diversa dal repository a cui si sta inviando il commit), è necessario aggiungere la diversa licenza nella richiesta pull e menzionarla anche nel messaggio di richiesta pull.

5. Questa è davvero una bella domanda e varia a seconda della persona con cui parli. La mia opinione è che non dovresti mai aggiungere il tuo nome a nessun commit o codice che fai. Il motivo principale è che implica "la proprietà e la responsabilità del codice" - potrebbe impedire ad altri di modificare il codice perché "è tuo". Ma ora stiamo entrando in un'enorme discussione sulla natura dell'open source, quindi mi fermo qui e dico: chiedi al manutentore del progetto o semplicemente fallo e vedi quale è la sua reazione.

6. Puoi riscrivere la cronologia (la tua locale, non ancora pubblicata) con GIT! Impara il comando git rebase: questo è uno dei motivi principali per cui amo git. È davvero una cattiva idea (forzare) il push di commit / cronologia riscritti nel repository condiviso (github, per esempio). Questo si rovinerà quindi con i repository che hanno gli altri sviluppatori: dovranno fare cose difficili quando tirano le modifiche (cronologia riscritta).

[# 6: grazie @toxalot!]