Coworker heeft mijn code ingediend als zijn eigen

Je moet hem een e-mail sturen met iets in de trant van:

Ik zie dat je de code van mijn tak naar de mastertak hebt geduwd. Houd er rekening mee dat de revisiegeschiedenis belangrijk is bij dit soort producten, dus als je de code hebt geknipt en geplakt in de hoofdtak, zoals je hebt gedaan, moet je voorkomen dat de code wordt geduwd vanuit de tak waarop hij is ontwikkeld.

en cc je manager. Dit maakt je manager bewust van het probleem zonder je medewerker direct te beschuldigen van wangedrag, en kadert het als een zorg voor de integriteit van het project in plaats van persoonlijk krediet.

Ik zou het zeker melden aan je manager met bewijs dat je het eerst hebt geschreven.

Het is niet illegaal zoals in een rechtbank, maar het is verkeerd en je manager zou het moeten weten. Zeg hem dat als hij het opnieuw doet, je hem opnieuw zult rapporteren.

Je klinkt boos genoeg om de medewerker uit te dagen tot een duel, maar een heleboel devs zijn meer ingetogen en zouden een subtielere benadering van het krijgen van gerechtigheid kunnen waarderen.

Je zou kunnen e-mailen wie de pull heeft geaccepteerd met je “zorgen” over je nog steeds in ontwikkeling zijnde code die op de meester verschijnt. Je hoeft niet eens beschuldigingen te uiten; laat ze zelf maar “uitzoeken” wat er gebeurd is. Zeg dat je code goed zou moeten zijn, maar je was niet klaar met testen en tweaken, en je bent verbaasd/bezorgd over hoe het in de master is gekomen zonder dat je een pull verzoek hebt ingediend.

Dit verwijdert het grootste deel van het drama, maar behoudt een goede mogelijkheid voor je collega om berispt te worden, zodra ze erachter komen hoe de code op ongepaste wijze op de master is terechtgekomen. Ik zie dat sommige techneuten door een conflict worden afgezet, waardoor ze minder enthousiast zijn om er in te graven, maar ze zullen bijna zeker willen uitzoeken wat er gebeurd is als ze benaderd worden als een “WTF” in plaats van een schijnbaar schandelijke beschuldiging.

Als de dingen zijn zoals beweerd, dan zal het onderzoek kort en bondig zijn. Het klinkt alsof je toch al een betere werker bent, dus de tijd zal het kaf van het koren zeven; wees grootmoedig en “punch down” niet in de kantoorpolitiek.

Woah Betty, laten we dit uitsplitsen:

Coworker heeft de code volledig gestolen en beweert dat hij het allemaal heeft geschreven

^ Dat is behoorlijk serieus. Als hij de mensen gaat vertellen “dit is het werk dat ik heb gedaan”, zeg dan zeker tegen je manager “Hé, ik wil je alleen maar wijzen naar deze github pagina om te laten zien dat ik de auteur ben van al dit werk, terwijl Bob alleen deze samenvoeging heeft gedaan. Ik wijs het aan omdat ik niet wil dat je de indruk krijgt dat ik mijn deel van het werk niet gedaan heb, en tegelijkertijd stoort het me dat Bob de eer probeert te krijgen voor het werk dat hij niet gedaan heeft.”

Maar

Vandaag voegt Bob wat code samen in onze mastertak.

Is Bob echt aan het “beweren” dat hij het allemaal geschreven heeft? Of heeft hij gewoon een tak samengevoegd in de master, en niemand weet/bezorgt welke naam er naast die samenvoeg commit staat? In mijn bedrijf, tenzij het management een of andere ramp aan het bekijken was, zou niemand kijken naar wie welke commit gemaakt heeft.

Is er naast git nog een andere project management tool die je manager gebruikt om te zien hoeveel werk iedereen doet? Als dat zo is, betekent een naam op een commit niets. Zo niet, dan is het beheer slecht genoeg dat ik denk dat niemand in ieder geval de geschiedenis van git in de gaten zou houden.

Je had een code. Hij gebruikte die code om zijn taak te volbrengen. Dat deel is volkomen acceptabel. Geen reden om een oplossing te schrijven als een bestaande oplossing werkt.

Je wilde crediteren voor de code. Je zegt dat hij taal zoals ik en ik gebruikte in de git commits die jouw code bevatten. Git commits zou geen management tool moeten zijn, of een tool om krediet toe te kennen voor gedaan werk. De projectmanagementsoftware of het systeem dat gebruikt wordt zou moeten afhandelen wie waarvoor krediet krijgt. Als u beiden aan dezelfde taak was toegewezen, verwacht het management waarschijnlijk dat u elkaars ideeën en code gebruikt. Je zou beiden in dezelfde tak moeten zitten als het een gezamenlijke taak is.

Het echte probleem is dat je je zorgen maakt over zijn vaardigheden en/of werkethiek. Dat moet los van dit specifieke incident worden aangepakt.

Je moet eerst met je mede-werker spreken. Op dit moment klinkt het alsof dit maar één keer is gebeurd. Ik heb vaak mijn collega’s code vastgelegd, en laat collega’s mijn code vastleggen. Als het jou aangaat, voel je vrij om hem te vertellen dat de geschiedenis van Git belangrijk is en dat je je naam aan een van je gecommitteerde code wilt koppelen. Sta erop dat als er een bug in de code zit, je niet wilt dat hij ten onrechte de schuld krijgt.

Als hij slecht blijft presteren op zijn werk, praat dan met het management over zijn prestaties (niet over de commits). Je kunt vermelden dat zijn commits vaak jouw code gebruiken, maar maak daar niet het punt van, want daar is eigenlijk niets intrinsiek mis mee. Je hoeft alleen maar te verduidelijken dat ze de commits niet moeten gebruiken om zijn vaardigheid of werkethiek te evalueren, omdat het jouw code is.

Meld dit aan het management. Lees ook het werknemershandboek van uw bedrijf, zij hebben waarschijnlijk een beleid voor onethisch gedrag en wat hun proces voor het melden ervan is.

Wanneer u dit ook meldt, ** zorg er dan voor dat het schriftelijk / een e-mail** is, alsof u er later naar moet verwijzen, dan moet u heel goed gedocumenteerd hebben dat dit is gebeurd en dat er een klacht is ingediend.

Is je doel om ervoor te zorgen dat je krediet krijgt voor de code die je hebt geschreven?

Het idee dat de code “van jou” is, is over het algemeen geen goede manier om na te denken over het werk dat je voor het bedrijf doet. De code die je schrijft is niet van jou, maar van het bedrijf. Het maakt niet uit of de code afkomstig is van uw bedrijf of van Bob’s bedrijf. U en Bob hebben een gemeenschappelijk doel om alle taken die nodig zijn voor het product uit te voeren.

Het is één ding als je manager gelooft dat je niet aan je trekken komt, maar Bob wel, maar je vraag laat het meer klinken alsof je beroofd bent.

Sommige van de opmerkingen gaan hier op in; maar de antwoorden (vooral het geaccepteerde antwoord) lijken in een heel andere richting te gaan. De juiste handelswijze hangt af van je werkelijke doelen; maar tenzij je manager de commit logs bekijkt om er zeker van te zijn dat jij en Bob elk genoeg werk doen, dan zou ik niet de behoefte voelen om iets aan deze situatie te doen.

Het klinkt alsof het ergste wat Bob hier deed was om geen best practices te volgen met het gebruik van broncontrole. Het samenvoegen van je wijzigingen zou een betere revisiegeschiedenis mogelijk hebben gemaakt dan het kopiëren/plakken van je wijzigingen. Het is redelijk om dit aan hem uit te leggen, en de redenen daarvoor uit te leggen. Maar op basis van de informatie die we in de vraag hebben; dit is geen kwestie waarbij je formeel iets moet opschrijven en ervoor moet zorgen dat je je manager kopieert. Zeg het hem gewoon terloops.

Dit klinkt als een samensmelting die verpest is; ik doe niet alsof ik git goed genoeg begrijp om precies te weten waarom dit gebeurt, maar Visual Studio maakt soms wel commits op de lokale repository als je de IDE gebruikt om samenvoegingsconflicten op te lossen. Dit verschijnt in de geschiedenis als het nemen van alle wijzigingen in de remote repository, het toepassen van deze wijzigingen op de eigen repository, het committen ervan, en dan het toepassen van die commit op de remote repository.

De rationele verklaring hier is dat Bob door het samenvoegproces heeft geklikt zonder het echt te begrijpen en dat het een misleidende bronbeheersingsgeschiedenis heeft gegenereerd. Werkend op die veronderstelling, vraag het hem met de bedoeling om hem te leren hoe hij goed kan samenvoegen, waardoor het voordeel van de twijfel over de kwestie een vergissing is.

Eerst, bepaal wat het probleem is. Het is niet helemaal duidelijk uit je vraag zoals die gesteld is.

Als het probleem is dat je naam uit de Git-geschiedenis is geschrapt (in de veronderstelling dat je Git gebruikt) en vervangen is door de zijne, dan is dat een huishoudelijk probleem en waarschijnlijk geen teken van kwaadwillig gedrag van je collega. Als een collega een maand lang vastzit aan een bug die soort van suggereert dat ze misschien een beetje verroest zijn bij het gebruik van hun gereedschap - inclusief versiebeheer.

Je naam zou op alle code die je hebt geschreven moeten staan. Dit is geen kwestie van trots of het ontvangen van krediet dat je verschuldigd bent - je moet die geschiedenis intact houden zodat mensen weten wie welke code heeft geschreven en met wie ze moeten praten als ze in de toekomst met bugs of vreemde ontwerpbeslissingen te maken krijgen. Als je naam er niet meer op staat, dan is je collega degene die vragen krijgt over je code, en de schuld op zich neemt voor je bugs!

Gebruik je IDE of een broncontrole tool om de code te annoteren en te zien of zijn naam daadwerkelijk op elke regel staat. In het algemeen maakt het niet uit wie de code samenvoegt - hun naam gaat alleen op die commit, niet op elke regel van de code in die commit. Dat valt uit elkaar als hij de takken niet correct heeft samengevoegd om dit te laten gebeuren, en dat is iets wat hij correct moet doen.

Als je werkt in een organisatie waar “hoeveel code ik heb geschreven” een metriek is die ze bijhouden en ze gebruiken het voor promotiedoeleinden, dan moet je dit naar het management brengen. Zeg niet “hij heeft van mij gestolen” (je weet niet dat hij dat deed), zeg “Ik ben bezorgd dat als je naar onze broncontrole geschiedenis kijkt om onze verdienste voor verhogingen en promoties te beoordelen, zijn fusie het laat lijken alsof ik niets heb bijgedragen”.

Dit hangt veel af van de dynamiek van je bedrijf. In mijn geval (wat volgens mij de norm is voor de meeste professionele softwarebedrijven) zou ik halfverlicht zijn om mijn naam te laten verdwijnen uit de code die ik heb geschreven… Nu heb ik geen mensen die me vragen stellen over domme beslissingen die ik in mijn code maanden eerder heb genomen! :)

Eerlijk gezegd, gezien de verstrekte details, lijkt iedereen die zegt _ rapporteer het! _ me gewoon een grote overreactie.

Mijn collega en ik hebben meer dan 2 jaar aan een project gewerkt waarbij we elkaar heen en weer hebben geruild, en ja , soms zouden we elkaars code hergebruiken of optimaliseren.

Ik weet niet in wat voor cultuur je werkt, maar als het op een of andere manier het werk definieert in lijnen van code in plaats van het eindproduct en de totale bijdrage lijkt het nogal giftig en competitief. Mijn advies zou zijn dat je don’t de hiërarchie oploopt op zoek naar een of andere vorm van vergelding. Als het zo belangrijk voor u is, praat dan met uw manager over hoe u het krediet voor dingen kunt bepalen en documenteer dan op welke manier dan ook.

Het punt dat ik het meest aan de orde wilde stellen was uw relatie met uw collega. Naar mijn eerlijke mening als mijn collega op een dag naar me toe kwam en uitriep: “Gebruik mijn code niet! Het is _mijn-code!”, en bracht me dan in de problemen met het management over iets wat ik niet opzettelijk of kwaadwillig deed, dan zou ik denken dat hij een zelfbelangrijke klootzak was. Ik zou dit in gedachten houden, want van de vraag of ze je code echt gestolen hebben of niet, of dat ze misschien gewoon op een vreemde manier in veranderingen aan het samenvoegen waren.

De beschuldiging (die een grote beschuldiging is) - als het je professionele relatie niet volledig verpest, zou het zeker hun persoonlijke mening over je verlagen. Geen probleem als je gelijk hebt. Ik ben een fan van “je graaft je eigen graf” type denken - maar als je verkeerd bent, kan de schade aan je werkrelatie behoorlijk groot zijn. Kantoorpolitiek is een lastig iets!

Nu, als je absoluut positief bent dat hij steelt en de eer opstrijkt voor dingen die hij niet heeft gedaan, voel je vrij om contact op te nemen met je manager en de juiste maatregelen te nemen om ervoor te zorgen dat hij wordt berispt voor dat soort gedrag - echter, als je niet echt zeker bent, misschien heroverweeg je het nog eens. Plagiaat is niet iets om lichtvaardig te beweren, vooral niet als het je dagelijkse leven voor een lange tijd kan beïnvloeden.

Voer een discussie met je collega en manager over wat er feitelijk gebeurt, maar beschuldig hen niet van hun bedoeling.

Wat er feitelijk gebeurt is dat ze je code samenvoegen alsof het hun eigen code is. Dit kan gedaan zijn uit persoonlijke vendetta om je als een dwaas te laten lijken, maar dat is een beschuldiging van opzet, wat veel moeilijker te bewijzen is, en op basis van wat je hebt gepost is er niets dat wijst op enige kwaadwillige opzet van je collega.

Focus op het maken van dit een leermoment, door aan te nemen dat zijn onwetendheid over de manieren waarop git correct gebruikt wordt. Git biedt vele manieren om een ontwikkelaar toe te staan de code van een andere ontwikkelaar te hergebruiken met behoud van het auteurschap. De twee primaire tools hier zijn het merge en cherry-pick commando.

Vertel hen dat ze zich ervan bewust moeten zijn dat het bewaren van metadata en geschiedenis auteurschap belangrijk is in het project.

Meta-informatie zoals auteurschap bestaat in een versiebeheersysteem zoals git niet zozeer om eigenaarschap op te sporen maar meer om het begrijpen van hoe iets moet zijn zoals het is.

Hoewel eenvoudige stromen zijn samengevoegd van commits met individueel auteurschap, zijn er veel gevallen waarin dit niet werkt, of niet het volledige verhaal in de vastomlijnde velden van een committent vastlegt.

Iets als refactoring of zelfs het toepassen van nieuwe witruimte regels op een blok code heeft te maken met wat git als nieuw auteurschap beschouwt, omdat git alleen letterlijke details begrijpt, niet de betekenis. En dat is alleen in gevallen waar code nog steeds gebruikt wordt in zijn oorspronkelijke rol en exacte bestandslocatie.

Veel andere gevallen, zoals het baseren van de oplossing voor een nieuw probleem op code die gekopieerd is van de oplossing van een ouder probleem binnen de codebasis van een bedrijf, zoekt de hele wereld naar een VCS als echt, nieuw auteursschap.

Hoewel dit verre van perfect is, probeer ik, wanneer ik een commit creëer die voor een groot deel gebaseerd is op bestaand werk (vooral als iemand anders is verhuisd of substantieel is herwerkt), de oorsprong ervan te vermelden in het commit bericht. Dat is een beetje te mooi om te vermelden, maar net zo goed om een -record te maken van de relatie met andere code. Dus als er bijvoorbeeld een bug wordt gevonden in het nieuwe gebruik, is het de moeite waard om te controleren of deze ook bestaat in de plaats waar de code is gekopieerd.

Gezien dit, zou een goede manier van handelen kunnen zijn om te proberen een code review proces te gebruiken om de uiteindelijke samenvoeging van de betwiste code te laten doen onder een meer beschrijvend bericht, dat de werkelijke oorsprong ervan beschrijft. En om dit argument niet zozeer te gebruiken om “eigendom” van de bijdrage te behouden, maar om kennis van waar de code vandaan komt, wat zijn relatie tot andere code kan zijn en om een meer volledige lijst te hebben van *die in het geval van problemen *in te voeren.

Ik weet niet of je dit hebt gemerkt, maar als je een broncode controle systeem hebt, en twee mensen maken identieke veranderingen, dan krijg je veel “merge conflicten” die het samenvoegen in een tijdrovende en foutgevoelige operatie veranderen.

Dus op de volgende teamvergadering, waar allerlei dingen worden besproken, kun je zeggen “… en in de toekomst, zou ik het op prijs stellen als niemand onvolledige veranderingen van mijn tak nam en ze samenvoegde in de hoofdtak. Ik heb hierdoor uurtjes en uren verspild aan het oplossen van samenvoegingsconflicten”. Het is heel goed mogelijk dat je baas dan vraagt wie dat soort onzin heeft gedaan, en nu kun je namen noemen aan de baas zonder er als een verklikker uit te zien.

Voeg zijn code samen door te specificeren dat hij hem geschreven heeft. Het beheren van jezelf samenvoegt Is een viale strategie. lijkt hij niet weten hoe GIT werkt en vergat te houden in sync met uw wijzigingen. Commits with all’ de code van andere mensen worden automatisch gegenereerd door tools zoals de source tree in het geval dat mensen een slechte samenvoegstrategie gebruiken

Wat verkeerd is, is het specificeren van “mijn code” in comunità description.

Als ik een dag lang in een bug terecht kom ( een maand lijkt me te veel. Nooit een maand op een bug blijven zitten) en ik voeg veranderingen samen dan zeg ik specifiek dat de samenvoeging mijn bugfix plus vorige code van andere bevat, en zelfs als ik dat doe ziet het er niet naar uit dat ik code van anderen heb gecommitteerd.

Als je medewerker aan een tak werkt moet hij eerst de hoofdtak samenvoegen met de zijne. Test. Voeg dan zijn tak terug samen. Door dit te doen blijft de geschiedenis van je wijzigingen bewaard.

Als hij begint met het kopiëren van code van je tak zonder samen te voegen en dan te verzenden, doet hij het nog slechter. Hij werkt rond versiebeheer dat mogelijk nieuwe bugs introduceert.

Ik zou een committ beleid introduceren om te volgen en iedereen te dwingen het beleid te respecteren. Ik zou me liever meer zorgen maken over zijn GIT-vaardigheid. Het zou havok kunnen veroorzaken

Ja, ik heb dit een keer met een zeer ongewone collega laten gebeuren. Op een dag vertelde een QA persoon me dat mijn code er precies hetzelfde uitziet als die andere collega. Ik logde in bij GitHub en merkte dat de code griezelig veel lijkt op de mijne, maar ik heb het in eerste instantie afgebroken dat misschien omdat we meerdere sites hosten die hetzelfde bestand delen, de code eenvoudigweg hetzelfde is omdat het hetzelfde doet.

Na verloop van tijd merkte ik dat de collega zei dat ze bezig was met het “refactoren van de code” tijdens de dagelijkse standen tot de laatste dag van de sprint, dan zegt ze dat haar code niet klaar is op de laatste dag en een extra dag nodig heeft, en de volgende dag werden er op mysterieuze wijze honderden regels code omhoog geduwd op een pull-verzoek. Ik keek naar de code en merkte dat de code vergelijkbaar is met de mijne, tot aan een spelfout die ik maakte. Toen realiseerde ik me dat de persoon wachtte tot ik mijn tak omhoog duwde en ze dingen zou observeren en kopiëren.

Ik was net zo woedend als jij. Vooral omdat de medewerker niet naar me toe kwam om te vragen welke ik graag zou helpen of sturen. Het was een van de weinige redenen dat ik besloot het bedrijf te verlaten nadat ik het aan een manager had voorgelegd die er niets om leek te geven. Mijn advies is om het aan een manager voor te leggen, een spelfout te maken waarvan je kunt bewijzen dat die niet toevallig kan worden gedupliceerd. Op die manier kun je zeggen dat het geen toeval is.