Kollege hat meinen Code als seinen eigenen eingereicht [geschlossen]

Ich würde es auf jeden Fall Ihrem Vorgesetzten mit dem Beweis melden, dass Sie es zuerst geschrieben haben.

Es ist nicht illegal wie vor Gericht, aber es ist falsch und Ihr Vorgesetzter sollte es wissen. Sag ihm, wenn er es noch einmal tut, wirst du ihn wieder anzeigen.

Sie sollten ihm eine E-Mail schicken, in der Sie etwas in der Art sagen:

Wie ich sehe, hast du den Code von meinem Branch auf den Master-Branch gepusht. Bitte denken Sie daran, dass der Revisionsverlauf bei dieser Art von Produkten wichtig ist, daher sollte vermieden werden, dass Code ausgeschnitten und in den Hauptzweig eingefügt wird, wie Sie es getan haben. vielmehr sollte der Code aus dem Zweig gepusht werden, auf dem er entwickelt wurde.

und cc auf Ihren Vorgesetzten. Dadurch wird Ihr Vorgesetzter auf das Problem aufmerksam gemacht, ohne Ihren Kollegen direkt des Fehlverhaltens zu beschuldigen, und es als Besorgnis um die Integrität des Projekts und nicht als persönliche Anerkennung bezeichnet.

Du klingst wütend genug, um den Kollegen zu einem Duell herauszufordern, aber viele Entwickler sind zurückhaltender und schätzen vielleicht einen subtileren Ansatz, um Gerechtigkeit zu erlangen.

Sie könnten jemandem, der den Pull akzeptiert hat, eine E-Mail mit Ihren "Bedenken" bezüglich Ihres noch in der Entwicklung befindlichen Codes senden, der auf dem Master erscheint. Sie müssen nicht einmal Vorwürfe machen; lass sie selbst "herausfinden", was passiert ist. Angenommen, Ihr Code sollte gut sein, aber Sie waren mit dem Testen und Optimieren noch nicht fertig und sind verwirrt/besorgt darüber, wie er es in den Master geschafft hat, ohne dass Sie eine Pull-Anfrage gesendet haben.

Dies beseitigt den größten Teil des Dramas, bewahrt aber eine gute Möglichkeit für Ihren Kollegen, gerügt zu werden, sobald er herausgefunden hat, wie der Code unangemessen auf den Master gelangt ist. Ich kann mir vorstellen, dass einige technikbegeisterte Leute von Konflikten abgeschreckt werden, was sie weniger begeistert davon macht, sich damit zu beschäftigen, aber sie werden mit ziemlicher Sicherheit herausfinden wollen, was passiert ist, wenn sie als „WTF“ und nicht als scheinbar unverschämte Anschuldigung angesprochen werden.

Wenn die Dinge wie behauptet sind, wird die Untersuchung kurz und schlüssig sein. Es hört sich so an, als wären Sie sowieso ein besserer Arbeiter, also wird die Zeit die Spreu vom Weizen trennen; Seien Sie großmütig und "schlagen" Sie nicht in die Büropolitik ein.

Woah Betty, lass uns das aufschlüsseln:

Der Kollege hat den Code vollständig gestohlen und behauptet, er habe alles geschrieben

^ Das ist ziemlich ernst. Wenn er herumgeht und den Leuten sagt "das ist die Arbeit, die ich gemacht habe", dann sagen Sie Ihrem Vorgesetzten auf jeden Fall: "Hey, ich möchte Sie nur auf diese Github-Seite verweisen, um zu zeigen, dass ich der Autor all dieser Arbeit bin, während Bob nur diese eine wurde zusammengeführt Ich weise darauf hin, weil ich nicht möchte, dass Sie den Eindruck haben, dass ich nicht meinen Anteil an der Arbeit geleistet habe, und mich gleichzeitig stört, dass Bob versucht, dies zu übernehmen Anerkennung für die Arbeit, die er nicht geleistet hat."

Aber

Heute führt Bob etwas Code in unseren Master-Branch ein.

„Behauptet“ Bob wirklich, dass er alles geschrieben hat? Oder hat er einfach einen Zweig mit dem Master zusammengeführt, und niemand weiß/kümmert sich darum, welcher Name neben diesem Merge-Commit steht? In meiner Firma würde sich niemand ansehen, wer welches Commit erstellt hat, es sei denn, das Management überprüfte eine Katastrophe.

Gibt es neben Git noch ein anderes Projektmanagement-Tool, das Ihr Manager verwendet, um zu sehen, wie viel Arbeit alle leisten? Wenn ja, hat ein Name auf einem Commit keine Bedeutung. Wenn nicht, dann ist das Management so schlecht, dass ich nicht glaube, dass irgendjemand auf jeden Fall die Git-Geschichte sehen würde.

Du hattest Code. Er benutzte diesen Code, um seine Aufgabe zu erledigen. Dieser Teil ist vollkommen akzeptabel. Kein Grund, eine Lösung zu schreiben, wenn eine vorhandene Lösung funktioniert.

Sie wollten Anerkennung für den Code. Sie erwähnen, dass er in den Git-Commits, die Ihren Code enthalten, eine Sprache wie Me and I verwendet hat. Git-Commits sollten kein Management-Tool oder ein Tool sein, um geleistete Arbeit zu würdigen. Die verwendete Projektmanagement-Software oder das verwendete System sollte festlegen, wer für was Anerkennung erhält. Wenn Ihnen beide dieselbe Aufgabe zugewiesen wurde, erwartet das Management wahrscheinlich, dass Sie die Ideen und den Code des anderen verwenden. Sie sollten ehrlich gesagt beide auf demselben Ast sein, wenn es sich um eine gemeinsame Aufgabe handelt.

Das eigentliche Problem sind Ihre Bedenken hinsichtlich seiner Fähigkeiten und/oder Arbeitsmoral. Das sollte getrennt von diesem speziellen Vorfall angesprochen werden.

Sie sollten zuerst mit Ihrem Kollegen sprechen. Klingt im Moment so, als wäre das nur einmal passiert. Ich habe oft den Code meiner Kollegen festgeschrieben und habe Kollegen meinen Code festschreiben lassen. Wenn es Sie jedoch betrifft, können Sie ihm gerne sagen, dass der Git-Verlauf wichtig ist und Sie möchten, dass Ihr Name an jeden Ihrer Codes angehängt wird, der übergeben wird. Bestehen Sie darauf, dass Sie nicht wollen, dass er fälschlicherweise beschuldigt wird, wenn es einen Fehler im Code gibt.

Wenn er bei seiner Arbeit weiterhin schlechte Leistungen erbringt, sprechen Sie mit dem Management über seine Leistung (nicht über die Verpflichtungen). Sie können erwähnen, dass seine Commits häufig Ihren Code verwenden, aber machen Sie das nicht zum Punkt, denn daran ist an sich nichts falsch. Sie müssen nur klarstellen, dass sie die Commits nicht verwenden sollten, um seine Fähigkeiten oder Arbeitsmoral zu bewerten, da es sich um Ihren Code handelt.

Melden Sie dies der Geschäftsleitung. Lesen Sie auch das Mitarbeiterhandbuch Ihres Unternehmens. Sie haben wahrscheinlich eine Richtlinie zu unethischem Verhalten und wie ihr Verfahren zur Meldung dieses Verhaltens aussieht.

Wenn Sie dies ebenfalls melden, vergewissern Sie sich, dass dies schriftlich / per E-Mail erfolgt, denn wenn Sie später darauf verweisen müssen, sollten Sie sehr gut dokumentieren, dass dies passiert ist und eine Beschwerde eingereicht wurde.

Ist es Ihr Ziel sicherzustellen, dass Sie für den von Ihnen geschriebenen Code Anerkennung erhalten?

Die Idee, dass Code „Ihr“ ist, ist im Allgemeinen keine gute Art, über die Arbeit nachzudenken, die Sie für das Unternehmen leisten. Der Code, den Sie schreiben, gehört nicht Ihnen; es gehört der firma. Es sollte keinen Unterschied machen, ob der Code von Ihrem Zweig oder von Bobs Zweig übertragen wurde. Sie und Bob haben ein gemeinsames Ziel, alle Aufgaben zu erledigen, die für das Produkt erforderlich sind.

Es ist eine Sache, wenn Ihr Vorgesetzter glaubt, dass Sie nicht Ihren Beitrag leisten, aber Bob tut es, aber Ihre Frage lässt es eher so klingen, als würden Sie sich ausgeraubt fühlen.

Einige der Kommentare haben dies angesprochen; aber die Antworten (insbesondere die akzeptierte Antwort) scheinen in eine ganz andere Richtung zu gehen. Die richtige Vorgehensweise hängt von Ihren tatsächlichen Zielen ab; Aber wenn Ihr Manager nicht die Commit-Protokolle überprüft, um sicherzustellen, dass Sie und Bob beide genug Arbeit leisten, würde ich nicht das Bedürfnis haben, etwas an dieser Situation zu ändern.

Es hört sich so an, als wäre das Schlimmste, was Bob hier getan hat, darin bestanden, Best Practices bei der Verwendung der Quellcodeverwaltung nicht zu befolgen. Das Zusammenführen Ihrer Änderungen hätte einen besseren Revisionsverlauf ermöglicht als das Kopieren/Einfügen Ihrer Änderungen. Es ist vernünftig, ihm dies zu erklären und die Gründe dafür zu erklären. Aber von den Informationen, die wir in der Frage haben; Dies ist kein Problem, bei dem Sie etwas formell aufschreiben und sicherstellen müssen, dass Sie Ihren Manager kopieren. Erwähne es ihm einfach beiläufig.

Das klingt nach einer fehlerhaften Zusammenführung; Ich gebe nicht vor, Git gut genug zu verstehen, um genau zu wissen, warum dies auftritt, aber Visual Studio erstellt manchmal Commits im eigenen lokalen Repository, wenn Sie die IDE verwenden, um Zusammenführungskonflikte zu lösen. Dies erscheint im Verlauf so, als ob alle Änderungen in das entfernte Repository übernommen, auf das eigene Repository angewendet, festgeschrieben und dann dieses Commit auf das entfernte Repository angewendet wurden.

Die rationale Erklärung hier ist, dass Bob durch den Zusammenführungsprozess geklickt hat, ohne ihn wirklich zu verstehen, und einen irreführenden Versionsverwaltungsverlauf generiert hat. Gehen Sie von dieser Annahme aus und befragen Sie ihn mit der Absicht, ihn darüber aufzuklären, wie er richtig zusammenführt, und im Zweifelsfall zu entscheiden, ob es sich um einen Fehler handelt.

Identifizieren Sie zunächst , was das Problem ist . Aus Ihrer gestellten Frage geht nicht ganz hervor.

Wenn das Problem darin besteht, dass Ihr Name aus dem Git-Verlauf entfernt (vorausgesetzt, Sie verwenden Git) und durch seinen ersetzt wurde, handelt es sich um ein Haushaltsproblem und wahrscheinlich nicht um ein böswilliges Verhalten Ihres Kollegen. Wenn ein Kollege einen Monat lang an einem Fehler feststeckt, deutet dies darauf hin, dass er bei der Verwendung seiner Tools – einschließlich der Versionskontrolle – etwas eingerostet sein könnte .

Ihr Name sollte auf allen von Ihnen geschriebenen Codes stehen. Dies ist keine Frage des Stolzes oder der Anerkennung, die Ihnen zusteht - Sie müssen diese Historie intakt halten, damit die Leute wissen, wer welche Codezeile geschrieben hat und mit wem sie sprechen können, wenn sie in Zukunft auf Fehler oder seltsame Designentscheidungen stoßen. Wenn Ihr Name nicht mehr darauf steht, dann ist Ihr Kollege derjenige, der Fragen zu Ihrem Code beantwortet und die Schuld für Ihre Fehler übernimmt!

Verwenden Sie Ihre IDE oder ein Quellcodeverwaltungstool, um den Code mit Anmerkungen zu versehen und zu sehen, ob sein Name tatsächlich in jeder Zeile steht. Im Allgemeinen spielt es keine Rolle , wer den Code zusammengeführt hat – sein Name steht nur auf diesem Commit, nicht auf jeder Codezeile in diesem Commit . Das fällt auseinander, wenn er Zweige nicht korrekt zusammengeführt hat, um dies zu erreichen, und das ist etwas, was er richtig machen muss.

Wenn Sie in einer Organisation arbeiten, in der „Wie viel Code ich geschrieben habe“ eine Metrik ist, die sie verfolgen und zu Werbezwecken verwenden, dann sollten Sie dies dem Management mitteilen. Sagen Sie nicht „er hat mich gestohlen“ (Sie wissen nicht, dass er es getan hat), sagen Sie „Ich mache mir Sorgen, dass, wenn Sie sich unsere Versionsverwaltungshistorie ansehen, um unseren Verdienst für Gehaltserhöhungen und Beförderungen zu beurteilen, seine Zusammenführung den Anschein erweckt als ob ich nichts beigetragen hätte".

Dies hängt stark von der Dynamik Ihres Unternehmens ab. In meinem Fall (was meiner Meinung nach die Norm für die meisten professionellen Softwareunternehmen ist) wäre ich halb erfreut, wenn mein Name aus dem von mir geschriebenen Code verschwinden würde ... Jetzt habe ich keine Leute mehr, die mir Fragen zu dummen Entscheidungen stellen ich gemacht in meinem Code Monate zuvor! :)

Ehrlich gesagt, angesichts der bereitgestellten Details sagt jeder, es zu melden! scheint mir nur eine große Überreaktion zu sein.

Mein Kollege und ich haben über 2 Jahre lang an einem Projekt gearbeitet und Commits hin und her ausgetauscht, und ja , manchmal haben wir den Code des anderen wiederverwendet oder optimiert.

Ich weiß nicht, in welcher Kultur Sie arbeiten, aber wenn es irgendwie die Arbeit in Codezeilen und nicht in Endprodukten und Gesamtbeiträgen definiert, scheint es ziemlich giftig und wettbewerbsfähig zu sein. Mein Rat wäre, dass Sie nicht die Befehlskette hochlaufen und nach irgendeiner Form von Vergeltung suchen. Wenn es für Sie eine so große Sache ist, sprechen Sie mit Ihrem Vorgesetzten darüber, wie Sie die Kreditwürdigkeit für Dinge bestimmen und dann auf die von ihm beschriebene Weise dokumentieren können.

Der Punkt, den ich am meisten ansprechen wollte, war Ihre Beziehung zu Ihrem Kollegen. Meiner ehrlichen Meinung nach, wenn mein Kollege eines Tages auf mich zukam und ausrief: „Verwende nicht meinen Code! Es ist mein Code! würde denken, er wäre ein selbstgefälliger Idiot. Ich würde dies im Hinterkopf behalten, da aus der Frage nicht klar ist, ob sie Ihren Code wirklich gestohlen haben oder ob sie vielleicht nur Änderungen auf seltsame Weise zusammengeführt haben.

Die Anschuldigung (was eine große Anschuldigung ist) - wenn es Ihre berufliche Beziehung nicht vollständig ruiniert, würde es mit Sicherheit ihre persönliche Meinung von Ihnen senken. Keine große Sache, wenn du recht hast. Ich bin ein Fan von „Du schaufelst dir dein eigenes Grab“-Denken – aber wenn du dich irrst , könnte der Schaden für deine Arbeitsbeziehung ziemlich groß sein. Büropolitik ist eine heikle Sache!

Wenn Sie sich jetzt absolut sicher sind, dass er stiehlt und Dinge anrechnet, die er nicht getan hat, können Sie sich gerne an Ihren Vorgesetzten wenden und die entsprechenden Maßnahmen ergreifen, um sicherzustellen, dass er für diese Art von Verhalten gerügt wird – jedoch, wenn Sie bin mir nicht ganz sicher , überlege vielleicht nochmal. Plagiate sind nicht leichtfertig zu beanstanden, besonders wenn sie Ihr tägliches Leben für längere Zeit beeinträchtigen können.

Metainformationen wie die Urheberschaft existieren in einem Versionskontrollsystem wie Git nicht so sehr, um den Besitz nachzuverfolgen , sondern um besser zu verstehen , wie etwas so geworden ist, wie es ist.

Während einfache Flows Commits mit individueller Urheberschaft zusammenführen, gibt es viele Fälle, in denen dies nicht funktioniert oder nicht die vollständige Geschichte in den Feldern mit festgelegtem Zweck eines Commits erfasst.

Etwas wie das Refactoring oder sogar das Anwenden neu etablierter Whitespace-Regeln auf einen Codeblock beinhaltet das, was Git als neue Urheberschaft betrachtet, da Git nur wörtliche Details versteht, nicht die Bedeutung. Und das nur in Fällen, in denen der Code weiterhin in seiner ursprünglichen Rolle und am genauen Dateispeicherort verwendet wird.

Viele andere Fälle, wie zum Beispiel das Basieren der Lösung eines neuen Problems auf Code, der von der Lösung eines älteren Problems innerhalb der Codebasis eines Unternehmens kopiert wurde, sieht für alle Welt nach einem VCS wie einer echten, neuen Urheberschaft aus.

Obwohl dies alles andere als perfekt ist, versuche ich, wenn ich einen Commit erstelle, der größtenteils auf vorhandener Arbeit basiert (insbesondere auf der Arbeit von jemand anderem, die entweder umgezogen oder grundlegend überarbeitet wurde), seinen Ursprung in der Commit-Nachricht zu erwähnen. Das ist etwas zu fair, aber genauso viel oder mehr, um eine Aufzeichnung der Beziehung zu anderem Code zu erstellen . Wenn also beispielsweise ein Fehler in der neuen Verwendung gefunden wird, lohnt es sich zu prüfen, ob er auch dort existiert, wo der Code kopiert wurde.

Angesichts dessen könnte es eine gute Vorgehensweise sein, zu versuchen, einen Codeüberprüfungsprozess zu verwenden, um die endgültige Zusammenführung des umstrittenen Codes unter einer aussagekräftigeren Nachricht durchzuführen, die seine tatsächlichen Ursprünge beschreibt. Und um dieses Argument nicht so sehr vorzubringen, um das "Eigentum" an Beiträgen zu bewahren, sondern um das Wissen darüber zu bewahren, woher der Code stammt, in welcher Beziehung er zu anderem Code steht, und um eine vollständigere Liste zu haben, von wem man Beiträge einholen kann Fall von Schwierigkeiten .

Beginnen Sie eine Diskussion mit Ihrem Kollegen und Vorgesetzten darüber, was tatsächlich passiert, aber beschuldigen Sie sie nicht ihrer Absicht.

Was tatsächlich passiert, ist, dass sie Ihren Code zusammengeführt haben, als wäre es ihr eigener. Dies könnte aus persönlicher Rache geschehen sein, um Sie wie einen Idioten aussehen zu lassen, aber das ist eine Anschuldigung der Absicht, die viel schwieriger zu beweisen ist, und basierend auf dem, was Sie gepostet haben, gibt es nichts, was auf eine böswillige Absicht Ihres Kollegen hindeutet .

Konzentrieren Sie sich darauf, dies zu einem Lehrmoment zu machen, indem Sie seine Unwissenheit über die korrekte Verwendung von Git unterstellen. Git bietet viele Möglichkeiten, um es einem Entwickler zu ermöglichen, den Code eines anderen Entwicklers wiederzuverwenden, während die Urheberschaft erhalten bleibt. Die beiden wichtigsten Werkzeuge hier sind der Merge- und der Cherry-Pick-Befehl.

Weisen Sie sie darauf hin, dass die Erhaltung von Metadaten und der Urheberschaft des Verlaufs im Projekt wichtig ist.

Ich weiß nicht, ob Sie das bemerkt haben, aber wenn Sie ein Quellcode-Kontrollsystem haben und zwei Personen identische Änderungen vornehmen, dann werden Sie viele "Merge-Konflikte" bekommen, die das Mergen zu einer zeitaufwändigen und fehleranfälligen Operation machen.

So kann man beim nächsten Teammeeting, wo allerlei besprochen wird, sagen „... und in Zukunft würde ich es begrüßen, wenn niemand unvollständige Änderungen aus meinem Branch übernimmt und in den Haupt-Branch gemergt. Ich habe eine Stunde verschwendet und stundenlange Arbeit zur Lösung von Merge-Konflikten aus diesem Grund". Gut möglich, dass Ihr Chef dann fragt, wer so einen Quatsch gemacht hat, und jetzt können Sie dem Chef Namen nennen, ohne wie ein Spitzel dastehen zu müssen.

Führen Sie seinen Code zusammen, indem Sie angeben, dass er ihn geschrieben hat. Das Managen von Fusionen selbst ist eine gute Strategie. scheint nicht zu wissen, wie GIT funktioniert, und hat vergessen, sich mit Ihren Änderungen zu synchronisieren. Commits mit dem gesamten Code anderer Personen werden automatisch von Tools wie dem Quellbaum generiert, falls Personen eine schlechte Zusammenführungsstrategie verwenden

Was falsch ist, ist die Angabe von "my code" in der Comunità-Beschreibung.

Wenn ich einen Tag lang von einem Fehler getroffen werde (ein Monat scheint zu viel. Ich habe nie einen Monat an einem Fehler gearbeitet) und ich Änderungen zusammenführe, sage ich ausdrücklich, dass die Zusammenführung meinen Bugfix plus vorherigen Code von anderen enthält, und selbst wenn ich dies tue, tut es das nicht sieht so aus, als hätte ich Code von anderen übertragen.

Wenn Ihr Mitarbeiter an einem Zweig arbeitet, sollte er zuerst den Hauptzweig mit seinem eigenen zusammenführen. Prüfen. Führen Sie dann seinen Zweig wieder zusammen. Dadurch wird der Verlauf Ihrer Änderungen gespeichert.

Wenn er anfängt, Code aus Ihrem Zweig zu kopieren, ohne ihn zusammenzuführen und dann einzureichen, geht es ihm noch schlechter. Er arbeitet an der Versionierung, die möglicherweise neue Fehler einführt.

Ich würde eine Verpflichtungsrichtlinie einführen, die befolgt werden muss, und jeden dazu zwingen, die Richtlinie zu respektieren. Ich würde mir eher Sorgen um seine GIT-Fähigkeiten machen. Es könnte Chaos anrichten

Ja, das ist mir einmal mit einem sehr ungewöhnlichen Kollegen passiert. Eines Tages sagte mir ein QA-Mitarbeiter, mein Code sehe genau so aus wie dieser andere Kollege. Ich habe mich bei GitHub angemeldet und bemerkt, dass der Code meinem auf unheimliche Weise ähnlich ist, aber ich habe es zuerst abgewischt, dass der Code vielleicht einfach derselbe ist, da wir mehrere Websites hosten, die dieselbe Datei teilen, da er dasselbe tut.

Im Laufe der Zeit beobachtete ich, dass die Kollegin sagte, sie arbeite am „Refaktorisieren des Codes“ während der täglichen Standups bis zum letzten Tag des Sprints, dann sagte sie, ihr Code sei am letzten Tag nicht fertig und brauche einen zusätzlichen Tag, und dann mysteriöserweise am nächsten Tag wurden Hunderte von Codezeilen auf einen Pull-Request hochgeladen. Ich habe mir den Code angesehen und festgestellt, dass der Code meinem ähnlich ist, bis hin zu einem Rechtschreibfehler, den ich gemacht habe. Dann wurde mir klar, dass die Person wartete, bis ich meinen Ast hochschob, und sie beobachtete und kopierte Dinge davon.

Ich war genauso wütend wie du. Meistens, weil der Mitarbeiter nicht zu mir kam, um zu fragen, was ich gerne helfen oder anleiten würde. Das war einer der wenigen Gründe, warum ich mich entschied, das Unternehmen zu verlassen, nachdem ich es einem Manager vorgestellt hatte, dem es anscheinend egal war. Mein Rat ist, es einem Manager vorzulegen und einen Rechtschreibfehler einzubauen, von dem Sie beweisen können, dass er nicht zufällig kopiert werden konnte. Auf diese Weise können Sie sagen, dass es auf keinen Fall ein reiner Zufall ist.