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:
-
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?
-
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.
-
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).
-
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?
-
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.