Quelle est la bonne étiquette et le flux de travail GitHub recommandé pour contribuer et différer simultanément du dépôt en amont?


21

Je suis nouveau sur GitHub et VCS en général. Je programme en plusieurs langues depuis des années, mais j'ai toujours travaillé en solo sur des projets personnalisés (pas de sorties publiques). J'ai récemment commencé à utiliser un widget jQuery UI que j'ai téléchargé depuis GitHub dans un projet sur lequel je travaille. Le dépôt n'est plus conservé par l'auteur d'origine. Une autre fourche a incorporé certaines des demandes de tirage d'origine. C'est celui dont j'ai bifurqué.

J'ai trouvé quelques bugs et ai trouvé les correctifs pour eux. J'aimerais apporter ces correctifs, mais j'ai également beaucoup d'autres changements que je veux apporter, pour notre propre usage, qui vont casser certaines des fonctionnalités existantes. De plus, j'aimerais incorporer une idée d'une autre fourchette.

J'apprends toujours GIT et GitHub et j'essaie de trouver la meilleure façon de tout faire. J'ai fait beaucoup de lecture (ici, SO, pages d'aide GitHub, Pro Git) sur différents concepts / tâches: workflows, fusion, demandes de tirage, sélection de cerise, rebasage, branchement. Ma matière grise nage et je dois commencer à le faire pour mieux comprendre ce que j'ai lu.

Problèmes principaux:

  1. Je pense avoir lu (quelque part) que vous ne pouvez avoir qu'une seule demande d'extraction sur une branche à la fois. Cela signifie-t-il que je devrais avoir une branche distincte pour chaque bogue, puis faire une demande de tirage distincte pour chacun?

  2. Je veux nettoyer les problèmes d'espaces blancs et je me souviens avoir lu qu'il est préférable de le faire dans un commit séparé. Dois-je le faire dans mon maître ou dans une succursale distincte? Je ne veux pas faire de pull request pour quelque chose d'aussi trivial , mais si je fais des changements d'espaces avant de créer une branche, cela affectera-t-il la pull request pour les corrections de bugs? Certaines fourches ont nettoyé les espaces blancs et cela a rendu le diff assez inutile.

  3. Je pensais créer des problèmes contre ma fourchette comme un moyen de documenter les bogues même si j'ai déjà le correctif pour eux. est-ce une bonne idée? Comment puis-je relier le problème, la validation et la fusion à maîtriser? Si je fais une demande d'extraction en amont, mon problème apparaîtra-t-il également en amont ou ce lien de documentation sera-t-il perdu? Je ne peux pas ouvrir un problème avec le dépôt en amont (il n'y a pas d'onglet de problème).

  4. Quelle est la meilleure façon de donner du crédit à l'autre auteur de fork pour l'idée que je veux utiliser? Je ne peux pas utiliser son code exactement, d'autant plus que sa modification s'applique à une ancienne version de l'amont et n'est pas compatible avec mes autres modifications telles quelles. Mais je veux utiliser l'idée et je veux donner du crédit là où le crédit est dû. Dois-je simplement créer un lien vers son référentiel (ou profil ou commit spécifique) dans mon message de commit?

  5. Quelle est l'étiquette concernant la modification du fichier Lisez-moi et du DocBlock en haut du fichier principal? Est-ce correct de faire des changements, d'ajouter mon nom, d'ajouter des liens vers mon repo et ma démo, de supprimer des liens vers la démo d'origine (puisque ma fourchette finira par être incompatible avec l'original)? Bien sûr, je vais laisser le nom de l'auteur d'origine et les informations de licence. Pour mémoire, il est sous licence MIT.

En tant que développeur solo qui n'a jamais utilisé VCS, je suis habitué à réécrire l'histoire . Je suis perfectionniste et j'aime que les choses soient propres et bien rangées. L'idée de l'histoire enregistrée me rend un peu nerveux et je veux le faire correctement la première fois . J'ai créé un nouveau dépôt pour jouer / apprendre, mais je suis impatient de continuer à corriger le widget jQuery UI afin de pouvoir poursuivre mon projet.

Réponses:


15
  1. Correct: une pull-request est liée à une branche de votre référentiel. Si vous modifiez la branche, vous modifiez également ce que vous soumettez en tant que pull-request.

    Donc oui, vous devez créer une branche (et pull-request) par correction de bogue. Il pourrait être judicieux de commencer par un et de voir comment le responsable réagit à celui-ci avant de faire le reste. L'open source est un processus intrinsèquement social.

  2. Faites une pull-request pour vos changements d'espaces! S'exprimant comme quelqu'un qui est parfois mainteneur, j'aime ce type de pull-request: je les approuve ou non, et elles prennent peu de temps à traiter.

    Ce que vous pourriez également rencontrer, c'est que le responsable n'est pas d'accord avec vos changements d'espaces! Alors, méfiez-vous ..

  3. Hmm .. Ce n'est pas clair ce que vous essayez de réaliser ici. Cela ressemble à une documentation excessive et pas une bonne idée - peut-être pouvez-vous clarifier pourquoi vous voudriez faire cela?

  4. Un lien vers son dépôt dans votre message de validation (ou même dans un commentaire dans le code) est un excellent moyen de donner du crédit. Soyez prudent cependant - expliquez que vous le remerciez pour ses idées et non pour son code. Si vous avez copié du code, je lui enverrais un e-mail à ce sujet, sauf s'il est très clair quelle licence il utilise pour son code. Si la licence est claire (et qu'il s'agit d'une licence différente du référentiel auquel vous soumettez la validation), vous devez ajouter la licence différente dans votre pull-request et également le mentionner dans votre message de pull-request.

  5. C'est une très bonne question qui diffère selon la personne à qui vous parlez. Mon opinion est que vous ne devez jamais ajouter votre nom à un commit ou à un code que vous faites. La raison principale est qu'elle implique "la propriété et la responsabilité du code" - cela pourrait empêcher les autres de modifier le code parce que "c'est le vôtre". Mais maintenant, nous entrons dans une énorme discussion sur la nature de l'open source, alors je vais m'arrêter ici et dire - demander au responsable du projet ou simplement le faire et voir ce que sa réaction est.

  6. Vous pouvez réécrire (votre historique local, pas encore publié) avec GIT! Apprenez la commande git rebase - c'est l'une des principales raisons pour lesquelles j'aime git. C'est une très mauvaise idée de (forcer) de pousser les validations / l'historique réécrits vers le référentiel partagé (github, par exemple). Cela va ensuite visser avec les référentiels que les autres développeurs ont - ils devront faire des choses difficiles lors de l'extraction de vos modifications (historique réécrit).

[# 6: Merci @toxalot!]


Pour le n ° 6, oui, vous pouvez réécrire l'histoire, mais uniquement l'histoire locale. Une fois qu'il est poussé vers un dépôt public, c'est une très mauvaise idée de réécrire l'histoire.
toxalot
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.