7
votes

Comment gérer les correctifs de projets open source qui ne peuvent pas pousser à en amont?

Je travaille sur un projet open source. Maintenant, j'ai terminé quelques correctifs qui sont pertinents pour l'entreprise de la société et je ne peux pas pousser ces patchs à en amont.

Donc, je dois garder ces patchs sur mon référentiel git local. Je dois retirer les nouvelles patchs de l'amont et résoudre les conflits avec mes patchs.

Quelqu'un a mon expérience similaire et comment travailler avec elle confortablement?

mise à jour: Tout comme si j'ai plusieurs correctifs ne peut pas être accepté par le noyau Linux, car ces patchs sont hostiles au noyau. Je dois faire un bâtiment quotidien du noyau et je ne veux pas taper à la main tous les jours. Existe-t-il des outils pour m'aider?


7 commentaires

Pourquoi ne pouvez-vous pas pousser? Avez-vous une description d'erreur ou quelque chose?


Le projet sur GitHub?


Si le projet est open source, pouvez-vous nous dire quel projet il s'agit? Peut-être pouvons-nous savoir comment ce projet particulier veut gérer les soumissions.


Peut-être que le patch contient des secrets internes que l'OP n'est pas autorisé à se soumettre au public?


Merci pour votre aide enthousiaste, mais ce n'est pas le problème du projet. Juste à cause de mes patchs contient la contraction des entreprises hostiles.


En un mot, je ne devrais pas et ne peux pas le pousser à en amont.


Dupliqué possible de Maintenance des correctifs personnalisés sur le code tiers


4 Réponses :


1
votes

Premièrement avant de modifier le projet -

1. $ git branch <branch name>           // To create a new branch
2. $ git checkout <branch name>         // To change to the branch
3. $ git checkout master                // To change to the master branch


2 commentaires

Existe-t-il un système de gestion à traiter? Comme si j'ai beaucoup de taches et de plusieurs projets, ce sera une chose qui prendra beaucoup de temps pour garder mon référentiel local mis à jour.


Dès maintenant, je n'utilise aucun système de gestion. Mais comme vous l'avez dit à juste titre, il y en a besoin. Je vais mettre à jour une fois que j'ai trouvé un bon outil qui aide à travailler sur plusieurs projets



-1
votes

Je travaille sur un projet open source. Maintenant, j'ai terminé quelques correctifs qui sont pertinents pour l'entreprise de la société et je ne peux pas pousser ces patchs à en amont.

Si vous collaborez sur un projet dans Git, surtout s'il est open source, les gens ne vous laisseront probablement pas simplement pousser tout ce que vous voulez à la répétition en amont. Vous souhaitez probablement soumettre vos modifications dans une requête de traction ou envoyer vos correctifs à l'un des gestionnaires de projet.

Vous pouvez en savoir plus sur la collaboration avec d'autres personnes à partir de ces PRO Git Chapitres:

  1. flux de travail distribué
  2. Contribuer à un projet

    Si vous êtes intéressé, vous pouvez également lire sur Comment GITUB utilise des demandes de tir .


0 commentaires

5
votes

Je suis un peu surpris que les réponses jusqu'à présent ne semblent pas prendre en compte deux choses:

  1. Toutes les modifications apportées par programmeurs ne sont pas conçues ou adaptées à la soumission à un projet open source.
  2. Même lorsqu'il est, s'il y a une mise à jour du référentiel pendant que vous travaillez sur votre code, vous souhaitez très souvent fusionner ces changements dans votre copie de travail.

    La bonne chose est que, puisque vous travaillez avec un logiciel de contrôle de version décent n'est généralement pas si difficile à faire ce dont vous avez besoin. Je suis un gars de subversion (en raison de la politique de l'entreprise), donc je ne connais donc pas spécifiquement de git, mais après avoir lu Cet article Wiki semble à peu près le même accord. Vous n'avez plus d'appliquer les correctifs à nouveau aussi longtemps que vous adaptez les fichiers de votre référentiel local. Vous pouvez mettre à jour la copie locale avec les correctifs déjà appliqués!

    Votre code personnalisé touche probablement une très petite fraction du code du référentiel. Il est probable que la plupart des changements dans le référentiel ne touchent pas le même code que vous avez touché. Vous aurez simplement besoin d'utiliser la commande GIT Pull pour télécharger tout le code mis à jour. Lorsque les sections que vous avez touchées sont modifiées sur le référentiel, GIT fera mieux de fusionner ces changements. La seule fois où vous avez à la main, Modifier les fichiers est-elle GIT détecte un conflit qu'il ne peut pas résoudre. L'article que j'ai mentionné, en parle plus tôt à ce sujet.

    Vous pouvez utiliser votre éditeur de texte préféré, mais il est très pratique d'utiliser un outil de fusion à 3 voies dans ce cas. Meld est l'un de ces outils pour Linux, mais je suis sûr qu'il y en a beaucoup dehors.


0 commentaires

2
votes

Voici un flux de travail possible.

Configuration initiale forte> p>

git checkout master
git pull upstream
git checkout patched
git rebase master


0 commentaires