Come posso contribuire al codice di altri in GitHub? [chiuso]

231

Vorrei contribuire a un determinato progetto in GitHub . Dovrei rovinarlo ? Ramificalo ? Cosa è raccomandato e come farlo?

git  open-source  github 
— wizztjh
fonte
61
Un altro ridicolo vicino
— Stephen
4
Ho scritto una guida dettagliata più dettagliata sul contributo a Concrete5 su Github, ma il processo potrebbe applicarsi a qualsiasi progetto. Dai un'occhiata .
— Joe Meyer,
7
Non vedo davvero come questo non sia "costruttivo". I voti e le opinioni da soli forniscono la prova che è una domanda popolare a cui la gente sta cercando di aver risposto.
— Ian,
4
— Konstantinos il
1
forse con un voto a maggioranza sufficiente, dovrebbe essere permesso di far resuscitare una domanda precedentemente chiusa e lasciare che le persone contribuiscano nuovamente al thread.
— Peter Teoh,

Risposte:

180

Idealmente tu:

  1. Fork il progetto
  2. Effettuare uno o più commit ben commentati e puliti nel repository. Puoi creare un nuovo ramo qui se stai modificando più di una parte o funzione.
  3. Esegue una richiesta pull nell'interfaccia web di github.

se si tratta di una nuova richiesta di funzionalità, non avviare prima la codifica. Ricorda di pubblicare un problema per discutere della nuova funzionalità.

Se la funzionalità è ben discussa e ci sono alcuni +1 o il proprietario del progetto l'ha approvata, assegnare il problema a te stesso, quindi eseguire i passaggi sopra.

Alcuni progetti non utilizzeranno il sistema di richiesta pull. Verifica con l'autore o la mailing list il modo migliore per ottenere il tuo codice nel progetto.

— Yann Ramin
fonte
4
Dettagli sul biforcazione di GitHub e richieste pull
— Gabriel Grant
1
Sì, pull richiesta. La richiesta di unione è una terminologia gitorosa.
— Yann Ramin,
2
@MariusKavansky è il contrario! Una volta che sai su cosa lavorare, solo tu contribuisci :)
— hashbrown,
dopo aver contribuito a qualche progetto open source. Penso che sia un'idea migliore aprire un problema per discutere della nuova funzionalità se si tratta di una nuova funzionalità. Se si tratta di una funzionalità o un problema ben discusso, è necessario assegnare il problema a se stessi, quindi eseguire i passaggi sopra. Questo è il mio 2 centesimi.
— wizztjh,
@hashbrown, Finora sta chiedendo dov'è la "lista" delle funzionalità richieste. Quelle funzionalità che sono già state richieste e +1.
— Pacerier,
31

Per aggiungere alla risposta di Yann , una volta che hai biforcuto un progetto, puoi sviluppare in qualsiasi ramo tu voglia (uno nuovo o uno dal progetto originale)

Ricordati di:

— VonC
fonte
1
puoi aggiungere dettagli o link sul tuo secondo punto (ramo di rebasing) ?
— JorgeArtware,
1
@JorgeArtware Ho aggiornato la risposta con alcuni link che illustrano il rebase.
— VonC,
@VonC Faccio una domanda qui, ma se ritieni che sia necessario, farò una domanda completamente nuova. Perché dovrei riformulare invece di unirmi, oltre ad avere la "storia semplice"? In altre parole, ecco cosa faccio quando contribuisco ad alcuni progetti (dopo che il PR del mio ramo di funzioni è stato unito per sviluppare e padroneggiare rami): lo git checkout master; git pull;stesso per sviluppo (in cui il mio ramo di caratteristiche è stato unito per primo) La differenza che posso pensare di, dopo aver letto "pull vs pull --rebase" e "merge vs rebase" è solo la storia piatta. Qualcos'altro di più profondo?
— linuxbandit
@grasshopper in termini di "contributo" (il contesto di questa pagina), si desidera sempre riordinare i propri commit locali in cima ai rami aggiornati prima di spingere: ciò renderà banale tale contributo da integrare dal manutentore al ramo del progetto originale. Nel contesto della tua domanda, in cui il tuo PR è stato accettato, certo, puoi unire invece di rebase per aggiornare le filiali esistenti.
— VonC
(Mi dispiace aver cambiato il nome utente proprio ora per riflettere il mio github) - @VonC grazie, quindi tutti i suggerimenti che stavo leggendo sul rebase si applicano prima del PR, ha senso. Per riflettere le PR accettate e unite all'interno del mio repository locale, esiste qualche pratica comune (rebase anziché merge) o posso fare qualunque cosa? E se invierò comunque un'altra PR?
— Linuxbandit
15

Per aggiungere alle risposte di Yan e VonC, questa è una buona risorsa dagli stessi github: http://help.github.com/forking/

Assicurati anche di guardare nella barra laterale destra sotto l'intestazione "collaborazione".

— brycemcd
fonte
10

V'è un grande video Railscast qui che ti guida attraverso il processo. Ha anche una serie di buoni consigli come mostrare come determinare su quale ramo potresti voler lavorare quando contribuisci, usando test, sottomoduli, ecc.

Mentre questo screencast si concentra principalmente sugli sviluppatori di Rails, la maggior parte delle informazioni è valida per contribuire a qualsiasi progetto open source.

— Istantanea
fonte
4

Github ha molti modi di collaborare a un progetto. Il modello che utilizza maggiormente il progetto è un modello di richiesta pull. Ho avviato un progetto per aiutare le persone a fare la loro prima richiesta pull su GitHub. Puoi fare il tutorial pratico per fare il tuo primo PR qui

Il flusso di lavoro è semplice come

  • Fork il repo in github
  • Clona il repository sulla tua macchina
  • Crea un ramo e apporta le modifiche necessarie
  • Invia le modifiche al fork su GitHub git push origin branch-name
  • Vai al tuo fork su GitHub per vedere un Compare and pull requestpulsante
  • Cliccaci sopra e fornisci i dettagli necessari
— sudo bangbang
fonte
2

Flusso di lavoro tecnico

Vorrei suggerire il seguente flusso di lavoro:

  1. Fork il repository (tramite l'interfaccia web di GitHub: pulsante "Fork")
  2. Nel repository biforcuto, copia l'URL

  3. Clona (nella riga di comando)

    git clone <url-from-your-workspace>

  4. Immettere la directory appena creata e creare un ramo

    cd <directory> git checkout -b <branchname>

  5. Ora apporta le tue modifiche

  6. Puoi creare uno o più commit dopo ogni modifica:

    commit -a

  7. Al termine, invia le modifiche

    git push origin <branch>

  8. Nella riga di comando, dovresti visualizzare un URL per creare il PR . Visita l'URL e fai clic sul pulsante per creare un PR.

  9. Altrimenti, visita il repository nel browser e ti offrirà un pulsante per creare la richiesta pull

Questo è tutto.

Quindi, in sostanza, hai indirizzato il repository nell'area di lavoro, creato un nuovo ramo e inviato quel nuovo ramo.

Se successivamente si effettuano più PR dallo stesso repository clonato, è necessario sincronizzare (ottenere le ultime modifiche dal repository originale) prima di creare un altro ramo per un altro PR:

git checkout master
git remote add upstream <url-of-original-repo>
git pull upstream master

Altre considerazioni:

  • il progetto può contenere linee guida per i contributi: cercare un file CONTRIBUTING.rst o .md
  • potresti voler seguire le linee guida per la codifica del progetto
  • potresti voler prima delineare la tua idea come problema
  • potresti voler esaminare la scheda Richieste pull per il progetto e verificare se ci sono PR aperte, PR unite

Questi suggerimenti sono qui per salvarti dal problema di mettere il lavoro in un PR che non verrà unito. Se c'è attività nel progetto e le PR vengono unite, questo è un buon segno. Se ci sono Linee guida per il contributo, seguile.

Sii sempre cortese. Ricorda che i manutentori del progetto non sono in alcun modo obbligati a unire il tuo PR. Hai qualcosa di prezioso da aggiungere al progetto?

— Sybille Peters
fonte
1
Processo ben dettagliato (più preciso della mia risposta di 9 anni). Upvoted.
— VonC
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.