@bharal it matters because he has been a very poor coworker. He has been stuck on a bug for over a month. We missed this projects deadline and had to extend. It matters because I have been passively trying to show how little he does and then he straight outright steals my code.

Does the code have tests with good test coverage? If not, ask him to write tests. That will test at least if he understands the code or not.

"I have been passively trying to show how little he does" - This is your real problem. Passively trying to do something is as good as doing nothing. Your valid options are to address this colleague's lack of work directly, or else to do nothing and accept that you are doing nothing.

If you knew he was stuck on a bug for a month, why didn't you offer to help? Writing your own solution to the bug you knew he was working on and then "hiding" it away in your dev branch is not good. Was it right for him to take it and push it before it's ready? Maybe not, but it sounds like neither of you is working cooperatively here.

You actually can prove that the code is yours since it should have been pushed to your branch first (and many iterations before the result) while his must have appeared one shot.

This sounds really weird - were you and he competing in some kind of test/exam scenario? How did you happen to have code that resolved his bug? And how did he know this? Were you working on the same bug for some reason?

Please clarify: Does the code your coworker committed contain the bugfix he was supposed to do? Or something that was clearly assigned to you?

Are you sure it wasn't a mistake? Not everyone can easily work with git merges. Maybe he wanted to pull your dev branch, add and change some stuff and then merge it into master. After looking at the git-rebase manpage, he did what many people do (source: xkcd.com/1597) and just copied the fixed files into his working copy and committed the result. You especially mentioned "line-by-line", so did he retain your copyright/last-change/author/... comments in the files or did he change them to his name? This would make more clear if there was bad intend or if it is just a misunderstanding.

I agree with @allo. If the dev is as incompetent as you say, he might've had no idea how to correctly pull in your changes, and he might have just copied them in without a clue what he was doing. "Never attribute to malice..."

There isn't really an issue with him using your code in my opinion, one of the main principles of good development is re-usability, so if a solution to the problem already exists why wouldn't he use it? It sounds like the issue is his general work ethic/productivity, which you need to raise with your manager.

Just to be 100% sure, check his commit message. I have in the past committed other peoples' code, for good reasons, crediting them in the message. Nothing of this scale though.

How did you manage to have so much uncommitted code? Never have more than a days uncommitted code (it can be in a feature branch)

Can you give details on why you believe it is your code? How did he get it?

Could you update the body of this post with some of the details you put in the comments? Please also include as closely as possible the exact comments your coworker used when checking in the code

The question seems to assume that merging the code constitutes a claim of authorship. Please clarify (a) whether that assumption is valid in your organization and (b) whether your coworker has explicitly claimed authorship by some other means.

If it's a small repo where I could warn everyone, I'd use --force to fix the history, and then tell the co-worker not to merge my stuff. Escalate if they cause problems after that.

I suppose I'd like to know how feasible a history --force-with-lease fix is