Update 2021:

As I mentioned in “git stash is slow on windows“, with Git for Windows 2.19 (Sept. 2018), git stash (and git rebase) are no longer script-only, but actually a binary compiled with git.exe.

Tim‘s answer illustrates how it is still difficult to ascertain if a rebase is in progress.

That was discussed in the mailing list, leading to patch like “status: rebase and merge can be in progress at the same time“:

Since git rebase -r was introduced, that is possible.
But our machinery did not think that possible, and failed to say anything about the rebase in progress when in the middle of a merge.

There was a case of “rebase in progress” detection before that (2016), with “worktree.c: check whether branch is rebased in another worktree“

This function find_shared_symref() is used in a couple places:

1. in builtin/branch.c: it’s used to detect if a branch is checked out elsewhere and refuse to delete the branch.
2. in builtin/notes.c: it’s used to detect if a note is being merged in another worktree
3. in branch.c, the function die_if_checked_out() is actually used by “git checkout” and “git worktree add” to see if a branch is already checked out elsewhere and refuse the operation.

In cases 1 and 3, if a rebase is ongoing “HEAD” will be in detached mode.
find_shared_symref() fails to detect it and declares “no branch is checked out here“, which is not really what we want.

---

Original answer: 2010

For one thing, there is a ORIG_HEAD in place during a rebase (but that is not limited to the rebase command)

But you can also look at the 2010 Git 1.7.0 git-rebase.sh script itself (which is as “internal” as you can get 😉 ).
Lines like those can give you another clue:

dotest="$GIT_DIR"/rebase-merge
test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply || die "No rebase in progress?"

sabgenton comments:

• The folder rebase-apply seems to appear with rebase,
• but a folder rebase-merge shows up only with with rebase -i.

And hippy also comments, in 2017, that:

The coding guidelines discourage the usage of -o (see Documentation/CodingGuidelines), so the correct way now (2017, but also since 2011, Git 1.7.6) is:

(test -d ".git/rebase-merge" || test -d ".git/rebase-apply") || die "No rebase in progress?"

Jelaby suggests in the comments:

(test -d "$(git rev-parse --git-path rebase-merge)" || \
 test -d "$(git rev-parse --git-path rebase-apply)" )

This correctly handles worktrees and unusual or non-standard layouts that don’t have a .git directory, and also allows you to run this test from a subdir of the working directory.

That is because the git rev-parse --git-path <path>: does resolve “$GIT_DIR/<path>“.

And Elizandro – SparcBR adds in the comments:

Could also redirect the error to null:

(test -d "$(git rev-parse --git-path rebase-merge)" || test -d "$(git rev-parse --git-path rebase-apply) 2>/dev/null"

---

Git 2.6+ (Q3 2015) will print more information during a rebase:

See commit 592e412, commit 84e6fb9 (06 Jul 2015), commit 84e6fb9 (06 Jul 2015), and commit df25e94, commit 05eb563 (30 Jun 2015) by Guillaume Pagès (gitster).
^{(Merged by Junio C Hamano — gitster — in commit 178d2c7, 03 Aug 2015)}

status: give more information during rebase -i

git status gives more information during rebase -i, about the list of commands that are done during the rebase.
It displays:

• the last two commands executed and
• the next two lines to be executed.

It also gives hints to find the whole files in .git directory.

---

Trying and detect the prompt won’t work with Git 2.26+, as shown in commit 6d04ce7

“git rebase” has learned to use the merge backend (i.e. the machinery that drives “rebase -i“) by default, while allowing “--apply” option to use the “apply” backend (e.g. the moral equivalent of “format-patch piped to am“).
(The rebase.backend configuration variable can be set to customize.)

See commit 10cdb9f, commit 2ac0d62, commit 8295ed6, commit 76340c8, commit 980b482, commit c2417d3, commit 6d04ce7, commit 52eb738, commit 8af14f0, commit be50c93, commit befb89c, commit 9a70f3d, commit 93122c9, commit 55d2b6d, commit 8a997ed, commit 7db00f0, commit e98c426, commit d48e5e2 (15 Feb 2020), and commit a9ae8fd, commit 22a69fd (16 Jan 2020) by Elijah Newren (newren).
^{(Merged by Junio C Hamano — gitster — in commit 8c22bd9, 02 Mar 2020)}

git-prompt: change the prompt for interactive-based rebases

In the past, we had different prompts for different types of rebases:

REBASE: for am-based rebases
REBASE-m: for merge-based rebases
REBASE-i: for interactive-based rebases

It’s not clear why this distinction was necessary or helpful; when the
prompt was added in commit e752019 (“Improve bash prompt to detect
various states like an unfinished merge”, 2007-09-30, Git v1.5.5-rc0), it simply added these three different types.
Perhaps there was a useful purpose back then, but there have been some changes:

• The merge backend was deleted after being implemented on top of the interactive backend, causing the prompt for merge-based rebases to change from REBASE-m to REBASE-i.
• The interactive backend is used for multiple different types of non-interactive rebases, so the “-i” part of the prompt doesn’t really mean what it used to.
• Rebase backends have gained more abilities and have a great deal of overlap, sometimes making it hard to distinguish them.
• Behavioral differences between the backends have also been ironed out.
• We want to change the default backend from am to interactive, which means people would get “REBASE-i” by default if we didn’t change the prompt, and only if they specified --am or --whitespace or -C would they get the “REBASE” prompt.
• In the future, we plan to have “--whitespace“, “-C“, and even “--am” run the interactive backend once it can handle everything the am-backend can.

For all these reasons, make the prompt for any type of rebase just be “REBASE“.

---

Since Git 2.17 (March 2018), you also have:

git rebase --show-current-patch

It shows the content of .git/REBASE_HEAD during an interactive rebase which can be paused during conflict.