Qual è l'etichetta corretta e il flusso di lavoro GitHub consigliato per contribuire contemporaneamente e divergere dal repository upstream?

20

Sono nuovo di GitHub e VCS in generale. Ho iniziato a programmare in varie lingue per anni, ma ho sempre lavorato da solo su progetti personalizzati (nessuna pubblicazione pubblica). Recentemente ho iniziato a utilizzare un widget di interfaccia utente jQuery che ho scaricato da GitHub in un progetto su cui sto lavorando. Il repository non è più mantenuto dall'autore originale. Un altro fork ha incorporato alcune delle richieste di pull originali. Questo è quello da cui sono stato forgiato.

Ho trovato un paio di bug e ho trovato le soluzioni per loro. Mi piacerebbe contribuire con queste correzioni, ma ho anche un sacco di altre modifiche che voglio apportare, per il nostro uso, che interromperà alcune delle funzionalità esistenti. Inoltre, mi piacerebbe incorporare un'idea da un altro fork.

Sto ancora imparando GIT e GitHub e sto cercando di capire il modo migliore per andare su tutto. Ho letto molto (qui, SO, GitHub help pages, Pro Git) su diversi concetti / attività: flussi di lavoro, fusione, richieste pull, cherry picking, rebasing, branching. La mia materia grigia sta nuotando e ho bisogno di iniziare facendo così posso capire meglio quello che ho letto.

Problemi principali:

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

  2. Voglio ripulire i problemi di spazio bianco e mi sembra di ricordare di aver letto che è meglio farlo in un commit separato. Dovrei farlo nel mio master o in una filiale separata? Non voglio fare una richiesta di pull per qualcosa di così banale , ma se faccio cambiamenti nello spazio bianco prima della ramificazione, ciò influenzerà la richiesta pull per le correzioni dei bug? Alcune forcelle eseguivano la pulizia degli spazi bianchi e in effetti rendevano il diff piuttosto inutile.

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

  4. Qual è il modo migliore per dare credito all'autore di un'altra fork per l'idea che ha di lui che voglio usare? Non posso usare esattamente il suo codice, soprattutto perché la sua modifica è applicata a una versione precedente di upstream e non è compatibile con le altre mie modifiche. Ma voglio usare l'idea e voglio dare credito dove è dovuto il credito. Dovrei semplicemente collegarmi al suo repo (o profilo o commit specifico) nel mio messaggio di commit?

  5. Qual è l'etichetta relativa alla modifica del file readme e DocBlock nella parte superiore del file principale? È corretto apportare modifiche, aggiungere il mio nome, aggiungere collegamenti al mio repository e alla demo, rimuovere i link alla demo originale (poiché la mia forcella finirà per essere incompatibile con l'originale)? Ovviamente, 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 cronologia . Sono un perfezionista e le cose come sono pulite e ordinate. L'idea della storia registrata mi rende un po 'nervoso e voglio farlo bene la prima volta . Ho creato un nuovo repository per giocare / imparare con, ma sono ansioso di muovermi per aggiustare il widget dell'interfaccia utente di jQuery in modo da poter andare avanti con il mio progetto.

    
posta toxalot 29.12.2012 - 21:07
fonte

1 risposta

15
  1. Corretto: una richiesta pull è collegata a un ramo nel tuo repository. Se modifichi il ramo, modifichi anche ciò che invii come richiesta pull.

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

  2. Fai fai una richiesta di pull per i tuoi cambi di spazi bianchi! Parlando come qualcuno che a volte è un manutentore, adoro questi tipi di richieste di pull: o le approvo o no, e richiedono 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'eccedenza di documentazione e non un'idea interessante: forse puoi chiarire il motivo per cui vorresti farlo?

  4. Il collegamento al suo repository nel tuo 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, allora lo manderei via e-mail a meno che non sia chiaro quale licenza sta usando per il suo codice. Se la licenza è chiara (ed è una diversa licenza dal repository a cui stai inviando il commit) allora devi aggiungere la licenza differente nella richiesta pull e menzionare anche che nella tua pull- messaggio di richiesta.

  5. Questa è una domanda davvero valida e diversa a seconda di chi parli. La mia opinione è che non si dovrebbe mai aggiungere il proprio nome a qualsiasi commit o codice che si fa. La ragione principale è che implica "proprietà e responsabilità per il 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 fermerò qui e dirò - chiedi al maintainer del progetto o fallo e vedi quale sia la sua reazione.

  6. Puoi riscrivere (la tua cronologia locale, non ancora pubblicata) con GIT! Impara il comando git rebase - questo è uno dei motivi principali che amo git. È una cattiva idea per veramente di (forzare) la scrittura di commit / cronologia sul repository condiviso (github, ad esempio). Questo avvizzerà con i repository che gli altri sviluppatori hanno - dovranno fare cose difficili quando si estraggono le modifiche della cronologia (riscritta).

[# 6: Grazie a @toxalot!]

    
risposta data 01.01.2013 - 20:41
fonte

Leggi altre domande sui tag