Coworker submitted my code as his own [closed]

Question

A co-worker, Bob, and I have been working on a project that was supposed to be completed together. Due to his lack of time management, he has been stuck on a bug for over a month. Today, Bob merged some code into our master branch.

The issue is, the code that Bob merged into the master branch was code I had written (line for line).

I am unsure how to move forward from here. I can prove that I wrote the code first, but does that even matter?

How would one go about addressing this issue with a passive manager?

Answer 1

I would definitely report it to your manager with proof you wrote it first.

It is not illegal as in a court of law but it is wrong and your manager should know. Tell him if he does it again you will report him again.

Answer 2

You should send an email to him saying something along the lines of:

I see that you pushed the code from my branch to the master branch. Please keep in mind that revision history is important in these sort of products, so having code cut and pasted into the main branch, as you did, should be avoided; rather, the code should be pushed from the branch it was developed on.

and cc your manager. This will make your manager aware of the issue without directly accusing your coworker of misconduct, and frames it as concern for the integrity of the project rather than personal credit.

Answer 3

You sound angry enough to challenge the coworker to a duel, but a lot of devs are more subdued and might appreciate a subtler approach to getting justice.

You could email whomever accepted the pull with your "concerns" about your still-in-development code appearing on master. You don't even have to make any allegations; let them "figure out" what happened on their own. Say your code should be good, but you weren't done testing and tweaking, and are puzzled/concerned about how it made it into master without you submitting a pull request.

This removes most of the drama, but preserves a good possibility for your coworker to get reprimanded, once they figure out how the code inappropriately got onto master. I can see some tech-minded folks getting turned off by conflict, making them less-excited about digging into it, but they will almost assuredly want to figure out what happened if approached as a "WTF" instead of a seeminlgy outrageous allegation.

If things are as claimed, the investigation will be brief and conclusive. It sounds like you're a better worker anyway, so time will sift the wheat from the chaff; be magnanimous and don't "punch down" in office politics.

Answer 4

Woah Betty, let's break this down:

Coworker stole code entirely and claims he wrote it all

^ That's pretty serious. If he is going around telling people "this is the work I have done", then for sure tell your manager "Hey I'd just like to point you to this github page to show I am the author of all this work, while Bob only did this one merge. I'm pointing it out because I don't want you to have the impression that I haven't been doing my share of the work, and at the same time it's bothering me that Bob is trying to take credit for work he hasn't done."

But

Today, Bob merge some code into our master branch.

Is Bob really "claiming" that he wrote it all? Or did he simply merge a branch into master, and nobody knows/cares what name is next to that merge commit? In my company, unless management was reviewing some disaster, nobody would look at who authored which commit.

Besides git, is there some other project management tool your manager uses to see how much work everyone is doing? If so, a name on a commit wont mean anything. If not, then the management is poor enough that I don't think anyone would be watching git history in any case.

Answer 5

You had code. He used that code to complete his task. That part is perfectly acceptable. No reason to write a solution when an existing solution works.

You wanted credit for the code. You mention he used language like Me and I in the git commits containing your code. Git commits should not be a management tool, or a tool to assign credit for work done. The project management software or system being used should handle who gets credit for what. If you were both assigned to the same task, management likely expects you to use each others ideas and code. You should both be on the same branch honestly if it's a joint task.

The real issue is your concerns with his skills and/or work ethic. That should be addressed separate of this particular incident.

You should first speak to your co worker. At the moment, sounds like this has only happened once. I've often committed my coworkers code, and let coworkers commit my code. If it concerns you though, feel free to tell him that git history is important and you'd like your name attached to any of your code that's committed. Insist that if there's a bug in the code, you don't want him to be falsely blamed.

If he continues to perform poorly at his job, talk to management about his performance (not about the commits). You can mention that his commits often use your code, but don't make that the point, because there's really nothing intrinsically wrong about that on it's own. You just need to clarify that they shouldn't use the commits to evaluate his skill or work ethic because it is your code.

Answer 6

Report this to management. Read your company's employee handbook as well, they likely have a policy on unethical behavior and what their process for reporting it is as well.

When you report this, as well, make sure it's in writing / an email, as if you need to reference it later, you should have it very well documented that this happened and a complaint was made.

Answer 7

Is your goal to make sure you get credit for the code you wrote?

The idea of code being "yours" is generally not a good way to think about work you do for the company. The code you write doesn't belong to you; it belongs to the company. It should make no difference whether the code was committed from your branch or from Bob's branch. You and Bob have a common goal to complete whatever tasks are needed for the product.

It is one thing if your manager believes that you aren't pulling your weight but Bob is, but your question makes it sound more like you feel like you were robbed.

Some of the comments have addressed this; but the answers (especially the accepted answer) seem to go in a very different direction. The right course of action depends on your actual goals; but unless your manager is reviewing the commit logs to make sure that you and Bob are each doing enough work, then I wouldn't feel the need to do anything about this situation.

It sounds like the worst thing Bob did here was to not follow best practices with how to use source control. Merging in your changes would have allowed for better revision history than copy/pasting your changes. It is reasonable to explain this to him, and explain the reasons why. But from the information we have in the question; this is not an issue where you need to formally write something up and make sure to copy your manager. Just casually mention it to him.

Answer 8

This sounds like a merge that has gone screwy; I don't pretend to understand git well enough to know exactly why this occurs, but Visual Studio does sometimes create commits on one's local repository when you use the IDE to resolve merge conflicts. This appears in the history as having taken all the changes to the remote repository, applying them to one's own repository, committing them, and then applying that commit to the remote repository.

The rational explanation here is that Bob has clicked through the merge process without really understanding it and generated source control history that is misleading. Working on that assumption, query it with him with the intention of educating him as to how to properly merge, giving the benefit of the doubt as to the issue being a mistake.

Answer 9

First, identify what the problem is. It's not entirely clear from your question as asked.

If the issue is that your name has been scrubbed from the Git history (assuming you're using Git) and replaced with his, that's a housekeeping issue and probably not a sign of malicious behaviour on the part of your coworker. If a coworker is stuck on a bug for a month that kind of suggests they might be a little rusty around use of their tools - including version control.

Your name should be on all the code you wrote. This isn't a matter of pride or receiving credit you're owed - you need that history intact so people know who wrote what line of code and who to talk to when they encounter bugs or odd design decisions in the future. If your name isn't on it anymore, then your coworker is the one who gets to field questions about your code, and take the blame for your bugs!

Use your IDE or a source control tool to annotate the code and see if his name is actually on every line. In general, it doesn't matter who merged the code - their name only goes on that commit, not every line of code in that commit. That falls apart if he didn't correctly merge branches to make this happen, and that's something he needs to do correctly.

If you work in an organization where "how much code I wrote" is a metric they track and they use it for promotion purposes, then you should bring this up to management. Don't say "he stole from me" (you don't know he did), say "I'm concerned that if your are looking at our source control history to assess our merit for raises and promotions, his merge makes it look like I contributed nothing".

This depends a lot on your company's dynamic. In my case (which I think is the norm for most professional software companies), I'd be semi-delighted to have my name disappear from code I wrote... Now I don't have people asking me questions about foolish decisions I made in my code months earlier! :)

Answer 10

Honestly, given the details provided, everyone saying report it! just seems like a major overreaction to me.

My coworker and I worked on a project for over 2 years swapping commits back and forth, and yes, sometimes we would reuse or optimize each others code.

I don't know what kind of culture you work in, but if it somehow defines work in lines of code rather than end product and overall contribution it seems rather toxic and competitive. My advice would be that you don't run up the chain of command looking for some form of retribution. If it's that big of a deal to you talk to your Manager about how to determine credit for things and then document in whatever way they describe.

The point I most wanted to address was your relationship with your colleague. In my honest opinion if my coworker came up to me one day and exclaimed, "Don't use my code! It's my code!", and then got me in trouble with management over something I wasn't purposely or maliciously doing, I would think he was a self-important twit. I would keep this in mind, because from the question it's unclear as to whether or not they truly stole your code, or were perhaps just merging in changes in an odd way.

The accusation (which is a big accusation to make ) - if it doesn't completely ruin your professional relationship, it would most certainly lower their personal opinion of you. No big deal if you're right. I'm a fan of "you dig your own grave" type thinking - but if you're wrong, the damage to your working relationship could be quite substantial. Office politics are a tricky thing!

Now, if you're absolutely positive that he is stealing and taking credit for things that he did not do, feel free to contact your Manager and take the appropriate measures to make sure he is reprimanded for that type of behavior - however, if you're not really sure, perhaps reconsider. Plagiarism isn't something to claim lightly, especially when it can affect your day-to-day life for quite a long time.

Answer 11

Meta-information such as authorship exists in a version control system such as git not so much to track ownership but more to aid understanding of how something got to be the way that it is.

While simple flows have merges of commits having individual authorship, there are many cases where this does not work, or does not capture the full story in the fixed-purpose fields of a commit.

Something such as refactoring or even applying newly established whitespace rules to a block of code involve what git considers to be new authorship, since git only understands literal details, not meaning. And that's only in cases where code is continuing to be used in its original role and exact file location.

Many other cases, such as basing the solution to a new problem on code copied from the the solution of an older problem within a company's code base, looks for all the world to a VCS like genuine, new authorship.

While far from perfect at doing so, when I create a commit based in large part on existing work (especially someone else's either relocated or substantially re-worked) I try to mention its origin in the commit message. That's somewhat to fairly credit, but as much or more so to create a record of the relationship to other code. So for example, if a bug is found in the new usage, it's worth checking if it also exists in the place the code was copied from.

Given this, a good course of action could be to try to use a code review process to have the final merge of the disputed code be done under a more descriptive message, which described its actual origins. And to make this argument not so much to preserve "ownership" of contribution, but to preserve knowledge of where the code came from, what its relationship to other code may be and to have a more complete list of who to seek input from in the case of difficulty.

Answer 12

Raise a discussion with your coworker and manager of what factually happens, but don't accuse them of their intent.

What factually happens is that they merged your code as if it's their own. This might have been done out of personal vendetta to make you look like a fool, but that's an accusation of intent, which is much harder to prove, and based on just what you've posted there's nothing to indicate any malicious intent from your coworker.

Focus on making this a teaching moment, by assuming his ignorance on the ways use git correctly. Git provides many ways to allow a developer to reuse another developer's code while preserving authorship. The two primary tool here are the merge and cherry-pick command.

Tell them to be aware that preserving metadata and history authorship is important in the project.

Answer 13

I don't know if you have noticed this, but when you have a source code control system, and two people make identical changes, then you will get lots of "merge conflicts" which turn merging into a time consuming and error prone operation.

So on the next team meeting, where all kinds of things are discussed, you can say "... and in the future, I would appreciate it if nobody took incomplete changes from my branch and merged them into the main branch. I wasted hour and hours of work on resolving merge conflicts because of this". It is quite possible that your boss will then ask who did that kind of nonsense, and now you can name names to the boss without looking like a snitch.

Answer 14

Merge his code by specifiying he wrote him. Managing yourself merges Is a viale strategy. seems he dont know how GIT works and forgot to keep in sync with your changes. Commits with all' the code of other people are automatically generated by tools like source tree in case of people using poor merging strategy

What is wrong is specifiying "my code" in comunità description.

When I get struck in a bug for a day ( a month seems too much. Never stayed on a bug for a month) and I merge changes I specifically say the merge include my bugfix plus previous code from other, and even doing so It dont looks like I committed code from others.

If your coworker is working on a branch he should first merge main branch into his own. Test. Then merge his branch back. Doing so will keep history of your changes.

If he start copying code from your branch without merging and then submitting, he is doing even worse. He is working around versioning potentially introducing new bugs.

I would introduce a committ policy to following and Force everyone to respect the policy. I would rather be more worried by his GIT skill. It could cause havok

Answer 15

Yes, I had this happened to me once with a very unusual coworker. One day a QA person told me my code looks exactly the same as this other coworker. I logged into GitHub and noticed the code is eerily similar to mine, but I at first brushed it off that maybe since we host multiple sites sharing the same file, the code is simply the same since it does the same thing.

Over time I observed the coworker said she was working on "refactoring the code" during daily standups up to the final day of the sprint, then says her code is not ready on the last day and need an additional day, and then mysteriously the next day hundreds of lines of code were pushed up on a pull request. I looked at the code and noticed the code is similar to mine, right down to a spelling error I made. Then I realized the person was waiting until I pushed up my branch and she would observe and copy things from it.

I was as furious as you were. Mostly because the coworker did not come to me to ask which I would gladly help or direct. It was one of few reasons I decided to leave the company after I brought it up to a manager who didn't seem to care. My advice is to bring it up to a manager, put in a spelling error that you can prove could not be duplicated by chance. That way you can say there's no way it's a mere coincidence.