Iyfjky

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?

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). — 2 days ago
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." — 2 days ago
People merge code they didn't write all the time. Where exactly is he claiming that he wrote it? — 2 days ago
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? — 2 days ago
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). — 2 days ago

score 121 · Accepted Answer · 2018-10-10 22:21:43Z

up vote
121
down vote

accepted

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.

edited Oct 10 at 22:21

answered Oct 10 at 22:13

paparazzo

34.6k761110

7

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 at 23:18

55

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 at 0:49

47

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 at 7:34

27

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 at 11:01

8

@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 at 11:30

Â |Â
show 8 more comments

Acccumulation 2,1381410 · Answer 2 · 2018-10-11 04:16:18Z

up vote
219
down vote

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.

answered Oct 11 at 4:16

Acccumulation

2,1381410

15

I would advice against directly confronting him like this. This is a case of gross misconduct. I would directly go to the manager.
â€“Â Krumia
Oct 11 at 7:21

90

The manager might not understand what does that mean.
â€“Â Farid Nouri Neshat
Oct 11 at 7:50

34

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 at 8:34

11

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 at 9:09

27

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 at 16:09

Â |Â
show 7 more comments

dandavis 2,4791614 · Answer 3 · 2018-10-11 08:05:32Z

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. — Oct 11 at 8:29
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. — Oct 11 at 9:18
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. — Oct 11 at 9:40
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." — Oct 11 at 10:37
@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. — Oct 11 at 18:14

Goose 33126 · Answer 4 · 2018-10-11 17:01:24Z

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.

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. — Oct 11 at 17:17
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. — Oct 11 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. — Oct 11 at 18:21
@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". — Oct 11 at 20:02
+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. — 2 days ago

schizoid04 2,8953930 · Answer 5 · 2018-10-10 23:31:49Z

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.

I would add, take this STRAIGHT to management before saying anything to your colleague, take their lead on how to handle this. — Oct 11 at 7:06

Mirror318 70527 · Answer 6 · 2018-10-12 06:55:29Z

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.

Tom W 965410 · Answer 7 · 2018-10-12 10:59:48Z

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.

Stefan Mohr 1172 · Answer 8 · 2018-10-12 17:31:36Z

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

Exiltaran 1 · Answer 9 · 2018-10-12 06:31:57Z

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

Chris Stratton 19817 · Answer 10 · 2018-10-12 16:00:59Z

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.

Lie Ryan 33417 · Answer 11 · 2018-10-13 23:53:32Z

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.

Dan 5,03921121 · Answer 12 · 2018-10-11 14:02:42Z

Yes, I had this happened to me once with a very unusual co-worker. One day a QA person told me my code looks exactly the same as this other co-worker. 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 co-worker 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 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 co-worker 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.

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. — Oct 11 at 19:43
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. — 2 days ago

GendoIkari 971 · Answer 13 · 2018-10-12 20:22:21Z

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 excepted 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 causally mention it to him.

score 121 · Accepted Answer · 2018-10-10 22:21:43Z

up vote
121
down vote

accepted

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.

edited Oct 10 at 22:21

answered Oct 10 at 22:13

paparazzo

34.6k761110

7

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 at 23:18

55

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 at 0:49

47

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 at 7:34

27

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 at 11:01

8

@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 at 11:30

Â |Â
show 8 more comments

Acccumulation 2,1381410 · Answer 15 · 2018-10-11 04:16:18Z

up vote
219
down vote

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.

answered Oct 11 at 4:16

Acccumulation

2,1381410

15

I would advice against directly confronting him like this. This is a case of gross misconduct. I would directly go to the manager.
â€“Â Krumia
Oct 11 at 7:21

90

The manager might not understand what does that mean.
â€“Â Farid Nouri Neshat
Oct 11 at 7:50

34

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 at 8:34

11

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 at 9:09

27

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 at 16:09

Â |Â
show 7 more comments

dandavis 2,4791614 · Answer 16 · 2018-10-11 08:05:32Z

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. — Oct 11 at 8:29
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. — Oct 11 at 9:18
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. — Oct 11 at 9:40
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." — Oct 11 at 10:37
@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. — Oct 11 at 18:14

Goose 33126 · Answer 17 · 2018-10-11 17:01:24Z

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.

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. — Oct 11 at 17:17
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. — Oct 11 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. — Oct 11 at 18:21
@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". — Oct 11 at 20:02
+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. — 2 days ago

schizoid04 2,8953930 · Answer 18 · 2018-10-10 23:31:49Z

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.

I would add, take this STRAIGHT to management before saying anything to your colleague, take their lead on how to handle this. — Oct 11 at 7:06

Mirror318 70527 · Answer 19 · 2018-10-12 06:55:29Z

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.

Tom W 965410 · Answer 20 · 2018-10-12 10:59:48Z

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.

Stefan Mohr 1172 · Answer 21 · 2018-10-12 17:31:36Z

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

Exiltaran 1 · Answer 22 · 2018-10-12 06:31:57Z

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

Chris Stratton 19817 · Answer 23 · 2018-10-12 16:00:59Z

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.

Lie Ryan 33417 · Answer 24 · 2018-10-13 23:53:32Z

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.

Dan 5,03921121 · Answer 25 · 2018-10-11 14:02:42Z

Yes, I had this happened to me once with a very unusual co-worker. One day a QA person told me my code looks exactly the same as this other co-worker. 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 co-worker 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 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 co-worker 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.

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. — Oct 11 at 19:43
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. — 2 days ago

GendoIkari 971 · Answer 26 · 2018-10-12 20:22:21Z

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 excepted 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 causally mention it to him.

Search This Blog

Iyfjky

Coworker submitted my code as his own

13 Answers
13

protected by Communityâ™¦ yesterday

13 Answers
13

13 Answers
13

protected by Communityâ™¦ yesterday

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

Coworker submitted my code as his own

13 Answers 13

protected by Communityâ™¦ yesterday

13 Answers 13

13 Answers 13

protected by Communityâ™¦ yesterday

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

13 Answers
13

13 Answers
13

13 Answers
13

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor