We are working using LeSS methodology. Area is divided into feature teams, within a team we split items into task.

I (developer) and another one worked on the same item, we splitted it into tasks, and I gave him the option of choosing that tasks to do. That person for no reason started to do (repeat my tasks), on my question on this, he told that he wanted hands on on overall picture. We agreed that we do the work on the branch that I created. But the person made his branch to put his code to solve my task. After I did my task I committed it to the agreed branch, and as we need to have item to be done, has solved partially task of another person, on which he haven’t worked, And made the commit to the branch, after that in branch is 90% of item.

While I was out of office for 3 days, that person created another branch, for build fix (build was broken by another team). And put my changes manually to the new branch (just copied the files I created), and did the rest 10% of work in that branch. He did it in a way, that only his commits are in history, and as he just moved my files (not git move of course) all history of my commits vanished. So it looks like he did all the work. And he had merged that branch into master.

My arguments to him: Why should we fix build, when commit of another team has broken it? We have our tasks, on which we agreed to do. And this thing of branch creation to fix the build, looks more for me like he did that, to intentionally steal my work.

On which he told that haven’t got time to merge the branch on which we agreed to do the work, and on which I did 90% of total work, to a newly created brunch fix-build

And that we are working for the same aim, as a team, so history of commits doesn’t matter for him, as in scrum there are no individuals, but there is the team.

My arguments: I put my best efforts into code, and I want to be associated with the work I do. As we are working for the contractor I want visibility, that my efforts are recognized and seen. So that is why this situation for me is a code stealing.

Update: added this info to give more details, to help understand the picture better:

  1. the branch is technically visible to everyone. But the way we pass done items, to the client is via pull request, and in it there is only fix-build branch. So only it is exposed explicitly to the customer, and I see no reason why they should search for the initial branch with my code in that case. That person intentionally misused git, in my opinion. He haven’t merged my work, but manually moved my files and did that under his commit and his name, all my commits history was erased
    1. The log of the branch he sent for review to a customer: 4 his commits the first, one is all my work under his name, it appears in history like he created all files and filled them with the contents Second merge with master 3-4 other 10% of the item
    2. The person is a senior developer, so I would expect from such person to know basic of git, that we are using and to be able work under own guidance
    3. Found a good amount idea in comments: the real question is for me not code stealing, but credit stealing
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Aug 14 '19 at 20:49

Yes. I know of scenarios where it's perfectly fine to help another team fix a break but what you've describe sounds super fishy. Way too much code added to simply help fix a build break. Sounds like he's lying about the purpose of the merge. I question if the other team even asked him to fix anything.

If you really want to do something, I would just update the authorship comment in the files you did 100% of to point to you. Your co-worker has zero right to complain. If he does just laugh in his face and make it obvious that you don't take his complaint seriously. If he tries to complain to management you've got him because he's lying. I don't think he'd try that tho.

  • There is no concept of authorship files in most source control systems. The best you can do is change the authorship of changes, but this usually requires non-regular permissions. Aug 14 '19 at 2:47
  • @GregoryCurrie Will clarify. Intended to write authorship comment.
    – HenryM
    Aug 14 '19 at 3:34

Is it a code stealing situation?

It all depends on a your answers to few questions:

  • are you evaluated on basis of number of commits you do? Is it a part of any criteria during contract renegotiation? does it help one gain more visibility?
  • is this culturally acceptable at your workplace - that git branches/work of others may be used without attribution?
  • does the co-worker lack much work experience, i.e., do they not have the skills to work on the other tasks independently?
  • is the co-worker unskilled with git?
  • have there been known instances with the co-worker - of trying to "steal" work of others?
  • was there any high pressure conversation during the 3 days you were absent for the co-worker to fix the build, which led to him going this way?
  • is this 90% - 10% your estimate, or did the scrum team agree with you that 90% was done? was it documented anywhere - ticket, jira, scrum notes?

You see, what you have right now is only one part of the story - yours, which lacks all the facts of the situation. The rational thing would be to get all the relevant facts so that you can form a complete picture, and not let your actions be guided by your current emotions.

Though you are right that there are elements of a negative intent here, you have to realize that all these could also be honest mistakes. It all boils down to the company culture, people, and policies. Try to get answers to these questions with an open mind.

If you still think that the other co-worker was in the wrong - talk to your manager, make him aware of the situation, and check with him how he would want you to proceed. This helps communicate the situation on the ground (credit where it is due), helps you learn what is valued (git history vs work done) in your organization, and allows the manager to keep an eye on the co-worker's behavior for any further patterns of "stealing", and issue him warnings etc.

Additionally you can try setting up good git culture, with the concurrence of the team, so that the situation does not arise again in future for someone else.

  • We as a team evaluated on the number of items we do each sprint.According to the contract it is the only criteria. But this is formal criteria. Wouldn’t you as a team on the side of the customer favour guys that do most of the work, and do it excellent? 2. I am a senior developer, that guy is also the senior developer, wouldn’t you expect from that kind of person to be able to work without supervision? And to know git? I talked to the guy first, he told me that he has no time to fix history, that he agree that this looks like code stealing
    – spin_eight
    Aug 14 '19 at 0:05
  • Only after that , I talked to our scrum master, and he was very angry with why I am wasting his time on that, as for him it doesn’t matter, who did what, unless we failed to deliver the item, he told me that “should we give you an award, every time you do commit” ))), he don’t have experience at this role))) and I don’t think that he is right
    – spin_eight
    Aug 14 '19 at 0:09
  • @spin_eight, try to bring it to your manager (or who is higher in the chain). In the meantime you now know that you cannot trust your coworker and scrum master is irrelevant. Pose this not only as code/task "stealing" but also source control history issue: in real world you should have a branch per item. Otherwise later in the project life you would have hard time relating tasks to code. Also you could play "stupid" and say that you spent such amount of hours working on the task while your colleague also worked on it. So all work you did is a "waste of time".
    – AlexanderM
    Aug 14 '19 at 0:25
  • @AlexanderM yes, and we have a branch per item, this is how we work. And we agreed with that guy, that I also create remote branch, where we commit our work. And I created and tested it( the build was green). Guy just copy pasted my work(1.5 week, like 20 my commits) from that branch, to the new fix-build branch under his name and his commit ( And I think there was no need to make that branch, as everything related to the item worked and was tested, so it was more like excuse for him to steal my work)
    – spin_eight
    Aug 14 '19 at 1:20
  • @spin_eight well, as I said earlier you can bring this up as a wasted effort. You were working on some task for a week and a half. Somebody else also worked on it (I wonder how much time that person would claim for that task) and by the end the other person's code got in with all your effort being "wasted" (since there is no merge info we can assume your work was thrown away)... Now multiply 60 hours (or how many) of your work to the amount you guys charge a client an you would get amount of wasted money.
    – AlexanderM
    Aug 14 '19 at 4:00

The code belongs to the company, not to you. So a colleague using that code elsewhere is in no way stealing. In fact it's commendable that he didn't try to reinvent the wheel.

You need to change your attitude from "it's all about me" to "it's all about the product" and you'll have a much better experience as a professional software engineer.

You're supposed to work together to create a great product, not each sit in your cubicle trying to fight to be the best or most productive team member by whatever metric.

  • While idea is good but if you apply it to situation the answer is wrong. Modern source control systems allow to merge branches to retain commit history which is very useful when you are trying to figure out why some feature is implemented in a way as well as trace down when some bugs were introduced and if this is a bug or a funky business decision. You can joke around evaluations but by the end of the day this is how company decides who is going to be terminated and who is going to be promoted. So the person that is "stealing" your tasks actually gets you to the door.
    – AlexanderM
    Aug 14 '19 at 4:10
  • @AlexanderM Cherrypicking specific pieces of specific files across parallel branches in VCSs is a nightmare. Often (usually) a lot faster to just check out both branches and just copy the code from one to the other.
    – jwenting
    Aug 14 '19 at 4:12
  • looks like they are using git. No offence, but from my experience the only source control system where it was easier to do things like that was TFS (through out my career I have used TFS, SVN, Hg & Git). Either way cramming multiple things into one branch (build fix + some feature that was "cherrypicked" from the other branch by the other dev) is a bad style at the best.
    – AlexanderM
    Aug 14 '19 at 4:50

Is it a code stealing situation?

No, as you do not own the code. The company does.

Is it a credit stealing situation?


There are legitimate reasons why he may fold your code into his. If he is preparing to push upstream, it would be best to squash commits together. Usually commits that break the build, or break functionality would be folded in such a way that at any commit in the chain the software is more or less working.

Or he could be simply merging the code together the best way under the circumstances.

Maybe the cause doesn't matter though, only the effect.

But why do you care?

You said you're not an independent contractor, but an employee. (And I will assume you're not from India - Russia maybe?) Usually this would mean that you don't need to impress the client with your effort, but your company must impress the client with delivery.

The question is, how would you be judged on your performance? Given the client doesn't employ you, why are you so concerned about them judging your performance on the pull request? If your manager can see the repositories, they can see the effort you are putting in.

Having said all this, there are workflow issues within the team. Before you start your next sprint, you need to sit down with your team-mate and discuss who will do what. If they wish to do everything, you need to talk to your manager and see if that's acceptable.

The reason you should highlight this is because of the impact it has on delivery, and also quality. (Having two people work on something will lead to better quality than a single person soloing it).

In addition, you need to highlight the poor merging strategies (if they existed in this instance) and highlight the risks involved with them.

If you go to your manager and complain that he is "stealing your work", that's not really something your manager will take seriously.

We as a team evaluated on the number of items we do each sprint.

Then surely your work tracking software will indicated what items you have worked on. If he starts aggressively assigning your tasks to himself, that is something you need to chat with the manager about.

Not the answer you're looking for? Browse other questions tagged .