As yet another corollary to the existing answers here, let’s rephrase the problem statement.

The answer to “should I export” is identical to the answer to the question “Does your subsequent code run a command which implicitly accesses this variable?”

For a properly documented standard utility, the answer to this can be found in the ENVIRONMENT section of the utility’s man page. So, for example, the git manual page mentions that GIT_PAGER controls which utility is used to browse multi-page output from git. Hence,

# XXX FIXME: buggy
branch="main"
GIT_PAGER="less"
git log -n 25 --oneline "$branch"
git log "$branch"

will not work correctly, because you did not export GIT_PAGER. (Of course, if your system already declared the variable as exported somewhere else, the bug is not reproducible.)

We are explicitly referring to the variable $branch, and the git program code doesn’t refer to a system variable branch anywhere (as also suggested by the fact that its name is written in lower case; but many beginners erroneously use upper case for their private variables, too! See Correct Bash and shell script variable capitalization for a discussion) so there is no reason to export branch.

The correct code would look like

branch="main"
export GIT_PAGER="less"
git log -n 25 --oneline "$branch"
git log -p "$branch"

(or equivalently, you can explicitly prefix each invocation of git with the temporary assignment

branch="main"
GIT_PAGER="less" git log -n 25 --oneline "$branch"
GIT_PAGER="less" git log -p "$branch"

In case it’s not obvious, the shell script syntax

var=value command arguments

temporarily sets var to value for the duration of the execution of

command arguments

and exports it to the command subprocess, and then afterwards, reverts it back to the previous value, which could be undefined, or defined with a different – possibly empty – value, and unexported if that’s what it was before.)

For internal, ad-hoc or otherwise poorly documented tools, you simply have to know whether they silently inspect their environment. This is rarely important in practice, outside of a few specific use cases, such as passing a password or authentication token or other secret information to a process running in some sort of container or isolated environment.

If you really need to know, and have access to the source code, look for code which uses the getenv system call (or on Windows, with my condolences, variations like getenv_s, w_getenv, etc). For some scripting languages (such as Perl or Ruby), look for ENV. For Python, look for os.environ (but notice also that e.g. from os import environ as foo means that foo is now an alias for os.environ). In Node, look for process.env. For C and related languages, look for envp (but this is just a convention for what to call the optional third argument to main, after argc and argv; the language lets you call them anything you like). For shell scripts (as briefly mentioned above), perhaps look for variables with uppercase or occasionally mixed-case names, or usage of the utility env. Many informal scripts have undocumented but discoverable assignments usually near the beginning of the script; in particular, look for the ?= default assignment parameter expansion.

For a brief demo, here is a shell script which invokes a Python script which looks for $NICKNAME, and falls back to a default value if it’s unset.

#!/bin/sh
NICKNAME="Handsome Guy"
demo () {
    python3 <<\____
from os import environ as env
print("Hello, %s" % env.get("NICKNAME", "Anonymous Coward"))
____
}
demo
# prints "Hello, Anonymous Coward"
# Fix: forgot export
export NICKNAME
demo
# prints "Hello, Handsome Guy"

As another tangential remark, let me reiterate that you only ever need to export a variable once. Many beginners cargo-cult code like

# XXX FIXME: redundant exports
export PATH="$HOME/bin:$PATH"
export PATH="/opt/acme/bin:$PATH"

but typically, your operating system has already declared PATH as exported, so this is better written

PATH="$HOME/bin:$PATH"
PATH="/opt/acme/bin:$PATH"

or perhaps refactored to something like

for p in "$HOME/bin" "/opt/acme/bin"
do
    case :$PATH: in
     *:"$p":*) ;;
     *) PATH="$p:$PATH";;
    esac
done
# Avoid polluting the variable namespace of your interactive shell
unset p

which avoids adding duplicate entries to your PATH.