Коллега отправил мой код как свой собственный [закрыто]

Я обязательно сообщу об этом вашему менеджеру с доказательством того, что вы написали это первым.

Это не является незаконным, как в суде, но это неправильно, и ваш менеджер должен об этом знать. Скажи ему, что если он сделает это снова, ты снова на него сообщишь.

Вы должны отправить ему электронное письмо, в котором говорится что-то вроде:

Я вижу, что вы переместили код из моей ветки в главную ветку. Пожалуйста, имейте в виду, что история изменений важна для такого рода продуктов, поэтому следует избегать вырезания и вставки кода в основную ветку, как это сделали вы; скорее, код должен быть отправлен из ветки, в которой он был разработан.

и копия вашего менеджера. Это позволит вашему руководителю узнать о проблеме, не обвиняя напрямую вашего коллегу в неправомерных действиях, и сформулирует это как заботу о целостности проекта, а не о личном кредите.

Вы кажетесь достаточно злым, чтобы вызвать коллегу на дуэль, но многие разработчики более сдержанны и могут оценить более тонкий подход к восстановлению справедливости.

Вы можете отправить электронное письмо тому, кто согласился, с вашими «опасениями» по поводу того, что ваш код, который все еще находится в разработке, появляется на мастере. Вам даже не нужно делать никаких утверждений; пусть сами "разбираются" в том, что произошло. Скажите, что ваш код должен быть хорошим, но вы не закончили тестирование и настройку и озадачены/обеспокоены тем, как он превратился в мастер без отправки запроса на включение.

Это устраняет большую часть драмы, но сохраняет хорошую возможность для вашего коллеги получить выговор, как только они выяснят, как код ненадлежащим образом попал в master. Я вижу, как некоторых технически мыслящих людей отталкивает конфликт, что делает их менее заинтересованными в том, чтобы копаться в нем, но они почти наверняка захотят выяснить, что произошло, если подойти к ним как к «какому хрену», а не кажущемуся возмутительным обвинению.

Если все так, как утверждается, расследование будет кратким и убедительным. Похоже, вы в любом случае лучше работаете, так что время просеет зерна от плевел; быть великодушным и не "бить вниз" в офисной политике.

Вау, Бетти, давайте разберем это:

Сотрудник полностью украл код и утверждает, что написал его полностью

^ Это довольно серьезно. Если он ходит и говорит людям: «Это работа, которую я сделал», то обязательно скажите своему менеджеру: «Эй, я просто хотел бы указать вам на эту страницу github, чтобы показать, что я автор всей этой работы, в то время как Боб слился только этот. Я указываю на это, потому что не хочу, чтобы у вас сложилось впечатление, что я не выполняю свою часть работы, и в то же время меня беспокоит, что Боб пытается взять на себя кредит за работу, которую он не сделал».

Но

Сегодня Боб объединит некоторый код в нашу основную ветку.

Действительно ли Боб «утверждает», что он все это написал? Или он просто объединил ветку с мастером, и никто не знает/не заботится о том, какое имя стоит рядом с этим коммитом слияния? В моей компании, если только руководство не анализировало какую-то катастрофу, никто не стал бы смотреть, кто автор какой фиксации.

Помимо git, есть ли какой-нибудь другой инструмент управления проектами, который использует ваш менеджер, чтобы увидеть, сколько работы все делают? Если это так, имя в коммите ничего не значит. Если нет, то управление настолько плохое, что я не думаю, что кто-то в любом случае будет смотреть историю git.

У тебя был код. Он использовал этот код для выполнения своей задачи. Эта часть вполне приемлема. Нет причин писать решение, когда существующее решение работает.

Вы хотели кредит на код. Вы упомянули, что он использовал такой язык, как я и я, в коммитах git, содержащих ваш код. Коммиты Git не должны быть инструментом управления или инструментом для присвоения чести выполненной работе. Используемое программное обеспечение или система управления проектами должны определять, кто и за что получает кредит. Если вам обоим поручили одну и ту же задачу, руководство, скорее всего, ожидает, что вы будете использовать идеи и код друг друга. Честно говоря, вы оба должны быть в одной ветке, если это совместная задача.

Настоящая проблема заключается в том, что вы беспокоитесь о его навыках и/или трудовой этике. Это следует рассматривать отдельно от этого конкретного инцидента.

Сначала следует поговорить с коллегой. На данный момент кажется, что это произошло только один раз. Я часто коммитил код моих коллег и позволял коллегам коммитить мой код. Однако, если это касается вас, не стесняйтесь сказать ему, что история git важна, и вы хотели бы, чтобы ваше имя было прикреплено к любому вашему коду, который был зафиксирован. Настаивайте на том, что если в коде есть ошибка, вы не хотите, чтобы его ложно обвинили.

Если он продолжает плохо справляться со своей работой, поговорите с руководством о его работе (не о коммитах). Вы можете упомянуть, что его коммиты часто используют ваш код, но не придавайте этому значения, потому что на самом деле в этом нет ничего плохого. Вам просто нужно уточнить, что они не должны использовать коммиты для оценки его навыков или трудовой этики, потому что это ваш код.

Сообщите об этом руководству. Прочтите также руководство для сотрудников вашей компании, вероятно, у них есть политика в отношении неэтичного поведения, а также то, как они сообщают об этом.

Когда вы сообщаете об этом, также убедитесь, что это сделано в письменной форме / по электронной почте , как если бы вам нужно было сослаться на это позже, вы должны очень хорошо задокументировать, что это произошло и была подана жалоба.

Ваша цель — убедиться, что вы получили признание за написанный вами код?

Представление о том, что код «ваш», как правило, не лучший способ думать о работе, которую вы выполняете для компании. Код, который вы пишете, вам не принадлежит; он принадлежит компании. Не должно иметь значения, был ли код зафиксирован из вашей ветки или из ветки Боба. У вас с Бобом есть общая цель — выполнить все задачи, необходимые для продукта.

Одно дело, если ваш менеджер считает, что вы не берете на себя ответственность, в отличие от Боба, но ваш вопрос звучит так, будто вы чувствуете себя ограбленным.

Некоторые комментарии касались этого; но ответы (особенно принятый ответ), похоже, идут совсем в другом направлении. Правильный курс действий зависит от ваших реальных целей; но если ваш менеджер не просматривает журналы коммитов, чтобы убедиться, что вы и Боб делаете достаточно работы, то я не чувствую необходимости что-либо делать в этой ситуации.

Похоже, худшее, что сделал Боб, — ​​это не следовать передовым методам использования системы управления версиями. Слияние ваших изменений позволило бы улучшить историю изменений, чем копирование/вставка ваших изменений. Разумно ему это объяснить, и объяснить причины. Но из информации, которую мы имеем в вопросе; это не проблема, когда вам нужно что-то официально написать и обязательно скопировать вашего менеджера. Просто невзначай скажи ему об этом.

Это звучит как неудачное слияние; Я не претендую на то, что понимаю git достаточно хорошо, чтобы точно знать, почему это происходит, но Visual Studio иногда создает коммиты в локальном репозитории, когда вы используете IDE для разрешения конфликтов слияния. Это отображается в истории как принятие всех изменений в удаленный репозиторий, применение их к собственному репозиторию, их фиксация, а затем применение этой фиксации к удаленному репозиторию.

Рациональное объяснение здесь состоит в том, что Боб щелкнул по процессу слияния, не понимая его по-настоящему, и сгенерировал историю контроля версий, которая вводит в заблуждение. Работая над этим предположением, спросите его о нем с намерением научить его правильному слиянию, давая преимущество сомнениям в том, что проблема является ошибкой.

Сначала определите, в чем проблема . Это не совсем ясно из вашего вопроса, как задано.

Если проблема в том, что ваше имя было вычищено из истории Git (при условии, что вы используете Git) и заменено его именем, то это хозяйственная проблема, а не признак злонамеренного поведения со стороны вашего коллеги. Если коллега застрял на ошибке в течение месяца, это говорит о том, что он может быть немного заржавевшим в использовании своих инструментов, включая контроль версий.

Ваше имя должно быть во всем коде, который вы написали. Это не вопрос гордости или получения кредита, который вам причитается — вам нужна неповрежденная история, чтобы люди знали, кто написал какую строку кода и с кем поговорить, когда они столкнутся с ошибками или странными дизайнерскими решениями в будущем. Если вашего имени больше нет, то ваш коллега — это тот, кто отвечает на вопросы о вашем коде и берет на себя вину за ваши ошибки!

Используйте свою IDE или инструмент управления исходным кодом, чтобы аннотировать код и посмотреть, действительно ли его имя присутствует в каждой строке. В общем, не имеет значения , кто слил код — их имя появляется только в этом коммите, а не в каждой строке кода в этом коммите . Это разваливается, если он неправильно объединил ветки, чтобы это произошло, и это то, что ему нужно сделать правильно.

Если вы работаете в организации, где «сколько кода я написал» является метрикой, которую они отслеживают и используют в целях продвижения по службе, то вы должны сообщить об этом руководству. Не говорите «он украл у меня» (вы не знаете, что он это сделал), скажите: «Я обеспокоен тем, что если вы просматриваете нашу историю контроля версий, чтобы оценить наши заслуги в повышении и продвижении по службе, его слияние покажется как будто я ничего не внес».

Это во многом зависит от динамики вашей компании. В моем случае (что, как мне кажется, является нормой для большинства профессиональных софтверных компаний), я был бы почти рад, если бы мое имя исчезло из кода, который я написал... Теперь у меня нет людей, задающих мне вопросы о глупых решениях, которые я принимал. сделано в моем коде месяцами ранее! :)

Честно говоря, учитывая предоставленные детали, все говорящие сообщают об этом! просто кажется мне серьезной чрезмерной реакцией.

Мой коллега и я работали над проектом более 2 лет, обмениваясь коммитами туда и обратно, и да , иногда мы повторно использовали или оптимизировали код друг друга.

Я не знаю, в какой культуре вы работаете, но если она каким-то образом определяет работу строками кода, а не конечным продуктом и общим вкладом, она кажется довольно токсичной и конкурентной. Мой совет: не взбегайте по служебной цепочке в поисках какой-то формы возмездия. Если для вас это так важно, поговорите со своим менеджером о том, как определить кредит для вещей, а затем задокументируйте, как они описывают.

Вопрос, который я больше всего хотел затронуть, касался ваших отношений с вашим коллегой. По моему честному мнению, если бы мой коллега однажды подошел ко мне и воскликнул: «Не используйте мой код! Это мой код!», а затем вызвал бы у меня проблемы с руководством из-за того, что я не делал намеренно или злонамеренно, я подумает, что он самодовольный дурак. Я хотел бы иметь это в виду, потому что из вопроса неясно, действительно ли они украли ваш код или, возможно, просто странным образом объединяли изменения.

Обвинение (которое является серьезным обвинением) - если оно не разрушит полностью ваши профессиональные отношения, то, безусловно, понизит их личное мнение о вас. Ничего страшного, если ты прав. Я сторонник мышления типа «вы копаете себе могилу», но если вы ошибаетесь , ущерб вашим рабочим отношениям может быть весьма существенным. Офисная политика - штука хитрая!

Теперь, если вы абсолютно уверены, что он ворует и присваивает себе заслуги за то, чего он не делал, не стесняйтесь обращаться к своему руководителю и принять соответствующие меры, чтобы убедиться, что он получил выговор за такое поведение, однако, если вы не совсем уверен , возможно передумаю. Плагиат — это не то, на что можно претендовать легкомысленно, особенно когда он может повлиять на вашу повседневную жизнь в течение довольно долгого времени.

Метаинформация, такая как авторство, существует в системе контроля версий, такой как git, не столько для отслеживания прав собственности , сколько для помощи в понимании того, как что-то стало таким, какое оно есть.

В то время как простые потоки имеют слияния коммитов, имеющих индивидуальное авторство, во многих случаях это не работает или не отражает всю историю в полях с фиксированным назначением коммита.

Такие вещи , как рефакторинг или даже применение недавно установленных правил пробелов к блоку кода, требуют того, что git считает новым авторством, поскольку git понимает только буквальные детали, а не смысл. И это только в тех случаях, когда код продолжает использоваться в исходной роли и в точном местоположении файла.

Во многих других случаях, например, когда решение новой проблемы основывается на коде, скопированном из решения старой проблемы в кодовой базе компании, весь мир ищет в системе контроля версий подлинное новое авторство.

Хотя это далеко не идеально, когда я создаю фиксацию, основанную в значительной степени на существующей работе (особенно чьей-то либо перемещенной, либо существенно переработанной), я стараюсь упомянуть ее происхождение в сообщении фиксации. Это несколько справедливо, но в той же или большей степени для создания записи об отношении к другому коду . Так, например, если ошибка обнаружена в новом использовании, стоит проверить, существует ли она также в том месте, откуда был скопирован код.

Учитывая это, хорошим способом действий может быть попытка использовать процесс проверки кода, чтобы окончательное слияние оспариваемого кода было выполнено под более описательным сообщением, в котором описывалось его фактическое происхождение. И выдвигать этот аргумент не столько для того, чтобы сохранить «право собственности» на вклад, сколько для того, чтобы сохранить знание того, откуда взялся код, какова его связь с другим кодом, и чтобы иметь более полный список тех, у кого запрашивать информацию в случай трудности .

Обсудите с коллегой и руководителем, что происходит на самом деле, но не обвиняйте их в намерениях.

Что на самом деле происходит, так это то, что они объединили ваш код, как если бы он был их собственным. Это могло быть сделано из личной вендетты, чтобы выставить вас дураком, но это обвинение в намерении, которое гораздо сложнее доказать, и, основываясь только на том, что вы опубликовали, нет ничего, что указывало бы на злой умысел со стороны вашего коллеги. .

Сосредоточьтесь на том, чтобы сделать это обучающим моментом, предполагая, что он не знает, как правильно использовать git. Git предоставляет множество способов, позволяющих разработчику повторно использовать код другого разработчика, сохраняя при этом авторство. Двумя основными инструментами здесь являются команда слияния и выбора вишни.

Скажите им, чтобы они знали, что сохранение авторства метаданных и истории важно в проекте.

Я не знаю, замечали ли вы это, но когда у вас есть система управления исходным кодом и два человека вносят идентичные изменения, вы столкнетесь с множеством «конфликтов слияния», которые превращают слияние в трудоемкую и подверженную ошибкам операцию.

Так что на следующем собрании команды, где обсуждаются всякие штуки, можно сказать "... и в будущем, я был бы признателен, если бы никто не брал неполные изменения из моей ветки и не сливал их в основную ветку. Я потратил час впустую и часы работы по разрешению конфликтов слияния из-за этого». Вполне возможно, что ваш начальник потом спросит, кто такую ​​ерунду натворил, и теперь вы можете называть имена начальнику, не выглядя при этом стукачом.

Слейте его код, указав, что он его написал. Управление своими слияниями — жизнеспособная стратегия. кажется, он не знает, как работает GIT, и забыл синхронизировать ваши изменения. Коммиты со всем кодом других людей автоматически генерируются такими инструментами, как исходное дерево, в случае, если люди используют плохую стратегию слияния.

Что неправильно, так это указание «мой код» в описании сообщества.

Когда я сталкиваюсь с ошибкой в ​​течение дня (месяц кажется слишком большим. Никогда не задерживался на ошибке в течение месяца) и я объединяю изменения, я специально говорю, что слияние включает мое исправление плюс предыдущий код из других, и даже делая это, это не так. похоже, я передал код от других.

Если ваш коллега работает над веткой, он должен сначала объединить основную ветку со своей. Тестовое задание. Затем слейте его ветку обратно. Это сохранит историю ваших изменений.

Если он начнет копировать код из вашей ветки без слияния, а затем отправки, у него дела обстоят еще хуже. Он работает над версиями, которые могут привести к появлению новых ошибок.

Я бы ввел политику коммитов для соблюдения и заставил бы всех уважать эту политику. Я бы предпочел больше беспокоиться о его навыках желудочно-кишечного тракта. Это может вызвать хаос

Да, однажды это случилось со мной с очень необычным коллегой. Однажды специалист по контролю качества сказал мне, что мой код выглядит точно так же, как у этого другого сотрудника. Я вошел в GitHub и заметил, что код очень похож на мой, но сначала я отмахнулся от того, что, возможно, поскольку мы размещаем несколько сайтов, использующих один и тот же файл, код просто такой же, поскольку он делает одно и то же.

Со временем я заметил, что коллега сказала, что она работала над «рефакторингом кода» во время ежедневных стендапов до последнего дня спринта, а затем сказала, что ее код не готов в последний день и ему нужен дополнительный день, а затем загадочным образом на следующий день. день сотни строк кода были отправлены по запросу на вытягивание. Я посмотрел на код и заметил, что код похож на мой, вплоть до орфографической ошибки, которую я сделал. Затем я понял, что человек ждал, пока я подниму свою ветку, и она будет наблюдать и копировать вещи с нее.

Я был в ярости, как и ты. В основном потому, что коллега не пришел ко мне, чтобы спросить, что я с удовольствием помогу или направлю. Это была одна из немногих причин, по которым я решил покинуть компанию после того, как рассказал об этом менеджеру, которому, похоже, было все равно. Мой совет — сообщить об этом менеджеру, допустив орфографическую ошибку, которая, как вы можете доказать, не может быть воспроизведена случайно. Таким образом, вы можете сказать, что это никак не может быть простым совпадением.