Un collègue a soumis mon code comme étant le sien

Vous devriez lui envoyer un e-mail en lui disant quelque chose du genre :

Je vois que vous avez poussé le code de ma branche vers la branche principale. Veuillez garder à l'esprit que l'historique des révisions est important dans ce genre de produits, donc il faut éviter de couper et coller le code dans la branche principale, comme vous l'avez fait ; il faut plutôt pousser le code de la branche sur laquelle il a été développé.

et cc votre responsable. Cela permettra à votre directeur de prendre conscience du problème sans accuser directement votre collègue de mauvaise conduite, et de le présenter comme une préoccupation pour l'intégrité du projet plutôt que comme un crédit personnel.

Je le signalerais sans aucun doute à votre responsable en lui apportant la preuve que vous l'avez écrit en premier.

Ce n'est pas illégal comme dans un tribunal mais c'est mal et votre responsable devrait le savoir. Dites-lui que s'il recommence, vous le signalerez à nouveau.

Vous avez l'air assez en colère pour provoquer votre collègue en duel, mais beaucoup de développeurs sont plus discrets et pourraient apprécier une approche plus subtile pour obtenir justice.

Vous pourriez envoyer un e-mail à la personne qui a accepté le tirage avec vos “préoccupations” concernant votre code encore en développement apparaissant sur le master. Vous n'avez même pas besoin de faire des allégations ; laissez-les “découvrir” ce qui s'est passé par eux-mêmes. Dites que votre code devrait être bon, mais que vous n'avez pas fini de le tester et de le modifier, et que vous êtes perplexe ou préoccupé par la façon dont il est apparu sur master sans que vous ayez soumis une demande d'extraction.

Cela supprime la plupart des problèmes, mais préserve une bonne possibilité pour votre collègue d'être réprimandé, une fois qu'il aura découvert comment le code est arrivé de façon inappropriée sur master. Je peux voir des gens à l'esprit technologique se laisser décourager par un conflit, ce qui les rend moins excités à l'idée de creuser la question, mais ils voudront presque certainement comprendre ce qui s'est passé s'ils sont abordés comme un “WTF” au lieu d'une allégation apparemment scandaleuse.

Si les choses se passent comme prévu, l'enquête sera brève et concluante. Il semble que vous soyez un meilleur travailleur de toute façon, donc le temps va trier le bon grain de l'ivraie ; soyez magnanime et ne “frappez pas” dans la politique de bureau.

Woah Betty, décomposons cela :

Un collègue a volé le code entièrement et prétend avoir tout écrit

^ C'est assez sérieux. S'il dit aux gens “c'est le travail que j'ai fait”, alors dites à votre manager “Hé, je voudrais juste vous montrer cette page github pour montrer que je suis l'auteur de tout ce travail, alors que Bob n'a fait que cette fusion. Je vous le signale parce que je ne veux pas que vous ayez l'impression que je n'ai pas fait ma part du travail, et en même temps ça me dérange que Bob essaie de s'attribuer le mérite du travail qu'il n'a pas fait”

Mais

Aujourd'hui, Bob fusionne du code dans notre branche principale.

Est-ce que Bob “prétend” vraiment qu'il a tout écrit ? Ou bien a-t-il simplement fusionné une branche dans master, et personne ne sait/se soucie du nom qui se trouve à côté de ce commit de fusion ? Dans mon entreprise, à moins que la direction n'examine un désastre, personne ne regarde qui est l'auteur de quel engagement.

Outre git, y a-t-il un autre outil de gestion de projet que votre directeur utilise pour voir combien de travail chacun fait ? Si oui, un nom sur un commit ne signifie rien. Sinon, la gestion est suffisamment mauvaise pour que personne ne regarde l'historique de git de toute façon.

Vous aviez un code. Il a utilisé ce code pour accomplir sa tâche. Cette partie est parfaitement acceptable. Aucune raison d'écrire une solution quand une solution existante fonctionne.

Vous vouliez que le code soit crédité. Vous dites qu'il a utilisé un langage comme Me and I dans les git commit contenant votre code. Les git commits ne devraient pas être un outil de gestion, ni un outil permettant d'attribuer un crédit pour le travail effectué. Le logiciel ou le système de gestion de projet utilisé doit permettre de déterminer qui est crédité pour quoi. Si vous êtes tous deux affectés à la même tâche, la direction s'attend probablement à ce que vous utilisiez les idées et le code de l'autre. Vous devriez tous les deux être sur la même branche honnêtement s'il s'agit d'une tâche commune.

Le vrai problème est votre préoccupation concernant ses compétences et/ou son éthique du travail. Vous devez traiter ce point séparément de cet incident particulier.

Vous devez d'abord en parler à votre collègue. Pour l'instant, il semble que cela ne se soit produit qu'une seule fois. J'ai souvent respecté le code de mes collègues et j'ai laissé mes collègues le faire. Mais si cela vous concerne, n'hésitez pas à lui dire que l'histoire de votre collègue est importante et que vous aimeriez que votre nom soit associé à l'un des codes que vous avez commis. Insistez sur le fait que s'il y a un bug dans le code, vous ne voulez pas qu'il soit faussement accusé.

S'il continue à avoir de mauvaises performances dans son travail, parlez à la direction de ses performances (pas des engagements). Vous pouvez mentionner que ses engagements utilisent souvent votre code, mais n'en faites pas une remarque, car il n'y a rien d'intrinsèquement mauvais à cela en soi. Vous devez juste préciser qu'ils ne doivent pas utiliser les engagements pour évaluer ses compétences ou son éthique professionnelle parce qu'il s'agit de votre code.

**Lisez également le manuel de l'employé de votre entreprise, il est probable qu'elle ait une politique sur les comportements non éthiques et la procédure à suivre pour les signaler

Lorsque vous signalez un comportement non éthique, assurez-vous qu'il est écrit ou envoyé par e-mail**, car si vous devez vous y référer plus tard, vous devez avoir une preuve très claire que cela s'est produit et qu'une plainte a été déposée.

Votre objectif est-il de vous assurer que le code que vous avez écrit est à votre crédit ?

L'idée que le code soit “à vous” n'est généralement pas une bonne façon de penser au travail que vous faites pour l'entreprise. Le code que vous écrivez ne vous appartient pas, il appartient à l'entreprise. Peu importe que le code ait été rédigé par votre branche ou par la branche de Bob. Vous et Bob avez pour objectif commun d'accomplir toutes les tâches nécessaires au produit.

C'est une chose si votre directeur pense que vous ne faites pas votre part, mais que Bob le fait, mais votre question donne plutôt l'impression que vous avez été volé.

Certains commentaires ont abordé ce point ; mais les réponses (surtout la réponse acceptée) semblent aller dans une direction très différente. La bonne marche à suivre dépend de vos objectifs réels ; mais à moins que votre responsable ne passe en revue les journaux d'engagement pour s'assurer que vous et Bob faites chacun suffisamment de travail, je ne ressentirais pas le besoin de faire quoi que ce soit pour remédier à cette situation.

Il semble que la pire chose que Bob ait faite ici ait été de ne pas suivre les meilleures pratiques en matière de contrôle des sources. Fusionner vos modifications aurait permis d'obtenir un meilleur historique des révisions que de copier/coller vos modifications. Il est raisonnable de lui expliquer cela, et d'expliquer les raisons. Mais d'après les informations dont nous disposons dans la question, il ne s'agit pas d'un problème pour lequel vous devez écrire formellement quelque chose et vous assurer de copier votre responsable. Il suffit de le lui mentionner simplement.

Cela ressemble à une fusion qui a mal tourné ; je ne prétends pas comprendre git assez bien pour savoir exactement pourquoi cela se produit, mais Visual Studio crée parfois des commit sur son dépôt local lorsque vous utilisez l'IDE pour résoudre des conflits de fusion. Cela apparaît dans l'histoire comme ayant pris toutes les modifications du dépôt distant, les ayant appliquées à son propre dépôt, les ayant committées, puis ayant appliqué ce commit au dépôt distant.

L'explication rationnelle ici est que Bob a cliqué sur le processus de fusion sans vraiment le comprendre et a généré un historique de contrôle des sources qui est trompeur. En travaillant sur cette hypothèse, interrogez-le avec lui dans l'intention de l'éduquer sur la manière de fusionner correctement, en lui donnant le bénéfice du doute quant au fait que la question est une erreur.

Tout d'abord, identifiez le problème. Si le problème est que votre nom a été effacé de l'historique de Git (en supposant que vous utilisez Git) et remplacé par le sien, il s'agit d'un problème de gestion interne et probablement pas d'un signe de comportement malveillant de la part de votre collègue. Si un collègue est bloqué sur un bug pendant un mois qui en quelque sorte suggère qu'il pourrait être un peu rouillé dans l'utilisation de ses outils - y compris le contrôle de version.

Votre nom devrait figurer sur tout le code que vous avez écrit. Ce n'est pas une question de fierté ou d'honneur - vous devez garder cette histoire intacte pour que les gens sachent qui a écrit quelle ligne de code et à qui s'adresser en cas de bogue ou de décision de conception étrange à l'avenir. Si votre nom n'y figure plus, c'est votre collègue qui doit répondre aux questions concernant votre code et qui doit assumer la responsabilité de vos bogues !

Utilisez votre EDI ou un outil de contrôle des sources pour annoter le code et voir si son nom figure réellement sur chaque ligne. En général, peu importe qui a fusionné le code - son nom ne figure que sur ce commit, pas sur chaque ligne de code de ce commit. Si vous travaillez dans une organisation où “combien de code j'ai écrit” est une mesure qu'ils suivent et qu'ils utilisent à des fins de promotion, alors vous devriez en parler à la direction. Ne dites pas “il m'a volé” (vous ne savez pas qu'il l'a fait), dites “je crains que si vous regardez notre historique de contrôle des sources pour évaluer notre mérite pour les augmentations et les promotions, sa fusion donne l'impression que je n'ai rien contribué”.

Cela dépend beaucoup de la dynamique de votre entreprise. Dans mon cas (qui, je pense, est la norme pour la plupart des sociétés de logiciels professionnels), je serais à moitié ravi de voir mon nom disparaître du code que j'ai écrit… Maintenant, je n'ai plus de gens qui me posent des questions sur les décisions stupides que j'ai prises dans mon code des mois auparavant ! :)

Honnêtement, étant donné les détails fournis, le fait que tout le monde dise “signalez-le !” me semble être une réaction excessive.

Mon collègue et moi avons travaillé sur un projet pendant plus de deux ans en échangeant des engagements dans les deux sens, et oui , parfois nous réutilisions ou optimisions le code de l'autre.

Je ne sais pas dans quel type de culture vous travaillez, mais si elle définit le travail en lignes de code plutôt qu'en produit final et en contribution globale, cela semble plutôt toxique et compétitif. Mon conseil serait que vous ne remontiez pas la chaîne de commandement à la recherche d'une forme de rétribution. Si c'est si important pour vous, parlez à votre responsable de la manière de déterminer le crédit des choses et de les documenter de la manière qu'elles décrivent.

Le point que je voulais le plus aborder était votre relation avec votre collègue. À mon avis, si mon collègue s'approchait un jour de moi et s'exclamait : “N'utilisez pas mon code ! et qu'il me causait ensuite des ennuis avec la direction pour quelque chose que je ne faisais pas exprès ou malicieusement, je penserais qu'il est un imbécile qui se respecte. Je garderais cela à l'esprit, parce qu'il n'est pas clair, à partir de la question, s'ils ont vraiment volé votre code, ou s'ils ont simplement apporté des changements de manière étrange.

L'accusation (qui est une grosse accusation à faire) - si elle ne ruine pas complètement votre relation professionnelle, elle abaisserait très certainement l'opinion personnelle qu'ils ont de vous. Ce n'est pas grave si vous avez raison. Je suis un adepte de la réflexion du type "vous creusez votre propre tombe” - mais si vous vous trompez, les dommages causés à votre relation professionnelle pourraient être assez importants. La politique de bureau est une chose délicate !

Maintenant, si vous êtes absolument certain qu'il vole et s'attribue le mérite de choses qu'il n'a pas faites, n'hésitez pas à contacter votre responsable et à prendre les mesures appropriées pour vous assurer qu'il soit réprimandé pour ce type de comportement - cependant, si vous n'êtes pas vraiment sûr, reconsidérez peut-être la question. Le plagiat n'est pas une chose à revendiquer à la légère, surtout lorsqu'il peut affecter votre vie quotidienne pendant assez longtemps.

Discutez avec votre collègue et votre supérieur de ce qui se passe en réalité, mais ne les accusez pas de leur intention.

Ce qui se passe en réalité, c'est qu'ils ont fusionné votre code comme si c'était le leur. Cela peut avoir été fait par vengeance personnelle pour vous faire passer pour un idiot, mais c'est une accusation d'intention, qui est beaucoup plus difficile à prouver, et sur la base de ce que vous avez posté, rien n'indique une quelconque intention malveillante de la part de votre collègue.

Concentrez-vous sur le fait de faire de ce moment un moment d'enseignement, en supposant son ignorance sur les façons d'utiliser correctement git. Git fournit de nombreuses façons de permettre à un développeur de réutiliser le code d'un autre développeur tout en préservant sa paternité. Les deux outils principaux sont la commande “merge” et “cherry-pick”.

Dites-leur d'être conscients que la préservation des métadonnées et de la paternité de l'histoire est importante dans le projet.

Les méta-informations telles que la paternité existent dans un système de contrôle de version tel que git, non pas tant pour suivre la propriété mais plutôt pour aider à comprendre comment une chose est devenue ce qu'elle est.

Alors que les flux simples ont des fusions de commits ayant une paternité individuelle, il y a de nombreux cas où cela ne fonctionne pas, ou ne saisit pas l'histoire complète dans les champs à but fixe d'un commit.

Quelque chose comme refactoring ou même l'application de règles d'espacement nouvellement établies à un bloc de code implique ce que git considère comme une nouvelle paternité, puisque git ne comprend que des détails littéraux, et non le sens. Et ce n'est que dans les cas où le code continue à être utilisé dans son rôle original et à l'emplacement exact du fichier.

Beaucoup d'autres cas, comme le fait de baser la solution d'un nouveau problème sur du code copié à partir de la solution d'un problème plus ancien dans la base de code d'une entreprise, recherchent dans le monde entier un VCS comme une véritable nouvelle paternité.

Bien que ce soit loin d'être parfait, lorsque je crée un commit basé en grande partie sur un travail existant (en particulier celui de quelqu'un d'autre qui a été déplacé ou substantiellement retravaillé), j'essaie de mentionner son origine dans le message de commit. C'est un peu trop généreux, mais tout autant ou plus pour créer un enregistrement de la relation avec un autre code. Ainsi, par exemple, si un bogue est trouvé dans la nouvelle utilisation, il vaut la peine de vérifier s'il existe également à l'endroit d'où le code a été copié.

Compte tenu de cela, une bonne ligne de conduite pourrait être d'essayer d'utiliser un processus de révision du code pour que la fusion finale du code contesté se fasse sous un message plus descriptif, qui décrirait ses origines réelles. Et de présenter cet argument non pas tant pour préserver la “propriété” de la contribution, mais pour préserver la connaissance de l'origine du code, de sa relation avec d'autres codes et pour disposer d'une liste plus complète de qui solliciter en cas de difficulté.

Je ne sais pas si vous l'avez remarqué, mais lorsque vous avez un système de contrôle du code source et que deux personnes effectuent des modifications identiques, vous obtenez de nombreux “conflits de fusion” qui font que la fusion devient une opération longue et sujette aux erreurs.

Ainsi, lors de la prochaine réunion d'équipe, où toutes sortes de choses sont discutées, vous pouvez dire “… et à l'avenir, j'apprécierais que personne ne prenne des modifications incomplètes de ma branche et ne les fusionne dans la branche principale. J'ai perdu des heures et des heures de travail à résoudre des conflits de fusion à cause de cela”. Il est tout à fait possible que votre patron vous demande alors qui a fait ce genre de bêtises, et maintenant vous pouvez donner des noms au patron sans avoir l'air d'une balance.

Fusionnez son code en précisant qu'il l'a écrit. La gestion de vos propres fusions est une stratégie de viale. Il semble qu'il ne sache pas comment fonctionne GIT et qu'il ait oublié de se synchroniser avec vos changements. Commits avec tous’ le code des autres personnes est automatiquement généré par des outils comme l'arbre des sources dans le cas de personnes utilisant une mauvaise stratégie de fusion

Ce qui ne va pas c'est de spécifier “mon code” dans la description de la communauté.

Quand je suis frappé par un bug pendant un jour ( un mois semble trop. Jamais resté sur un bug pendant un mois) et que je fusionne des modifications, je dis spécifiquement que la fusion inclut ma correction de bug plus le code précédent d'autres personnes, et même en faisant cela, il ne semble pas que j'ai commis le code d'autres personnes.

Si votre collègue travaille sur une branche, il devrait d'abord fusionner la branche principale dans la sienne. Testez. Puis refusionner sa branche. S'il commence à copier le code de votre branche sans le fusionner puis le soumettre, il fait encore pire. Il travaille sur le versionnage, ce qui peut introduire de nouveaux bogues.

Je mettrais en place une politique de committ à suivre et obligerais tout le monde à la respecter. Je serais plutôt inquiet par sa compétence en GIT. Cela pourrait causer des dégâts

Oui, cela m'est arrivé une fois avec un collègue très inhabituel. Un jour, un responsable de l'assurance qualité m'a dit que mon code est exactement le même que celui de cet autre collègue. Je me suis connecté à GitHub et j'ai remarqué que le code est étrangement similaire au mien, mais j'ai d'abord pensé que peut-être, puisque nous hébergeons plusieurs sites partageant le même fichier, le code est simplement le même puisqu'il fait la même chose.

Au fil du temps, j'ai observé que la collègue disait qu'elle travaillait sur la “refactorisation du code” pendant les stand-up quotidiens jusqu'au dernier jour du sprint, puis qu'elle disait que son code n'était pas prêt le dernier jour et qu'elle avait besoin d'un jour supplémentaire, et enfin, mystérieusement, le jour suivant, des centaines de lignes de code ont été poussées vers le haut sur une demande d'extraction. J'ai regardé le code et j'ai remarqué qu'il était similaire au mien, jusqu'à une erreur d'orthographe que j'ai commise. J'ai alors réalisé que la personne attendait que je pousse ma branche et qu'elle observait et copiait des choses à partir de celle-ci.

J'étais aussi furieux que vous. Surtout parce que le collègue n'est pas venu me demander ce que j'allais volontiers aider ou diriger. C'est l'une des rares raisons pour lesquelles j'ai décidé de quitter l'entreprise après en avoir parlé à un directeur qui ne semblait pas s'en soucier. **Mon conseil est d'en parler à un responsable, de mettre une faute d'orthographe dont vous pouvez prouver qu'elle ne peut pas être reproduite par hasard. Ainsi, vous pourrez dire qu'il ne s'agit pas d'une simple coïncidence.