Ein Mitarbeiter reichte meinen Code als seinen eigenen ein

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

Ich sehe, dass Sie den Code von meinem Zweig in den Hauptzweig verschoben haben. Bitte bedenken Sie, dass die Revisionshistorie bei dieser Art von Produkten wichtig ist, so dass es vermieden werden sollte, Code per Cut and Paste in den Hauptzweig zu kopieren, wie Sie es getan haben; vielmehr sollte der Code von dem Zweig, auf dem er entwickelt wurde, verschoben werden.

und cc Ihr Manager. Auf diese Weise wird Ihr Vorgesetzter auf das Problem aufmerksam gemacht, ohne Ihren Mitarbeiter direkt des Fehlverhaltens zu beschuldigen, und es als Sorge um die Integrität des Projekts und nicht als persönliche Ehre dargestellt.

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

Es ist nicht illegal wie vor Gericht, aber es ist falsch, und Ihr Vorgesetzter sollte es wissen. Sagen Sie ihm, wenn er es wieder tut, werden Sie ihn erneut melden.

Sie klingen wütend genug, um den Mitarbeiter zu einem Duell herauszufordern, aber viele Entwickler sind eher zurückhaltend und könnten eine subtilere Herangehensweise schätzen, um Gerechtigkeit zu bekommen.

Sie könnten demjenigen, der den Sog akzeptiert hat, eine E-Mail schicken, in der Sie ihm Ihre “Bedenken” mitteilen, dass Ihr noch in der Entwicklung befindlicher Code als Meister erscheint. Sie müssen nicht einmal Anschuldigungen erheben; lassen Sie sie selbst “herausfinden”, was passiert ist. Sagen Sie, Ihr Code sollte gut sein, aber Sie waren noch nicht fertig mit dem Testen und Anpassen und sind verwirrt/beunruhigt darüber, wie er es zum Master geschafft hat, ohne dass Sie eine Pull-Anfrage gestellt haben.

Dadurch wird das meiste Drama beseitigt, aber es bleibt eine gute Möglichkeit für Ihre Mitarbeiter, einen Verweis zu erhalten, sobald sie herausgefunden haben, wie der Code unangemessenerweise auf den Master gelangt ist. Ich kann mir vorstellen, dass einige technisch versierte Leute von Konflikten abgeschreckt werden, so dass sie sich weniger darauf freuen, sich damit zu befassen, aber sie werden mit ziemlicher Sicherheit herausfinden wollen, was passiert ist, wenn sie als “WTF” und nicht als eine scheinbar unverschämte Anschuldigung angesprochen werden.

Wenn die Dinge so sind, wie behauptet, wird die Untersuchung kurz und schlüssig sein. Es klingt so, 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 auf den Boden der Büropolitik”.

Woah Betty, lassen Sie uns das aufschlüsseln:

Ein Mitarbeiter hat den Code komplett gestohlen und behauptet, er habe ihn geschrieben

^ Das ist ziemlich ernst. Wenn er herumgeht und den Leuten sagt: “Das ist die Arbeit, die ich geleistet habe”, dann sagen Sie Ihrem Manager sicher: “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 Zusammenführung vorgenommen hat. Ich weise darauf hin, weil ich nicht möchte, dass Sie den Eindruck haben, dass ich meinen Teil der Arbeit nicht gemacht habe, und gleichzeitig stört es mich, dass Bob versucht, die Lorbeeren für die Arbeit zu ernten, die er nicht gemacht hat.”

Aber

Heute führt Bob etwas Code in unseren Hauptzweig ein.

“Behauptet” Bob wirklich, dass er alles geschrieben hat? Oder hat er einfach einen Zweig mit dem Master-Zweig zusammengeführt, und niemand weiß/interessiert sich dafür, welcher Name neben diesem Merge-Commit steht? In meiner Firma würde niemand nachschauen, wer welchen Commit geschrieben hat, es sei denn, das Management würde irgendeine Katastrophe überprüfen.

Gibt es neben git noch ein anderes Projektmanagement-Tool, das Ihr Manager benutzt, um zu sehen, wie viel Arbeit jeder macht? Wenn ja, wird ein Name auf einem Commit nichts bedeuten. Wenn nicht, dann ist das Management so schlecht, dass meiner Meinung nach sowieso niemand die Git-Geschichte verfolgen würde.

Sie hatten einen Code. Er benutzte diesen Code, um seine Aufgabe zu erfüllen. Dieser Teil ist vollkommen akzeptabel. Es gibt keinen Grund, eine Lösung zu schreiben, wenn eine vorhandene Lösung funktioniert.

Sie wollten die Anerkennung für den Code. Sie erwähnen, dass er in den Git-Commits, die Ihren Code enthalten, Sprachen wie Ich und Ich verwendet hat. Git-Commits sollten weder ein Management-Tool noch ein Werkzeug sein, um die geleistete Arbeit anzuerkennen. Die verwendete Projektmanagementsoftware oder das verwendete System sollte regeln, wer wofür Anerkennung erhält. Wenn Sie beide mit derselben Aufgabe betraut sind, erwartet das Management wahrscheinlich, dass Sie die Ideen und den Code des anderen verwenden. Wenn es sich um eine gemeinsame Aufgabe handelt, sollten Sie beide ehrlich auf dem gleichen Gebiet tätig sein.

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

Sie sollten zuerst mit Ihrem Mitarbeiter sprechen. Im Moment hört es sich so an, als sei dies nur einmal geschehen. Ich habe meinen Verhaltenskodex für Mitarbeiter oft festgelegt und die Mitarbeiter meinen Kodex festlegen lassen. Wenn es Sie betrifft, können Sie ihm gerne sagen, dass die Git-Geschichte wichtig ist und dass Sie möchten, dass Ihr Name an jeden Code angehängt wird, der von Ihnen begangen wurde. Bestehen Sie darauf, dass Sie im Falle eines Fehlers im Code nicht wollen, dass er fälschlicherweise beschuldigt wird.

Wenn er bei seiner Arbeit weiterhin schlecht abschneidet, sprechen Sie mit dem Management über seine Leistung (nicht über die Commits). Sie können erwähnen, dass seine Commits oft Ihren Code benutzen, aber machen Sie das nicht zum Punkt, denn daran ist von sich aus nichts falsch. Sie müssen nur klarstellen, dass sie die Commits nicht dazu benutzen sollten, seine Fähigkeiten oder seine Arbeitsmoral zu bewerten, weil es Ihr Code ist.

**

Wenn Sie auch dies melden, vergewissern Sie sich, dass es sich um eine schriftliche Meldung oder eine E-Mail handelt, denn wenn Sie später darauf Bezug nehmen müssen, sollten Sie es sehr gut dokumentieren lassen, dass dies geschehen ist und eine Beschwerde eingereicht wurde.

Ist es Ihr Ziel, dafür zu sorgen, dass der von Ihnen geschriebene Code gewürdigt wird?

Die Vorstellung, dass der Code “Ihnen” gehört, ist im Allgemeinen keine gute Art, über Ihre Arbeit für das Unternehmen nachzudenken. Der Code, den Sie schreiben, gehört nicht Ihnen, sondern dem Unternehmen. Es sollte keinen Unterschied machen, ob der Code von Ihrer Niederlassung oder von Bobs Niederlassung aus begangen 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 nicht Sie, sondern Bob Ihren Beitrag leistet, aber Ihre Frage lässt es eher so klingen, als ob Sie sich beraubt fühlten.

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 solange Ihr Vorgesetzter nicht die Commit-Protokolle überprüft, um sicherzustellen, dass Sie und Bob jeweils genug Arbeit leisten, würde ich es nicht für nötig halten, etwas gegen diese Situation zu unternehmen.

Es klingt, als ob das Schlimmste, was Bob hier getan hat, war, dass er sich nicht an die besten Praktiken bei der Verwendung der Quellcodeverwaltung gehalten hat. Das Einfügen Ihrer Änderungen hätte eine bessere Revisionsgeschichte ermöglicht als das Kopieren/Einfügen Ihrer Änderungen. Es ist vernünftig, ihm dies zu erklären und die Gründe dafür darzulegen. Aber aus den Informationen, die wir in der Frage haben, geht hervor, dass dies kein Thema ist, bei dem Sie formell etwas aufschreiben und sicherstellen müssen, dass Sie Ihren Vorgesetzten kopieren. Erwähnen Sie es ihm gegenüber einfach beiläufig.

Ich gebe nicht vor, Git gut genug zu verstehen, um genau zu wissen, warum dies auftritt, aber Visual Studio erstellt manchmal Commits im lokalen Repository, wenn Sie die IDE verwenden, um Merge-Konflikte aufzulösen. Dies erscheint in der Historie so, dass alle Änderungen in das entfernte Repository übernommen, auf das eigene Repository angewendet, festgeschrieben und dann auf das entfernte Repository angewendet wurden.

Die rationale Erklärung hier ist, dass Bob sich durch den Zusammenführungsprozess geklickt hat, ohne ihn wirklich zu verstehen, und eine Historie der Versionsverwaltung erzeugt hat, die irreführend ist. Wenn Sie von dieser Annahme ausgehen, fragen Sie ihn danach mit der Absicht, ihn darüber aufzuklären, wie man richtig zusammenführt, wobei Sie im Zweifelsfall davon ausgehen können, dass es sich um einen Fehler handelt.

Zuerst ermitteln Sie, was das Problem ist. Es ist nicht ganz klar aus Ihrer Frage, wie sie gestellt wurde.

Wenn das Problem darin besteht, dass Ihr Name aus der Git-Geschichte gestrichen wurde (vorausgesetzt, Sie benutzen Git) und durch seinen ersetzt wurde, ist das ein Haushaltsproblem und wahrscheinlich kein Zeichen für böswilliges Verhalten Ihres Mitarbeiters. Wenn ein Mitarbeiter einen Monat lang an einem Fehler klebt, der irgendwie darauf hindeutet, dass er bei der Verwendung seiner Werkzeuge - einschließlich der Versionskontrolle - ein wenig eingerostet ist.

Ihr Name sollte auf dem gesamten von Ihnen geschriebenen Code stehen. Das ist keine Frage des Stolzes oder der Anerkennung, die man Ihnen schuldet - Sie brauchen diese Geschichte intakt, 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 draufsteht, dann ist Ihr Mitarbeiter derjenige, der Fragen zu Ihrem Code stellt und die Schuld für Ihre Fehler auf sich nimmt!

Verwenden Sie Ihre IDE oder ein Quellcode-Kontrollwerkzeug, um den Code zu kommentieren 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 in diesem Commit, nicht in jeder Zeile des Codes in diesem Commit. Das fällt auseinander, wenn er die Zweige nicht korrekt zusammengeführt hat, um dies geschehen zu lassen, und das ist etwas, was er korrekt tun muss.

Wenn Sie in einer Organisation arbeiten, in der “wieviel Code ich geschrieben habe” eine Metrik ist, die sie verfolgen und sie benutzen sie zu Werbezwecken, dann sollten Sie das dem Management melden. Sagen Sie nicht “er hat mich bestohlen” (Sie wissen nicht, dass er es getan hat), sondern sagen Sie “ich bin besorgt, dass, wenn Sie sich unsere Quellenkontroll-Historie ansehen, um unseren Verdienst für Gehaltserhöhungen und Beförderungen zu bewerten, seine Zusammenführung es so aussehen lässt, als hätte ich nichts beigetragen”.

Dies hängt sehr stark von der Dynamik Ihres Unternehmens ab. In meinem Fall (was meiner Meinung nach die Norm für die meisten professionellen Software-Firmen ist) wäre ich halbvergnügt, wenn mein Name aus dem Code, den ich geschrieben habe, verschwinden würde… Jetzt habe ich keine Leute mehr, die mir Fragen zu dummen Entscheidungen stellen, die ich Monate zuvor in meinem Code getroffen habe! :)

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

Mein Mitarbeiter und ich haben über zwei Jahre an einem Projekt gearbeitet und Commits hin und her getauscht, und ja , manchmal haben wir den Code des anderen wiederverwendet oder optimiert.

Ich weiß nicht, in was für einer Kultur du arbeitest, aber wenn es irgendwie die Arbeit in Codezeilen definiert, anstatt Endprodukt und Gesamtbeitrag, scheint es eher toxisch und wettbewerbsfähig zu sein. Mein Rat wäre, dass Sie nicht die Befehlskette hochlaufen und nach irgendeiner Form der Vergeltung Ausschau halten. Wenn Ihnen das so wichtig ist, dann sprechen Sie mit Ihrem Vorgesetzten darüber, wie Sie die Anerkennung für die Dinge bestimmen und dann in welcher Form auch immer dokumentieren.

Der Punkt, den ich am meisten ansprechen wollte, war Ihre Beziehung zu Ihrem Kollegen. Meiner ehrlichen Meinung nach, wenn mein Kollege eines Tages zu mir käme und ausrufen würde: “Benutzen Sie nicht meinen Code! Es ist mein Code!”, und mich dann wegen etwas, das ich nicht absichtlich oder böswillig tat, in Schwierigkeiten mit dem Management brachte, würde ich ihn für einen selbstgefälligen Trottel halten. Ich würde das im Gedächtnis behalten, denn aus der Frage geht hervor, dass unklar ist, ob sie wirklich Ihren Code gestohlen haben oder ob sie vielleicht nur auf seltsame Weise Änderungen vorgenommen haben.

Die Anschuldigung (was eine große Anschuldigung ist) - wenn sie Ihre berufliche Beziehung nicht völlig ruiniert, würde sie mit Sicherheit ihre persönliche Meinung über Sie herabsetzen. Keine große Sache, wenn Sie Recht haben. Ich bin ein Fan des Denkens vom Typ “man schaufelt sich sein eigenes Grab” - aber wenn Sie falsch liegen, könnte der Schaden für Ihre Arbeitsbeziehung ganz erheblich sein.

Wenn Sie absolut sicher sind, dass er stiehlt und die Lorbeeren für Dinge entgegennimmt, die er nicht getan hat, zögern Sie nicht, Ihren Vorgesetzten zu kontaktieren und die geeigneten Maßnahmen zu ergreifen, um sicherzustellen, dass er für diese Art von Verhalten gerügt wird - aber wenn Sie sich nicht wirklich sicher sind, sollten Sie es vielleicht noch einmal überdenken. Ein Plagiat ist keine leichtfertige Behauptung, vor allem, wenn es Ihr tägliches Leben ziemlich lange beeinträchtigen kann.

Diskutieren Sie mit Ihrem Mitarbeiter und Manager, was tatsächlich passiert, aber beschuldigen Sie sie nicht ihrer Absicht.

Was tatsächlich passiert, ist, dass sie Ihren Code zusammengeführt haben, als ob es ihr eigener wäre. Das mag aus persönlicher Vendetta geschehen sein, um Sie wie ein Dummkopf aussehen zu lassen, aber das ist ein Vorwurf der Absicht, was viel schwieriger zu beweisen ist, und auf der Grundlage dessen, was Sie gepostet haben, gibt es nichts, was auf eine böswillige Absicht Ihres Mitarbeiters hindeutet.

Konzentrieren Sie sich darauf, dies zu einem lehrreichen Moment zu machen, indem Sie seine Unwissenheit über die Art und Weise, wie man Git korrekt benutzt, voraussetzen. Git bietet viele Möglichkeiten, einem Entwickler zu erlauben, den Code eines anderen Entwicklers wiederzuverwenden, während die Urheberschaft erhalten bleibt. Die beiden Hauptwerkzeuge hier sind der Merge- und der Cherry-Pick-Befehl.

Sagen Sie ihnen, dass sie sich bewusst sein sollen, dass der Erhalt der Metadaten und der Autorenschaft der Geschichte im Projekt wichtig ist.

Metainformationen wie die Urheberschaft existieren in einem Versionskontrollsystem wie Git nicht so sehr, um die Eigentümerschaft zu verfolgen, sondern mehr, um das Verstehen zu unterstützen, wie etwas so geworden ist, wie es ist.

Während einfache Abläufe Zusammenfassungen von Commits mit individueller Urheberschaft haben, gibt es viele Fälle, in denen dies nicht funktioniert oder nicht die ganze Geschichte in den festen Zweckfeldern eines Commits erfasst.

Etwas wie Refactoring oder sogar die Anwendung neu etablierter Whitespace-Regeln auf einen Code-Block beinhaltet das, was git als neue Urheberschaft betrachtet, da git nur wörtliche Details versteht, nicht die Bedeutung. Und das auch nur in Fällen, in denen Code weiterhin in seiner ursprünglichen Rolle und an seinem exakten Speicherort verwendet wird.

In vielen anderen Fällen, wie z.B. wenn die Lösung eines neuen Problems auf Code basiert, der von der Lösung eines älteren Problems innerhalb der Codebasis eines Unternehmens kopiert wurde, sucht die ganze Welt nach einer VCS-ähnlichen echten, neuen Autorschaft.

Obwohl ich das bei weitem nicht perfekt mache, versuche ich, wenn ich einen Commit erstelle, der zum großen Teil auf bereits vorhandener Arbeit basiert (insbesondere auf der Arbeit von jemand anderem, die entweder verlagert oder wesentlich überarbeitet wurde), seinen Ursprung in der Commit-Nachricht zu erwähnen. Das ist ein wenig zu loben, aber genauso viel oder mehr, um eine Aufzeichnung der Beziehung zu anderem Code zu erstellen. Wenn also zum Beispiel ein Fehler in der neuen Verwendung gefunden wird, lohnt es sich zu prüfen, ob er auch an der Stelle existiert, von der der Code kopiert wurde.

Angesichts dessen könnte eine gute Vorgehensweise sein, zu versuchen, einen Codeüberprüfungsprozess zu verwenden, damit die endgültige Zusammenführung des umstrittenen Codes unter einer beschreibenderen Nachricht erfolgt, die seinen tatsächlichen Ursprung beschreibt. Und dieses Argument nicht so sehr, um das “Eigentum” an dem Beitrag zu erhalten, sondern um das Wissen darüber zu bewahren, woher der Code stammt, in welcher Beziehung er zu anderen Codes stehen könnte und um eine vollständigere Liste von wem man im Falle von Schwierigkeiten um Input bittet.

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” erhalten, die das Mergen zu einer zeitaufwendigen und fehleranfälligen Operation machen.

Auf der nächsten Teambesprechung, wo alle möglichen Dinge besprochen werden, können Sie sagen “… und in Zukunft würde ich es begrüßen, wenn niemand unvollständige Änderungen aus meinem Zweig in den Hauptzweig übernehmen und in den Hauptzweig übernehmen würde. Ich habe dadurch Stunden und Stunden an Arbeit für die Lösung von Merge-Konflikten verschwendet”. Es ist gut möglich, dass Ihr Chef dann fragt, wer diesen Unsinn gemacht hat, und jetzt können Sie dem Chef Namen nennen, ohne wie ein Spitzel auszusehen.

Fügen Sie seinen Code zusammen, indem Sie angeben, dass er ihn geschrieben hat. Es scheint, dass er nicht weiß, wie GIT funktioniert und vergessen hat, sich mit Ihren Änderungen synchron zu halten. Commits mit allen’ wird der Code anderer Leute automatisch von Werkzeugen wie dem Source-Tree generiert, falls Leute eine schlechte Merging-Strategie verwenden

Was falsch ist, ist die Angabe von “mein Code” in der comunità-Beschreibung.

Wenn ich einen Tag lang einen Fehler finde ( ein Monat scheint zu viel. Ich bin nie einen Monat lang an einem Fehler geblieben) und ich Änderungen zusammenführe, sage ich ausdrücklich, dass das Zusammenführen meinen Bugfix plus vorherigen Code von anderen enthält, und selbst wenn ich das tue, sieht es nicht so aus, als hätte ich Code von anderen committed.

Wenn Ihr Mitarbeiter an einem Zweig arbeitet, sollte er zuerst den Hauptzweig in seinen eigenen Zweig zusammenführen. Testen. Fügen Sie dann seinen Zweig wieder ein.

Wenn er anfängt, Code aus Ihrem Zweig zu kopieren, ohne ihn zusammenzuführen und dann abzuschicken, geht es ihm noch schlechter. Er arbeitet um die Versionierung herum, wodurch möglicherweise neue Fehler eingeführt werden.

Ich würde eine Commit-Politik einführen, die zu befolgen ist, und jeden zwingen, diese Politik zu respektieren. Ich würde mir eher mehr Sorgen über seine GIT-Fähigkeiten machen. Es könnte Chaos verursachen.

Ja, das ist mir einmal mit einer sehr ungewöhnlichen Kollegin passiert. Eines Tages sagte mir eine QA-Person, dass mein Code genau so aussieht wie der dieses anderen Mitarbeiters. Ich loggte mich in GitHub ein und bemerkte, dass der Code meinem unheimlich ähnlich ist, aber ich bürstete ihn zunächst ab, dass der Code vielleicht einfach derselbe ist, da wir mehrere Sites hosten, die dieselbe Datei gemeinsam nutzen, da er dasselbe tut.

Im Laufe der Zeit beobachtete ich, wie die Mitarbeiterin sagte, sie arbeite bis zum letzten Tag des Sprints während der täglichen Stand-Ups an der “Refactoring des Codes”, dann sagt sie, ihr Code sei am letzten Tag noch nicht fertig und brauche einen zusätzlichen Tag, und dann wurden am nächsten Tag auf mysteriöse Weise Hunderte von Codezeilen auf eine Pull-Anfrage hinaufgeschoben. Ich sah mir den Code an und stellte fest, dass er meinem ähnlich ist, bis hin zu einem Schreibfehler, den ich gemacht habe. Dann merkte ich, dass die Person wartete, bis ich meinen Zweig nach oben schob, und dass sie beobachten und Dinge daraus kopieren würde.

Ich war genauso wütend wie Sie. Vor allem, weil die Mitarbeiterin nicht zu mir kam, um mich zu fragen, was ich gerne tun würde, um zu helfen oder zu leiten. Das war einer der wenigen Gründe, warum ich beschloss, das Unternehmen zu verlassen, nachdem ich es einer Managerin erzählt hatte, die sich nicht darum zu kümmern schien. Mein Ratschlag ist, es einem Manager vorzutragen und einen Rechtschreibfehler einzufügen, von dem Sie beweisen können, dass er nicht zufällig dupliziert werden konnte. Auf diese Weise können Sie sagen, dass es auf keinen Fall ein reiner Zufall sein kann.