To pile on here: I fundamentally agree with GP, but from your description, I think you ran into a separate issue from how Git's data structure works, too: Git (the CLI tool) is stateful.

Just as you modify the index (which, fundamentally, is shared global state in your repo) whenever you run `git add`, `git rebase` puts your repo in "rebase mode" (which, again, makes your repo global state).

So if you worked for a while in an unfinished rebase (i.e. on a branch in "limbo" between the original and the rebased version), then realized that and ran `git rebase --abort`, what you told Git was: This rebase isn't working, please throw away my attempt and restore things to the way they where before I started it. And thus, you don't see your changes anymore.

So, aside from GP's tip to learn the basic ideas behind Git's DAG (which I support whole-heartedly), here's some further advice:

1. Run `git status` religiously. Always. Basically, every second command should be `git status` until you're confident in your ability to infer the status yourself. Even then: Just `cd`d into your repo? Run `git status`! If that's too much typing work, set up a shell alias.

2. When reading up on Git's data structures, also take time to really learn rebase, with bells and whistles. My advice would be: You should be able to modify history with `git rebase -ir <commit>`. That means: Interactively, and with merge commits in between. And not just moving around commits, either, I mean at least: "Fixup", "reword" and "edit".

This won't be a breeze to learn, but it pays off. And when you've understood it, you can be reasonably sure you can face most situations easily.

3. Now to the positive message :)

You might not have lost your work. Did you check it in properly? Then it's still there. You'll find the commits somewhere in `git reflog`. You could cherry-pick them to your current (old and probably proper) branch position.

On that note: Learn how to use and read `git reflog`. It's obscure, but it is your safety net in Git. If you check stuff in properly and often (you do, right?) you can pretty much always find your changes there, no matter what went wrong. Git rarely really ever throws information away after you officially handed it over. It follows a garbage collection process, and the time between unforced GCs is basically forever (months or so).

Edit: I've got another one:

4. Use a good Git UI. I'm of the opinion that a commit graph for a reasonably small project should be kept readable and understandable. If you want to be conscious of your immediate commit history, I personally find Git UIs to be a much better tool to visualize it. Personally, I use and really like Git Fork [1] -- it's a small project without subscription fee, a more than fair price, and the developers are really responsive. Plus, it's actually pretty bug free, other than its competitors (*cough* Tower *cough*).

The important thing here is: You should never solely rely on a Git UI, as they can never do all the things you want to be able to use Git for. Don't shy away from the CLI. But: I've found that for me, inspecting Git's history on the CLI is at least an order of magnitude worse than using an interactive UI (I believe due to inherent limitations around terminals). So you'll likey want to be able to use both. I'd wager that if you used a UI to check things in and look at the status of your repo, you'd have noticed the ongoing rebase rather quickly.

[1]: https://git-fork.com/