Some further information: On Windows gbk refers to code page 936, and it is the default ANSI active code page on Windows in some locales, especially where Chinese is spoken. Where English is spoken, code page 1252 is most often the default in Windows.

Python can be made to use UTF-8 instead of the ANSI active code page by running the interpreter with -X utf8 or setting the PYTHONUTF8 environment variable to the value 1. I have found that this (the -X way) has been sufficient to overcome some limitations, such as #1747 before it was fixed. I am unsure if it is sufficient to overcome all such limitations; I have not at this point tested to see if it ameliorates #1362.

Python will also use UTF-8 when instructed to do so, by passing encoding="utf-8" where applicable, which is something that has to be done in the code of a program. If running Python with -X utf8 is sufficient to work around most or all encoding limitations in GitPython, then it might be possible to fix them by using encoding="utf-8" in most or all calls to functions that recognize it (when operating with text). But I am unsure if that would work, because there is also the behavior of external programs, particularly GitPython's git subprocesses, to consider.

Unlike other systems where the most closely related locale settings are more readily changed and can be changed easily for specific commands using simple and well-documented techniques, the ANSI active code page on a Windows system is a system-level setting (unlike the interface language setting and preferred language settings), which can be changed, but only for the whole system, and this is rarely done. This post and its linked sources provide some more information about that. Windows can also be made to use UTF-8 where it would otherwise use a localized code page, though this is considered "beta" and some applications might have problems.