Współpracownik zgłosił mój kod jako swój własny

Powinieneś wysłać do niego maila mówiącego coś w stylu:

Widzę, że popchnąłeś kod z mojego oddziału do oddziału głównego. Proszę pamiętać, że historia zmian jest ważna w tego typu produktach, więc należy unikać wycinania kodu i wklejania go do głównej gałęzi, tak jak to zrobiłeś, a raczej wypychania kodu z gałęzi, na której został stworzony.

i cc Twój menedżer. To uświadomi Twojemu menadżerowi problem, bez bezpośredniego oskarżania współpracownika o niewłaściwe postępowanie, i potraktuje go jako troskę o integralność projektu, a nie osobisty kredyt.

Zdecydowanie zgłosiłbym to twojemu menadżerowi z dowodem, że napisałeś to pierwszy.

Nie jest to nielegalne jak w sądzie, ale jest złe i twój menadżer powinien wiedzieć. Powiedz mu, że jeśli zrobi to ponownie, zgłosisz to ponownie.

Brzmisz na tyle wściekle, by rzucić wyzwanie współpracownikowi na pojedynek, ale wielu devów jest bardziej stonowanych i może docenić subtelniejsze podejście do wymierzania sprawiedliwości.

Mógłbyś wysłać maila do każdego, kto zaakceptowałby twoje “obawy” o twój wciąż rozwijający się kod pojawiający się na mistrzu. Nie musisz nawet stawiać żadnych zarzutów; pozwól im “dowiedzieć się”, co się stało na własną rękę. Powiedz, że Twój kod powinien być dobry, ale nie zrobiłeś jeszcze testów i poprawek, i zastanawiasz się/obawiasz się, w jaki sposób stał się on mistrzem bez Twojej prośby o ściągnięcie.

Usuwa to większość dramatów, ale zachowuje dobrą możliwość nagany dla Twoich współpracowników, gdy tylko zorientują się, w jaki sposób kod niewłaściwie trafił do mistrza. Widzę, że niektórzy ludzie o poglądach technicznych są w konflikcie, co sprawia, że są mniej podekscytowani kopaniem w nim, ale prawie na pewno będą chcieli dowiedzieć się, co się stało, jeśli potraktuje się to jako “WTF” zamiast pozornie oburzającego oskarżenia.

Jeśli sprawy będą wyglądały tak, jak twierdzono, dochodzenie będzie krótkie i rozstrzygające. Brzmi to tak, jakbyś i tak był lepszym pracownikiem, więc czas przesieje pszenicę z plew; bądź wielkoduszny i nie “uderzaj” w politykę biurową.

Woah Betty, rozbijmy to:

Coworker ukradł kod całkowicie i twierdzi, że napisał to wszystko

^ To dość poważne. Jeśli idzie dookoła mówiąc ludziom “to jest praca, którą wykonałem”, to na pewno powiedz swojemu menadżerowi “Hej, chciałbym tylko wskazać ci tę stronę z githubem, aby pokazać, że jestem autorem całej tej pracy, podczas gdy Bob tylko ten jeden połączył się. Zwracam na to uwagę, ponieważ nie chcę, abyś miał wrażenie, że nie wykonałem swojej części pracy, a jednocześnie przeszkadza mi to, że Bob próbuje przypisać sobie zasługi za pracę, której nie wykonał.”

But

Today, Bob połączył jakiś kod w naszej głównej gałęzi.

Czy Bob naprawdę “twierdzi”, że napisał to wszystko? Czy też po prostu połączył jakąś gałąź w mistrza i nikt nie wie/nie obawia się, jaka nazwa jest obok tego połączenia? W mojej firmie, jeśli kierownictwo nie przeglądałoby jakiejś katastrofy, nikt nie patrzyłby na to, kto jest autorem tego commita.

Poza gitem, czy jest jakieś inne narzędzie do zarządzania projektami, którego używa Twój menedżer, aby zobaczyć, ile pracy wszyscy wykonują? Jeśli tak, to nazwisko na commitu nic nie znaczy. Jeśli nie, to kierownictwo jest na tyle kiepskie, że nie sądzę, aby ktokolwiek oglądał historię gita.

Miałeś kod. Użył tego kodu, by wykonać swoje zadanie. Ta część jest całkowicie akceptowalna. Nie ma powodu, aby napisać rozwiązanie, gdy istniejące rozwiązanie działa.

Chciałeś otrzymać kredyt za kod. Wspomniałeś, że używał takiego języka jak ja i ja w gicie commits zawierającym twój kod. Git commits nie powinien być narzędziem do zarządzania, ani narzędziem do przypisywania kredytów za wykonaną pracę. Oprogramowanie do zarządzania projektem lub system, który jest używany, powinien obsługiwać, kto za co otrzymuje punkty. Jeśli oboje zostaliście przydzieleni do tego samego zadania, kierownictwo prawdopodobnie oczekuje, że będziecie korzystać ze swoich pomysłów i kodu. Jeśli jest to wspólne zadanie, obydwaj powinniście być uczciwie zatrudnieni w tej samej branży.

Prawdziwą kwestią są wasze obawy dotyczące jego umiejętności i/lub etyki pracy. Należy się tym zająć oddzielnie od tego konkretnego incydentu.

Powinieneś najpierw porozmawiać ze swoim współpracownikiem. W tej chwili brzmi to tak, jakby zdarzyło się to tylko raz. Często zdarzało mi się łamać swój kodeks współpracowników i pozwalam im łamać mój kodeks. Jeśli jednak dotyczy to Ciebie, powiedz mu, że historia git jest ważna i chciałbyś, aby Twoje imię i nazwisko było dołączone do któregokolwiek z Twoich kodów, które zostały popełnione. Nalegaj, aby nie obwiniać go za błędy w kodzie.

Jeśli nadal będzie miał słabe wyniki w pracy, porozmawiaj z kierownictwem o jego wynikach (nie o commitach). Możesz wspomnieć, że jego commits często używa twojego kodu, ale nie mów o tym, ponieważ nie ma w tym nic złego. Musisz tylko wyjaśnić, że nie powinni oni używać commitów do oceny jego umiejętności lub etyki pracy, ponieważ jest to twój kod.

**Przeczytaj również firmowy podręcznik dla pracowników, prawdopodobnie mają oni zasady dotyczące nieetycznego zachowania i tego, jaki jest ich proces raportowania.

Kiedy zgłosisz to, jak również, ** upewnij się, że jest to w formie pisemnej / e-mail** , jakbyś potrzebował się do tego później odnieść, powinieneś mieć to bardzo dobrze udokumentowane, że tak się stało i skarga została złożona.

Czy Twoim celem jest upewnienie się, że dostajesz kredyt za napisany kod?

Pomysł, aby kod był “Twój” nie jest dobrym sposobem na myślenie o pracy, którą wykonujesz dla firmy. Kod, który napisałeś nie należy do Ciebie, ale do firmy. Nie powinno mieć znaczenia, czy kod został popełniony z Twojego oddziału, czy z oddziału Boba. Ty i Bob macie wspólny cel, aby wykonać wszystkie zadania, które są potrzebne do stworzenia produktu.

To jedno, jeśli Twój menedżer uważa, że nie ciągniesz za sobą ciężaru, ale Bob jest, ale Twoje pytanie sprawia, że brzmi ono bardziej, jakbyś czuł się okradziony.

Niektóre z komentarzy odnosiły się do tego, ale odpowiedzi (zwłaszcza zaakceptowana odpowiedź) wydają się iść w zupełnie innym kierunku. Właściwy kierunek działania zależy od Twoich rzeczywistych celów, ale jeśli Twój menedżer nie sprawdza dzienników zobowiązań, aby upewnić się, że Ty i Bob wykonujecie wystarczająco dużo pracy, to nie czułbym potrzeby robienia czegokolwiek w tej sytuacji.

Brzmi to tak, jakby najgorszą rzeczą, jaką zrobił tutaj Bob, było niestosowanie się do najlepszych praktyk w zakresie kontroli źródła. Połączenie twoich zmian pozwoliłoby na lepszą historię rewizji niż kopiowanie/wklejanie twoich zmian. Rozsądne jest wyjaśnienie mu tego i wyjaśnienie powodów. Ale z informacji, które mamy w pytaniu; nie jest to kwestia, w której trzeba formalnie coś napisać i upewnić się, że kopiuje się swojego menedżera. Wystarczy przypadkowo mu o tym wspomnieć.

Brzmi to jak fuzja, która poszła w złym kierunku; nie udaję, że rozumiem git na tyle dobrze, aby wiedzieć dokładnie, dlaczego tak się dzieje, ale Visual Studio czasami tworzy commits na lokalnym repozytorium, kiedy używasz IDE do rozwiązywania konfliktów fuzji. Pojawia się to w historii, jako podjęcie wszystkich zmian w zdalnym repozytorium, zastosowanie ich do własnego repozytorium, włączenie ich, a następnie włączenie ich do zdalnego repozytorium.

Racjonalnym wyjaśnieniem jest to, że Bob klikał przez proces łączenia, nie rozumiejąc go i wygenerował historię kontroli źródeł, która jest myląca. Pracując na tym założeniu, zapytaj go z nim, z zamiarem edukowania go, jak prawidłowo połączyć, dając korzyść z wątpliwości co do tego, że sprawa jest błędem.

Po pierwsze, zidentyfikuj, na czym polega problem. Nie jest to do końca jasne z Twojego pytania, tak jak zostało ono zadane.

Jeśli problemem jest to, że Twoje imię zostało wyczyszczone z historii Gita (zakładając, że używasz Gita) i zastąpione jego, to jest to problem z utrzymaniem domu i prawdopodobnie nie jest to oznaką złośliwego zachowania Twojego współpracownika. Jeśli współpracownik utknął na bakcylu na miesiąc, który kind of sugeruje, że może być trochę zardzewiały wokół używania jego narzędzi - w tym kontroli wersji.

Twoje nazwisko powinno być na całym kodzie, który napisałeś. Nie jest to kwestia dumy czy uzyskania kredytu, który jesteś winien - musisz mieć nienaruszoną historię, aby ludzie wiedzieli, kto napisał jaką linię kodu i z kim rozmawiać, gdy w przyszłości napotkają błędy lub dziwne decyzje projektowe. Jeśli twojego imienia już na nim nie ma, to twój współpracownik jest tym, który zadaje pytania o twój kod i bierze na siebie winę za twoje błędy!

Użyj swojego IDE lub narzędzia kontroli źródeł, aby zanotować kod i sprawdzić, czy jego imię jest rzeczywiście na każdej linii. Ogólnie rzecz biorąc, nie ma znaczenia, kto_ połączył kod - jego nazwa jest tylko w tym commit, _nie każda linia kodu w tym commit. To się rozpada, jeśli nie połączył poprawnie oddziałów, aby to zrobić, i to jest coś, co musi zrobić poprawnie.

Jeśli pracujesz w organizacji, gdzie “ile kodu napisałem” jest metryką śledzą i używają go do celów promocyjnych, to powinieneś zgłosić to do kierownictwa. Nie mów “ukradł mi” (nie wiesz, że to zrobił), powiedz “Obawiam się, że jeśli patrzysz na naszą historię kontroli źródeł, aby ocenić nasze zasługi w zakresie podwyżek i promocji, to jego połączenie sprawia, że wygląda na to, że nic nie wniosłem”.

To zależy w dużej mierze od dynamiki Twojej firmy. W moim przypadku (co moim zdaniem jest normą dla większości profesjonalnych firm programistycznych), byłbym na wpół zdeterminowany, aby moje nazwisko zniknęło z kodu, który napisałem… Teraz nie mam ludzi zadających mi pytania o głupie decyzje, które podejmowałem w moim kodzie miesiące wcześniej! :)

Szczerze mówiąc, biorąc pod uwagę podane szczegóły, wszyscy mówiący report it! po prostu wydaje mi się, że to poważna przesada.

Mój współpracownik i ja pracowaliśmy nad projektem przez ponad 2 lata wymieniając się zobowiązaniami tam i z powrotem, i yes , czasami ponownie używalibyśmy lub optymalizowali sobie nawzajem kod.

Nie wiem w jakiej kulturze pracujesz, ale jeśli w jakiś sposób definiuje ona pracę w liniach kodu, a nie produkt końcowy i ogólny wkład, to wydaje się raczej toksyczna i konkurencyjna. Moja rada brzmi: nie uruchamiaj łańcucha komend szukając jakiejś formy odpłaty. Jeśli jest to tak duża sprawa, to porozmawiaj ze swoim menadżerem o tym, jak ustalać punkty za rzeczy, a następnie dokumentuj je w dowolny sposób.

Punktem, który najbardziej chciałem poruszyć była twoja relacja z kolegą. W mojej uczciwej opinii, gdyby mój współpracownik podszedł do mnie pewnego dnia i wykrzyknął: “Nie używaj mojego kodu! To jest mójkod!”, a potem wpakował mnie w kłopoty z zarządzaniem czymś, czego nie robiłem celowo lub złośliwie, pomyślałbym, że był to ważny głupek. Miałbym to na uwadze, ponieważ z pytania nie jest jasne, czy naprawdę ukradli twój kod, czy może po prostu w dziwny sposób połączyli zmiany.

Oskarżenie (które jest dużym oskarżeniem) - jeśli nie zrujnuje całkowicie twojej zawodowej relacji, to z pewnością obniży ich osobistą opinię o tobie. Nic wielkiego, jeśli masz rację. Jestem fanem myślenia typu “kopiesz swój własny grób” - ale jeśli jesteś niewłaściwy, szkoda dla twojego związku zawodowego może być dość znaczna. Polityka biurowa to trudna sprawa!

Teraz, jeśli jesteś absolutnie pewny, że kradnie i przypisuje sobie zasługi za rzeczy, których nie zrobił, skontaktuj się ze swoim menadżerem i podejmij odpowiednie kroki, aby upewnić się, że jest nagradzany za tego typu zachowanie - jeśli jednak nie jesteś pewien, być może przemyśl to ponownie. Plagiat nie jest czymś, co można lekceważyć, zwłaszcza gdy może mieć wpływ na twoje codzienne życie przez dość długi czas.

Podnieś dyskusję ze swoim współpracownikiem i menadżerem o tym, co faktycznie się dzieje, ale nie oskarżaj go o swoje zamiary.

To, co faktycznie się dzieje, to fakt, że połączyli oni Twój kod tak, jakby był on ich własnym. Mogło to być zrobione z osobistej wendety, abyś wyglądał na głupca, ale to jest oskarżenie o intencje, które jest o wiele trudniejsze do udowodnienia, a na podstawie tego, co umieściłeś, nie ma nic, co wskazywałoby na złośliwe intencje współpracownika.

Skup się na tym, aby uczynić z tego moment nauczania, zakładając, że jego ignorancja na temat sposobów prawidłowego używania gita. Git zapewnia wiele sposobów na umożliwienie deweloperowi ponownego użycia kodu innego dewelopera przy jednoczesnym zachowaniu autorstwa. Dwa podstawowe narzędzia to komenda merge and cherry-pick.

Powiedz im, by mieli świadomość, że zachowanie metadanych i autorstwa historii jest ważne w projekcie.

Meta-informacja, taka jak autorstwo, istnieje w systemie kontroli wersji, takim jak git nie tyle do śledzenia własności, co bardziej do pomocy zrozumienia, jak coś musi być takie, jak jest.

Podczas gdy proste przepływy łączą commits o indywidualnym autorstwie, istnieje wiele przypadków, w których to nie działa, lub nie uchwycić pełną historię w stałych pól commit.

Coś takiego jak refactoring lub nawet zastosowanie nowo utworzonych reguł whitespace do bloku kodu dotyczy tego, co git uważa za nowe autorstwo, ponieważ git rozumie tylko dosłowne szczegóły, a nie znaczenie. I to tylko w przypadkach, gdy kod jest nadal używany w swojej pierwotnej roli i dokładnej lokalizacji pliku.

Wiele innych przypadków, takich jak oparcie rozwiązania problemu new na kodzie skopiowanym z rozwiązania starszego problemu w firmowej bazie kodów, szuka całego świata na VCS jak prawdziwego, nowego autorstwa.

Choć daleko mi do doskonałości, kiedy tworzę commit oparty w dużej mierze na istniejącej już pracy (zwłaszcza czyjejś przeniesionej lub znacznie przerobionej), staram się wspomnieć o jego pochodzeniu w komunikacie commit. Jest to w pewnym sensie zasługą, ale w większym lub większym stopniu, aby stworzyć zapis związku z innym kodem. Tak więc na przykład, jeśli w nowym użyciu zostanie znaleziony błąd, warto sprawdzić, czy istnieje on również w miejscu, z którego został skopiowany.

Biorąc to pod uwagę, dobrym sposobem postępowania może być próba użycia procesu przeglądu kodu, aby ostateczne połączenie spornego kodu zostało dokonane w bardziej opisowej wiadomości, która opisała jego faktyczne pochodzenie. I aby ten argument nie tyle zachował “własność” wkładu, ile zachował wiedzę o tym, skąd pochodzi kod, jaki może być jego związek z innym kodem i aby mieć bardziej kompletną listę od kogo szukać wkładu w przypadku trudności.

Nie wiem, czy to zauważyłeś, ale kiedy masz system kontroli kodu źródłowego, a dwie osoby dokonują identycznych zmian, wtedy dostaniesz mnóstwo “łączyć konflikty”, które zamieniają łączenie w czasochłonną i podatną na błędy operację.

Więc na następnym spotkaniu zespołu, na którym omawiane są wszystkie rodzaje rzeczy, możesz powiedzieć “… i w przyszłości, byłbym wdzięczny, gdyby nikt nie wziął niekompletnych zmian z mojego oddziału i połączył je w główny oddział. Zmarnowałem godzinę i godziny pracy na rozwiązywanie łączących się konfliktów z tego powodu”. Całkiem możliwe, że twój szef zapyta wtedy, kto zrobił takie bzdury, a teraz możesz wymienić nazwiska na szefa, nie wyglądając na kapusia.

Połącz jego kod przez sprecyzowanie, że to on go napisał. Zarządzanie fuzjami jest strategią fioletową. Wydaje się, że nie wie jak działa GIT i zapomniał zsynchronizować się ze zmianami. Commits with all’ kod innych osób jest automatycznie generowany przez narzędzia takie jak drzewo źródłowe w przypadku osób używających słabej strategii łączenia

Co jest złe to sprecyzowanie “mojego kodu” w opisie comunità.

Kiedy zostaję uderzony w błąd na jeden dzień ( miesiąc wydaje się być zbyt długi. Nigdy nie zostawałem na robocie przez miesiąc) i łączę zmiany Mówię konkretnie, że łączenie zawiera mój błąd i poprzedni kod od innych, a nawet robiąc to nie wygląda na to, że popełniłem kod od innych.

Jeśli Twój współpracownik pracuje nad oddziałem, powinien najpierw połączyć główny oddział we własny. Test. Następnie połączyć jego oddział z powrotem. W ten sposób zachowasz historię swoich zmian.

Jeśli zacznie kopiować kod z Twojego oddziału bez łączenia, a następnie przesłać go z powrotem, robi to jeszcze gorzej. Pracuje nad wersjami potencjalnie wprowadzającymi nowe błędy.

Wprowadziłbym politykę zobowiązania do przestrzegania i zmusiłbym wszystkich do przestrzegania tej polityki. Wolałbym być bardziej zaniepokojony jego umiejętnościami GIT. To może spowodować havok

Tak, zdarzyło mi się to kiedyś z bardzo niezwykłym współpracownikiem. Pewnego dnia osoba z QA powiedziała mi, że mój kod wygląda dokładnie tak samo jak ten drugi współpracownik. Zalogowałem się do GitHuba i zauważyłem, że kod jest bardzo podobny do mojego, ale na początku zmyłem go, że może dlatego, że gościmy wiele stron udostępniających ten sam plik, kod jest po prostu taki sam, ponieważ robi to samo.

Z czasem zauważyłem, że współpracownik powiedział, że pracuje nad “przeredagowaniem kodu” podczas codziennych postojów aż do ostatniego dnia sprintu, a następnie mówi, że jej kod nie jest gotowy ostatniego dnia i potrzebuje dodatkowego dnia, a następnie tajemniczo następnego dnia setki linii kodu zostały wepchnięte na żądanie pull. Spojrzałem na kod i zauważyłem, że jest on podobny do mojego, aż do błędu ortograficznego, który popełniłem. Wtedy zdałem sobie sprawę, że osoba ta czekała, aż podniosę swoją gałąź, a ona będzie obserwować i kopiować z niej rzeczy.

Byłem tak samo wściekły jak ty. Głównie dlatego, że współpracownik nie przyszedł do mnie, by zapytać, któremu z chęcią pomogę lub pokieruję. Był to jeden z niewielu powodów, dla których zdecydowałem się opuścić firmę po tym, jak podniosłem ją do kierownika, któremu wydawało się, że nie zależy mi na niej. Moją radą jest wychować ją na kierownika, włożyć błąd w pisowni, którego nie można udowodnić przypadkiem. W ten sposób możesz powiedzieć, że nie ma mowy, że to zwykły przypadek.