同事提交了我的代码作为自己的

你应该给他发一封邮件说：

我看到你把代码从我的分支推送到了主分支。请记住，在这类产品中，修订历史是很重要的，所以应该避免像你这样把代码剪下来粘贴到主分支，而是应该从开发的分支中推送代码。这将使你的经理意识到这个问题，而不会直接指责你的同事有不当行为，并将其归结为对项目完整性的关注，而不是个人信用。

我肯定会向你的经理报告，并证明是你先写的。

这并不像法庭上那样违法，但这是不对的，你的经理应该知道。告诉他，如果他再这样做，你会再次举报他。

你听起来很生气，可以向同事挑战决斗，但很多开发者都比较克制，可能会喜欢用更温和的方法来讨回公道。你甚至不需要提出任何指控，让他们自己 “弄清楚 "发生了什么。说你的代码应该是好的，但你还没有完成测试和调整，你很困惑/担心它是如何在你没有提交pull request的情况下进入master的。我可以看到一些有技术头脑的人因为冲突而被拒之门外，使他们不那么想去调查，但他们几乎肯定会想弄清楚发生了什么事，如果以 "WTF "而不是一个看起来很离谱的指控来接近的话。听起来你的工作能力还是比较强的，所以时间会把麦子从糠中筛出；要有气度，不要在办公室政治中 "打倒"。

Woah Betty，让我们来分解一下：

同事完全偷了代码，并声称这一切都是他写的

^ 这是相当严重的。如果他到处告诉别人 “这是我做的工作"，那么一定要告诉你的经理 "嘿，我只想告诉你这个github页面，说明我是所有这些工作的作者，而Bob只做了这个合并。我指出这一点是因为我不想让你觉得我没有做我的工作，同时，我也不想让我感到困扰，因为Bob想把他没有做的工作归功于他。”

但是*

今天，Bob把一些代码合并到我们的主分支中。还是说他只是把一个分支合并到主分支，而没有人知道/关心合并后的提交后面的名字是什么？在我的公司里，除非管理层在审查什么灾难，否则没有人会去看谁写了哪个提交。

除了git之外，你们的经理是否有其他的项目管理工具来查看每个人都在做什么工作？如果有的话，提交上的名字不会有什么意义。如果没有的话，那么管理就很差，我想无论如何也不会有人去看git的历史记录。

你有代码。他用那段代码完成了他的任务。那部分是完全可以接受的。没有理由在现有的解决方案有效的情况下写一个解决方案。

你想要代码的功劳。你提到他在包含你的代码的git提交中使用了像我和我这样的语言。Git commits不应该是一个管理工具，或者说是一个为所做的工作分配功劳的工具。使用的项目管理软件或系统应该负责处理谁的功劳。如果你们两个人都被分配到同一个任务，那么管理层很可能希望你们使用对方的想法和代码。如果是共同的任务，你们两个人都应该是在同一个分支上。

真正的问题是你对他的技能和/或工作道德的担忧。

你应该先和你的同事谈谈。目前，听起来这事只发生过一次。我经常犯了我的同事守则，也让同事们犯了我的守则。如果是你的问题，你可以告诉他，git历史很重要，你希望你的代码被提交了，你的名字也会被附上。坚持说，如果代码中出现了bug，你不希望他被诬陷。

如果他在工作中的表现仍然很差，可以和管理层谈一谈他的表现（而不是提交的问题）。你可以提到他的提交人经常使用你的代码，但不要把它作为重点，因为这本身并没有什么本质上的问题。你只需要澄清一下，他们不应该用提交者来评价他的技能或工作态度，因为那是你的代码。

报告给管理层。请阅读公司的员工手册，他们可能有关于不道德行为的政策，以及他们的报告程序。

你的目标是确保你写的代码能得到公司的认可吗？

一般情况下，认为代码是 “你的 "的想法是不适合考虑你为公司做的工作。你写的代码不属于你，它属于公司。无论代码是来自你的分支还是Bob的分支，这应该没有什么区别。你和Bob有一个共同的目标，就是完成产品所需要的任何任务。

如果你的经理认为你没有尽到自己的责任，而Bob却尽到了责任，那是一回事，但你的问题听起来更像是你觉得自己被抢了。正确的行动方针取决于你的实际目标；但除非你的经理正在审查提交日志，以确保你和Bob各自做了足够的工作，否则我觉得没有必要对这种情况做任何事情。合并你的修改会比复制/粘贴你的修改更好的修改历史。向他解释这一点，并解释原因是合理的。但从问题中我们所掌握的信息来看；这个问题不需要你正式写出来的东西，一定要抄袭你的经理。随便跟他提一下就可以了。

这听起来像是一个合并失败的合并；我不太了解git，不知道为什么会发生这种情况，但是当你使用IDE解决合并冲突时，Visual Studio有时会在本地版本库上创建提交。这里的合理解释是，Bob在没有真正理解合并过程的情况下点击了合并过程，并生成了误导性的源控制历史记录。在这个假设的基础上，向他提出质疑，希望能教育他如何正确的合并，让他明白这个问题是个错误。

首先，确定问题是什么。

如果问题是你的名字被从Git历史记录中删除了（假设你使用的是Git），然后换成了他的名字，那是内务管理的问题，很可能不是你的同事的恶意行为。如果你的同事在一个bug上纠缠了一个月，那就说明他们可能对自己的工具的使用有点生疏，包括版本控制。这并不是因为你的骄傲，也不是因为你的功劳，你需要的是完整的历史记录，这样人们就会知道是谁写了哪一行代码，当他们将来遇到bug或奇怪的设计决定时，应该找谁来讨论。如果你的名字已经不在上面了，那么你的同事就是那个对你的代码提出问题的人，并为你的bug背黑锅！

使用你的IDE或源码控制工具对代码进行注释，看看他的名字是否真的在每一行上。一般来说，谁合并了代码并不重要–他们的名字只出现在那个提交上，而不是那个提交中的每一行代码。如果他没有正确地合并分支来实现这一点，那就不成立了，而这是他需要正确地去做的事情。

如果你在一个组织里工作，"我写了多少代码 “是他们跟踪的一个指标，他们用它来衡量和他们用它来做推广，那么你应该向管理层提出这个问题。不要说 "他偷了我的东西"（你不知道他偷了我的东西），而应该说 "我很担心，如果你看我们的源控制历史来评估我们的加薪和晋升的功绩，他的合并会让人觉得我没有任何贡献"。在我的情况下（我想这是大多数专业软件公司的常态），如果让我的名字从我写的代码中消失，我会半信半疑…… 现在我不会再有人问我几个月前我在代码中做出的愚蠢决定，我也不会再被人问起了。:)

我的同事和我的同事在一个项目上工作了2年多，来回交换提交，有时我们会重用或优化别人的代码。我的建议是，你不要在指挥链上寻找某种形式的报应。如果这对你来说是个大问题，那就和你的经理谈谈如何确定功劳，然后用他们描述的任何方式记录下来。 这是我的代码！"，然后因为我不是故意或恶意的事情给我的管理层带来麻烦，我会认为他是个自以为是的笨蛋。我会牢记这一点，因为从问题中不清楚他们是否真的偷了你的代码，或者可能只是以一种奇怪的方式合并修改。

指责（这是一个很大的指责）–如果它没有完全破坏你的职业关系，那肯定会降低他们对你的个人看法。如果你说的没错，也没什么大不了的。我是 “你自己挖自己的坟墓 "式的思维方式的粉丝–但如果你错了，对你的工作关系的损害可能是相当大的。办公室政治是一件很棘手的事情！

现在，如果你绝对肯定他是在偷东西，并为他没有做的事情邀功，请随时联系你的经理，并采取适当的措施，确保他因这种类型的行为而受到训斥–然而，_如果你不确定，或许可以重新考虑。抄袭并不是一件可以轻易宣称的事情，尤其是当它会影响你的日常生活相当长的时间。

和你的同事和经理讨论一下实际发生的事情，但不要指责他们的意图。

实际发生的事情是，他们把你的代码合并成了自己的代码。这可能是出于个人恩怨，让你看起来像个傻瓜，但这是对意图的指责，这很难证明，而且根据你所发布的内容来看，没有任何迹象表明你的同事有任何恶意。Git提供了很多方法，让开发者可以在保留作者身份的同时重用另一个开发者的代码。这里最主要的两个工具就是合并和cherry-pick命令。

告诉他们要注意，在项目中保存元数据和历史作者权是很重要的。

在git这样的版本控制系统中，像作者权这样的元信息并不是为了跟踪所有权，而是为了帮助_理解某个东西是如何变成这样的。

诸如重构甚至将新建立的空格规则应用到一个代码块上，都会涉及到git认为是新的作者权，因为git只理解字面的细节，而不是意义。而这只是在代码继续在原来的角色和确切的文件位置上使用的情况下。

还有很多其他的情况，比如将一个新问题的解决方案建立在从公司代码库中的旧问题的解决方案中复制的代码上，在VCS看来，这就像真正的新作者权一样。

虽然在这方面做得还不够完美，但是当我在很大程度上基于现有的工作（尤其是别人的代码，或者是被迁移了的，或者是被重做了的）创建一个提交时，我都会在提交信息中提到它的来源。这在一定程度上是为了公平地归功于它，但也是为了建立一个与其他代码的关系的**记录。所以，比如说，如果在新的用法中发现了一个bug，那么值得检查一下这个bug是否也存在于代码复制的地方。

考虑到这一点，一个很好的做法是尝试使用代码审查流程，让有争议的代码最终合并在一个更有描述性的消息下进行，描述它的实际来源。而提出这个论点并不是为了维护贡献的 “所有权"，而是为了保存_了解代码的来源，了解它与其他代码之间的关系，并有一个更完整的清单，在遇到困难时可以向谁寻求意见***。

不知道大家有没有注意到这一点，当你有一个源码控制系统，两个人做了完全相同的修改，那么你就会得到很多 “合并冲突"，把合并变成了一个耗时又容易出错的操作。

所以在下一次的团队会议上，在讨论各种事情的时候，你可以说”………..以后，如果没有人把我的分支中不完整的修改拿去合并到主分支中，我将会很感激。因为这个，我浪费了一个又一个小时的时间来解决合并冲突"。很有可能到时候你的老板会问是谁干的这种无厘头的事情，现在你可以点名道姓的向老板告密了，而不至于像个告密者。

合并他的代码，指定是他写的。看来他不知道GIT是如何工作的，忘记了与你的修改保持同步。提交与所有'其他人的代码都是由源码树等工具自动生成的，如果有人使用不好的合并策略

在comunità描述中指定 “我的代码 "是错误的。

如果你的同事在做一个分支，他应该先把主分支合并到他自己的分支中。测试一下。然后再把他的分支合并回来。

如果他没有合并就开始从你的分支中复制代码，然后再提交，那他就更糟糕了。

我会引入一个提交策略，强迫大家遵守这个策略。我更担心的是他的GIT技能。这可能会造成大乱。

是的，有一次我和一个很不寻常的同事发生过这样的事情。有一天，一个QA人员告诉我，我的代码看起来和其他同事的代码一模一样。我登录GitHub，发现这个代码和我的代码很相似，但我一开始还以为是我们的网站共享同一个文件，所以代码是一样的，因为它做的事情是一样的。

随着时间的推移，我观察到这位同事说她在每天的standups到最后一天冲刺的时候都在做 “重构代码"，然后在最后一天说她的代码还没准备好，需要多一天的时间，然后第二天就神秘兮兮的推送了几百行代码，在一个拉动请求上推送了几百行代码。我看了一下代码，发现代码和我的差不多，就差一个拼写错误。然后我发现这个人是在等我推送上我的分支后，她会观察，然后把里面的东西复制出来，

我和你一样气愤。主要是因为那个同事没有来找我问，我很乐意帮助或指导。这也是我向经理提出来后决定离开公司的几个原因之一，而经理似乎并不关心这个问题。**我的建议是向经理提出来，写上一个你能证明不可能是偶然的拼写错误。这样你就可以说这不可能只是巧合。