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

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

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

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

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

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

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

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

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

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

Woah Betty, давайте разберемся:

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

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

Но

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во-первых, определите, в чем проблема. Это не совсем понятно из заданного вопроса.

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

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

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

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

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

Честно говоря, с учетом предоставленных подробностей, все говорят, что report it! просто кажется, что большая реакция на меня.

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

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

Больше всего я хотел затронуть вопрос о ваших отношениях с коллегой. По моему честному мнению, если бы однажды ко мне подошел мой коллега и воскликнул: “Не используй мой код! Это my code!”, а потом у меня возникли проблемы с управлением тем, что я делал не нарочно или злонамеренно, я бы подумал, что он был самовлюбленным придурком. Я бы запомнил это, потому что из вопроса непонятно, действительно ли они украли твой код, или, возможно, просто странным образом сливались в изменениях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объедините его код, указав, что он его написал. Управление своими слияниями - стратегия viale. Похоже, он не знает, как работает GIT, и забыл синхронизироваться с вашими изменениями. Commits with all’ код других людей автоматически генерируется инструментами вроде дерева исходных текстов в случае людей, использующих плохую стратегию слияния

.

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

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

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

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

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

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

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