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?

closed as unclear what you're asking by sleske, Rory Alsop, Eric Lippert, The Wandering Dev Manager, Michael Grubey Oct 18 '18 at 5:40


  • 55
    It's also possible Bob just doesn't know how git and/or your git workflow work, and mistakenly committed your changes to the master branch (which I suppose you had committed to another branch). – jcaron Oct 11 '18 at 22:43
  • 141
    I'm a developer and I'm puzzled at what the issue is. Does your manager review the code and note who wrote what and give a better "grade" to the one who wrote more lines of code? My manager doesn't even look at my code most of the time. I'm evaluated mostly based on what I state I've accomplished, and that's not "wrote 45677 more lines of code than Bob." – Matt Samuel Oct 11 '18 at 23:08
  • 72
    People merge code they didn't write all the time. Where exactly is he claiming that he wrote it? – ESR Oct 12 '18 at 0:47
  • 49
    Hi, welcome to workplace.SE! Unfortunately, the question as asked does not make sense: You write "Bob merge some code into our master branch.", and you seem worried he's trying to claim authorship. However, the author is stored per commit , not per merge. Did Bob create his own commits, containing code you wrote? Or did he merge your commits? – sleske Oct 12 '18 at 8:37
  • 28
    Voted to close because Git works as @sieske said, and it is unclear if he just merged code (which is normal) or if he copied individual commits (which is bad). – Joe S Oct 12 '18 at 11:30

15 Answers 15


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.

  • 8
    Yeah all you can really do is make your manager aware of the situation. It's up to him to decide what to do (if anything). Make sure to explain in neutral terms exactly what happened. Don't just say, "he stole my code." – AffableAmbler Oct 10 '18 at 23:18
  • 70
    Since that developer is stupid enough to use the version control to plagiarize your code, you can trivially prove you had written it. Nobody just sits there and writes pages and pages of new code... it starts of with a branch clone, commits, test runs, then progressive commits of working but incomplete code... you have all the intermediate development commits and time stamps (I assume?), he doesn't... – Nelson Oct 11 '18 at 0:49
  • 55
    Another good reason to report it : if he claims it's his code, your manager will think you did nothing and think you are the lazy one. – LP154 Oct 11 '18 at 7:34
  • 29
    If i were a manger/lead in such situation, 1st question would be, why did OP have code that solved poor man's issue and let him work on the problem. Code reuse is a good thing. Unless, I gave the same task to two people and made them compete, which seems like waste of resources. My point is that going to the manager and telling what happened like in the question, might back fire at least a bit. – luk32 Oct 11 '18 at 11:01
  • 12
    @luk32 It's not clear to me from the question whether the commit contained the bugfix said coworker was to create or something else entirely. I've made a request for clarification on the question. – Inarion Oct 11 '18 at 11:30

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.

  • 15
    I would advice against directly confronting him like this. This is a case of gross misconduct. I would directly go to the manager. – sampathsris Oct 11 '18 at 7:21
  • 110
    The manager might not understand what does that mean. – Farid Nouri Neshat Oct 11 '18 at 7:50
  • 41
    You could be more clear so the manager also understands. Still focused on integrity and processes but more explicit about that the colleague slapped his name on others work: "By copying the content of my commits, the system now shows you as the author even though I wrote the code. This could cause issues if other people have questions about the code or need support with it, since they won't see the real author." – kapex Oct 11 '18 at 8:34
  • 13
    For me, just CC'ing the manager is too passive-aggressive. Let the manager deal with it, if the manager thinks it's something worth dealing with, and separately let the manager know you're unhappy that your coworker did this. That's what managers are for. – T.J. Crowder Oct 11 '18 at 9:09
  • 43
    This. Don't focus on his "stealing" of the code. Focus on the gross irresponsibility of throwing away revision history and committing one huge blob that doesn't document any of the changes being made or how they were arrived at. – R.. Oct 11 '18 at 16:09

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.

  • This is the best answer. Stick to process and don't make it personal. And if you're going to accuse someone, you always want a second pair of eyes on the evidence. – John Wu Oct 11 '18 at 8:29
  • 17
    I like this answer...except you aren't really puzzled .... you know how it made it onto master. I'd be rather blunter and say something like "it looks like X cut and pasted my code than committed it but that seems like a really strange thing to do so wanted to check what had happened". That 1. Doesn't make you look like an idiot who can't read commit history and 2. doesn't waste someone's time investigating the bit you already know. – Tim B Oct 11 '18 at 9:18
  • 17
    Agreed. Something like "I see that you have taken code from my dev branch (link) and pushed it to master from your own (link). This code was unfinished and shouldn't really have been taken. Please talk to me in future before integrating my work-in-progress code. Also it would be better to use the VCS's merge tool (rather than copy-pasting) in order to preserve history and authorship metadata. Thanks!" CC your manager. – Lightness Races in Orbit Oct 11 '18 at 9:40
  • 2
    I would throw in another option - "I realised that this pull request is almost entirely code I've written; as such it seems to be counter productive for me to review it as well as write it." – UKMonkey Oct 11 '18 at 10:37
  • 2
    @TimB: I share some of your concern with approach, but "idiot" is a bit far; it could be a script typo that pushed it, someone acting under duress, etc; an extreme benefit of the doubt based on not knowing with 100% certainty the whole story. I believe higher-ups time would be expended researching no matter what. I might meet you halfway with something like "it appears X might have pushed it, but that doesn't make sense". While truth is a justification for accusations, this is more about positioning yourself as a team player under adversity and fostering workplace harmony. – dandavis Oct 11 '18 at 18:14

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."


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.

  • 2
    This. Who is actually interested in lines of code? The manager will be interested whether the problem was solved by his devs, not who wrote which lines. – fgysin Oct 15 '18 at 13:57

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.

  • 1
    I don't think re-using code is the same here. If you posted code on github or open source, it's expected the code will be reused, probably without your consent nor authorization nor knowledge. What the OP is suggesting is the person is unable to do work, and simply copying/reusing his code to make his stuff work. Sort of like if you had a 100 page paper due in class, you see a class mate submit his on the teacher's desk without the teacher seeing it and you quickly swiping it and erasing his name and putting yours on it. Is that ethical? No, not really. – Dan Oct 11 '18 at 17:17
  • 2
    I should also add that when you commit code to a work repo, it's expected to be modified and potentially reused all without your consent or acknowledgement. It is assumed that you committed work, and perhaps immediately modified to fix bugs or errors. It's not unheard of or unexpected that after a project, someone is going back to fix bugs or correct errors or even refactor/redesign it to make it more readable for future updates. The OP is not suggesting this. – Dan Oct 11 '18 at 17:20
  • @Dan OP is working together with his coworker on the project. OP does not expect his coworker to resolve the problem he already solved. He expects credit for his work. A better analogy is school group projects. Much like school, credit is not always fairly distributed on group projects. I don't think there's necessarily anything wrong with committing your coworkers code in a group project. Right now it's an isolated incident and OPs larger problem is his coworkers skill or work ethic, and is only worried that his coworker might be masking that as a side effect of that core concern. – Goose Oct 11 '18 at 18:21
  • 16
    @Goose This is work, not school, It's not "your code" and "his code". They are both "the company's code". I agree that taking credit for someone else's work is wrong, but the reason it's wrong is not "because what he did was stealing". – alephzero Oct 11 '18 at 20:02
  • 4
    +1 Seems like if your company is using version control to check for a volume of work done by members of a team, something is wrong at the company--that's like counting lines of code, a known unhelpful practice! You should be working together and submitting code as a team. If, however, they aren't doing the work assigned to them, that's an issue and perhaps you should offer to pair with them and help. – Bill K Oct 11 '18 at 21:26

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.

  • 9
    I would add, take this STRAIGHT to management before saying anything to your colleague, take their lead on how to handle this. – Binary Worrier Oct 11 '18 at 7:06

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.

  • 8
    This is the only correct answer here (so far). The company paid for the development of the code, so the company owns the code. There's no such thing as "Alice's code" and "Bob's code" if Alice and Bob are paid by the same company. – Dawood ibn Kareem Oct 15 '18 at 0:48

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.


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! :)

  • "I'd be semi-delighted to have my name disappear from code I wrote..." Hahaha, I might empathize with this a little too well. I just now today was asked about a code change in 2014, before our current work tracking system... and because I left for a year and came back as a contractor I don't have all my journals. I was able to trace it down from the comments I left... but it took half a day and the team (mainly me) had egg on our faces. – kleineg Oct 16 '18 at 18:19

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.


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.


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.


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.


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


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.

  • 16
    So both of you had exactly the same task? I can understand homework being copied by students, but in a company people usually work on different things that can be combined to something bigger. – fafl Oct 11 '18 at 19:43
  • 1
    I much agree this needs more explanation. – Joshua Oct 11 '18 at 20:16
  • If they had been refactoring it should be really obvious--large changes except for yours. They might also have to integrate your changes with theirs which would be why it looked like they were checking in your code. You guys should probably sync between each other more often--I try to integrate at least daily--often many times a day. – Bill K Oct 11 '18 at 21:28
  • @fafl The company shares a multi level site so sometimes yes, that's why at first I thought it was just a coincident. But other times, it's a seperate project. Either way, the individual never spoken to me and simply waited until I was done to copy code. We're to work individually on our sprint but collaboration is a must with obvious shared code base.I feel this is much different than a team collaboration or team effort because the individual never mentioned roadblocks during daily standups and simply did nothing for the entire sprint until people (myself included) made a pull request. – Dan Oct 15 '18 at 13:03
