Comment puis-je contribuer au code des autres dans GitHub? [fermé]

231

Je voudrais contribuer à un certain projet dans GitHub . Dois-je le fourche ? Branche- le? Qu'est-ce qui est recommandé et comment le faire?

git  open-source  github 
— wizztjh
source
61
Une autre clôture ridicule
— Stephen
4
J'ai écrit un guide étape par étape plus détaillé sur la contribution à Concrete5 sur Github, mais le processus peut s'appliquer à n'importe quel projet. Vérifiez-le .
— Joe Meyer
7
Je ne vois pas vraiment comment ce n'est «pas constructif». Les votes et les opinions à eux seuls prouvent que c'est une question populaire à laquelle les gens cherchent à répondre.
— Ian
4
— Konstantinos
1
peut-être qu'avec un vote à la majorité suffisant, les questions précédemment fermées devraient pouvoir être ressuscitées et laisser les gens contribuer à nouveau au fil.
— Peter Teoh

Réponses:

180

Idéalement vous:

  1. Fork le projet
  2. Faites un ou plusieurs commits bien commentés et propres dans le référentiel. Vous pouvez créer une nouvelle branche ici si vous modifiez plusieurs pièces ou fonctions.
  3. Exécutez une requête Pull dans l'interface Web de Github.

s'il s'agit d'une nouvelle demande de fonctionnalité, ne commencez pas le codage en premier. N'oubliez pas de publier un problème pour discuter de la nouvelle fonctionnalité.

Si la fonctionnalité est bien discutée et qu'il y en a +1 ou que le propriétaire du projet l'a approuvée, attribuez-vous le problème, puis suivez les étapes ci-dessus.

Certains projets n'utilisent pas le système de demande d'extraction. Vérifiez auprès de l'auteur ou de la liste de diffusion la meilleure façon de réintroduire votre code dans le projet.

— Yann Ramin
source
4
— Gabriel Grant
1
Oui, tirez la demande. La demande de fusion est une terminologie délicate.
— Yann Ramin
2
@MariusKavansky c'est l'inverse! Une fois que vous savez sur quoi travailler, alors seulement vous contribuez :)
— hashbrown
après avoir contribué à un projet open source. Je pense que c'est une meilleure idée d'ouvrir un problème pour discuter de la nouvelle fonctionnalité si c'est une nouvelle fonctionnalité. Si c'est une fonctionnalité ou un problème qui est bien discuté, vous devez vous attribuer le problème, puis suivez les étapes ci-dessus. Ceci est mes 2 cents.
— wizztjh
@hashbrown, Il demande où est la "liste" des fonctionnalités demandées jusqu'à présent. Ces fonctionnalités qui sont déjà demandées et +1.
— Pacerier
31

Pour ajouter à la réponse de Yann , une fois que vous avez bifurqué un projet, vous pouvez développer dans n'importe quelle branche de votre choix (une nouvelle ou une du projet d'origine)

Se souvenir de:

— VonC
source
1
pouvez-vous ajouter des détails ou des liens sur votre deuxième point (branche de rebasage) ?
— JorgeArtware
1
@JorgeArtware J'ai mis à jour la réponse avec quelques liens illustrant le rebase.
— VonC
@VonC Je pose une question ici mais si vous croyez que c'est nécessaire, j'en ferai une toute nouvelle question. Pourquoi devrais-je rebaser au lieu de fusionner, à part avoir une «histoire simple»? En d'autres termes, voici ce que je fais lorsque je contribue à certains projets (après que le RP de ma branche de fonctionnalités a été fusionné pour se développer et pour masteriser les branches): de git checkout master; git pull;même pour le développement (où ma branche de fonctionnalités a été fusionnée en premier) La différence que je peux penser de, après avoir lu "pull vs pull --rebase" et "merge vs rebase" n'est que l'histoire plate. Autre chose de plus profond?
— linuxbandit
@grasshopper en terme de "contribution" (le contexte de cette page), vous souhaitez toujours rebaser vos commits locaux au dessus des branches mises à jour avant de pousser: cela rendra cette contribution triviale à intégrer par le mainteneur à la branche de projet d'origine. Dans le contexte de votre question, où votre PR a été accepté, bien sûr, vous pouvez fusionner au lieu de rebaser pour mettre à jour les branches existantes.
— VonC
(Désolé, le nom d'utilisateur a changé juste pour refléter mon github) - @VonC merci, donc toutes les suggestions que je lisais sur le rebase s'appliquent avant le PR, ont du sens. Pour refléter le PR accepté et fusionné dans mon référentiel local, y a-t-il une pratique courante (rebaser au lieu de fusionner), ou puis-je faire quoi que ce soit? Et si je soumets un autre RP?
— linuxbandit
15

Pour ajouter aux réponses de Yan et VonC, c'est une bonne ressource de github eux-mêmes: http://help.github.com/forking/

Assurez-vous également de regarder dans la barre latérale droite sous la rubrique "Collaboration".

— brycemcd
source
10

Il y a une excellente vidéo Railscast ici qui vous guide à travers le processus. Il contient également un certain nombre de bons conseils tels que montrer comment déterminer la branche sur laquelle vous souhaitez travailler lors de la contribution, à l'aide de tests, de sous-modules, etc.

Bien que cette capture d'écran soit principalement axée sur les développeurs Rails, la plupart des informations sont valables pour contribuer à tout projet open source.

— Instantané
source
4

Github a plusieurs façons de collaborer à un projet. Le modèle que la plupart des projets utilisent est un modèle de demande d'extraction. J'ai lancé un projet pour aider les gens à faire leur première demande d'extraction GitHub. Vous pouvez faire le tutoriel pratique pour faire votre premier PR ici

Le flux de travail est aussi simple que

  • Fork le repo dans github
  • Clonez le dépôt sur votre machine
  • Créez une succursale et apportez les modifications nécessaires
  • Poussez vos modifications sur votre fork sur GitHub git push origin branch-name
  • Accédez à votre fourchette sur GitHub pour voir un Compare and pull requestbouton
  • Cliquez dessus et donnez les détails nécessaires
— sudo bangbang
source
2

Workflow technique

Je suggère le workflow suivant:

  1. Forkez le référentiel (via l'interface web GitHub: bouton "Fork")
  2. Dans votre référentiel forké, copiez l'URL

  3. Cloner (en ligne de commande)

    git clone <url-from-your-workspace>

  4. Entrez dans le répertoire qui vient d'être créé et créez une branche

    cd <directory> git checkout -b <branchname>

  5. Maintenant, faites vos changements

  6. Vous pouvez créer un ou plusieurs validations après chaque modification:

    commit -a

  7. Une fois terminé, appuyez sur vos modifications

    git push origin <branch>

  8. Dans votre ligne de commande, vous devriez voir une URL pour créer le PR . Visitez l'URL et cliquez sur le bouton pour créer un PR.

  9. Sinon, visitez le référentiel dans le navigateur et il vous proposera un bouton pour créer la pull request

C'est tout.

Donc, en gros, vous avez bifurqué le référentiel vers votre espace de travail, créé une nouvelle branche et poussé cette nouvelle branche.

Si vous effectuez plus de RP à partir du même référentiel cloné, vous devez synchroniser (obtenir les dernières modifications du référentiel d'origine) avant de créer une autre branche pour un autre PR:

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

Autres considérations:

  • le projet peut avoir des directives de contribution: recherchez un fichier CONTRIBUTING.rst ou .md
  • vous voudrez peut-être suivre les directives de codage du projet
  • vous voudrez peut-être d'abord décrire votre idée comme un problème
  • vous voudrez peut-être regarder l'onglet Pull Requests pour le projet et vérifier s'il y a des RP ouverts, des PR fusionnés

Ces suggestions sont là pour vous éviter d'avoir à mettre du travail dans un PR qui ne sera pas fusionné. S'il y a une activité dans le projet et que les RP fusionnent, c'est un bon signe. S'il existe des directives de contribution, suivez-les.

Soyez toujours courtois. N'oubliez pas que les responsables du projet ne sont en aucun cas obligés de fusionner votre PR. Avez-vous quelque chose de précieux à ajouter au projet?

— Sybille Peters
source
1
Processus bien détaillé (plus précis que ma réponse de 9 ans). A voté.
— VonC
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.