Как изменить рабочую директорию git

Your Question is :

My default git folder is C:Usersusername.git

But I want to go into c:/project

What command do I need to get into that?

Since you have asked primarily about gitbash which is Linux based (Terminal), there are differences in commands when compared with Command Prompt of Windows.
We’ll discuss gitbash (Terminal) commands only.

1.First of all we must understand that command line(In Windows) and Terminal(In Mac) always points to some folder on storage Drives .

To check towards what directory it is pointing to at any given time. You need to type the command: pwd «an acronym for ‘Print Working Directory’ «.

1. There is a command ls which gives us information about the folders and files in a particular directory. This is quite a handy command and often used to know about the file structure. In my answer I will make use of this also.

1. To traverse along the folder tree we make use of yet another very important command know as cd which stands for change directory. And your question has the answer within this cd command only.

Here are some of the ways to traverse along the folder tree:

3a) cd command let’s us traverse to child directory. Kindly check the snapshot.

3b) Now to traverse back into the parent directory, we make use of cd .. command: Please check the Image below:

By Using the above two steps we can easily solve your Query:

A) Currently you are in : C:Usersusername.git

So, doing cd .. will point the Terminal towards Users folder.

B) Again Typing cd .. will make Terminal to point towards C Drive.

C) Now doing ls at this point will let you know about all the folders and files in C drive.

Check if there is a project folder, Then simply for the last time type the command:

cd project

And Walla you are have traveled so far to reach to your destination. Congratulations.

Note: If the project folder is not created with C drive, simply write the command mkdir project and it will be created. Then follow the above steps to play around.

4) There is one more straight forward quick solution to your problem in particular:

Wherever the terminal is pointing.
Simply write the command:

4a) cd / It will point to default root folder.

Then type the command : cd /c/ to point towards c directory.
Then simply go to child directory, which in your case is project directory
by typing:

cd project

And you are good to go: ENJOY

guides

• Git. Краткое руководство по терминалу
  • Введение
  • Открытие терминала
    • Linux
    • Mac
    • Windows (Git Bash)
    • Первоначальная настройка Git
  • Пути
  • Переменные окружения
  • Автодополнение
  • Ключевые команды
    • Текущий рабочий каталог
    • Смена рабочего каталога
    • Листинг каталога
    • Создание файлов
      • nano
      • Vim
      • VS Code
    • Создание каталогов
    • Перемещение файлов и каталогов
    • Удаление файлов и каталогов
    • На заметку
      • Важность консольных сообщений
      • Выход из программы вывода текста
      • Копирование/вставка
      • “Короткий путь”

Введение

Данное краткое руководство демонстрирует основные команды в терминале Bash:

• Bash (Linux/Mac)
• Git Bash (Windows)

Открытие терминала

Первая задача: открыть терминал сразу в нужном каталоге.

Linux

В Linux достаточно щёлкнуть правой кнопкой мыши на каталоге и выбрать пункт меню Open in Terminal или Открыть в терминале:

Mac

В Mac всё немного сложнее, необходимо настроить отображение этого пункта меню в Finder.

Для этого необходимо перейти в Системные настройки, затем пункт меню Клавиатура, в разделе Службы выбрать раздел Файлы и папки и поставить флажок напротив Новый терминал по адресу папки:

После чего при клике правой кнопкой мыши на каталоге появится необходимый пункт меню:

Windows (Git Bash)

В Windows всё достаточно просто — клик правой кнопкой мыши на каталоге и выбор Git Bash Here:

Первоначальная настройка Git

После установки Git первое, что мы сделаем — укажем наши имя и адрес электронной почты. Это важно, потому как этой информацией подписывается каждый коммит (кто сделал изменения и его электронная почта). Для настройки потребуется ввести команды:

$ git config --global user.name "Thorin Oakenshield"
$ git config --global user.email ereborsons@stone.com

Если указана опция --global, настройки применятся глобально, то есть для всех ваших действий в системе Git. Без этой опции настройки применяются локально, для текущего репозитория, и не влияют на глобальные настройки.

Пути

Одно окно терминала подразумевает, что вы можете в один момент времени находиться только в одном каталоге, который называется Current Working Directory (текущий каталог), так же как и в одном открытом окне Nautilus, Finder или проводника Windows.

Вы можете выполнять команды относительно текущего каталога или относительно абсолютного пути.

Абсолютный путь — это путь, начинающийся от корня файловой системы. Корень файловой системы обозначается символом /.

Например, в Git Bash (Windows) абсолютный путь для каталога Program Files, будет чаще всего выглядеть следующим образом: /c/Program Files/.

Для домашнего каталога в Ubuntu (Linux), абсолютный путь будет выглядеть следующим образом: /home/user/, где user — имя пользователя.

Bash (Git Bash в том числе) используют символ / для разделения каталогов.

Ещё два специальных обозначения помимо корня файловой системы:

• . — обозначает текущий каталог;
• .. — обозначает родительский каталог.

Важно: в терминале символ ` ` (пробел) является символом, разделяющим команды и опции. Поэтому если в пути есть пробел, то варианта два:

• заключать путь в кавычки, то есть "Program Files";
• использовать символ backslash для экранирования пробела: Program Files.

Переменные окружения

Командная оболочка устанавливает ряд переменных, которые выполняют специфические функции. Так, переменная с именем PATH содержит список путей, в которых будет производиться поиск программы, если вы наберёте её название в терминале.

Для вывода содержимого конкретной переменной используется команда echo следующим образом:

Команда printenv позволяет отобразить все переменные окружения:

Видно, что в переменных окружения содержится достаточно много информации о системе.

Автодополнение

В командных оболочках работает автодополнение по клавише Tab:

• дополняются имена команд;
• дополняются пути.

Используйте автодополнение, так как оно позволяет сократить время на набор команды.

Ключевые команды

В этом разделе будут описаны ключевые команды, необходимые нам для работы. Естественно, список этот далеко не полный.

Текущий рабочий каталог

pwd — сокращение от “Print Working Directory”.

Отображение текущего рабочего каталога:

Смена рабочего каталога

cd — сокращение от “Change Directory”.

Переход в определённый каталог:

path может быть как абсолютным, так и относительным путём.

Например, перейти на каталог выше:

Перейти в подкаталог src:

Если перед путём нет слеша — он трактуется как относительный (относительно текущего каталога).

Листинг каталога

ls — сокращение от “List”.

Отображает листинг (содержимое каталога):

По умолчанию, ls не отображает файлы, начинающиеся с ., например, .gitignore. Для отображения таких файлов нужно использовать флаг -a:

Создание файлов

Для создания файлов используются специальные программы (например, для создания текстовых файлов — текстовые редакторы).

В рамках рассмотрения Bash мы рассмотрим два текстовых редактора, которые позволят вам создавать и редактировать файлы в псевдографическом режиме.

nano

nano — простой текстовый редактор.

Для того, чтобы создать файл достаточно ввести команду nano и имя файла:

Откроется редактор следующего вида:

Пункты меню в нижней части вызываются с помощью горячих клавиш, где символ ^ обозначает клавишу Ctrl.

То есть чтобы записать файл и выйти следует последовательно нажать Ctrl + O (запись) и Ctrl + X (выход).

Редактор nano установлен в большинстве Unix-подобных операционных системах и Git Bash.

Vim

Редактор Vim (a programmer’s text editor) — профессиональный редактор, позволяющий достичь максимальной производительности при работе с любыми текстовыми файлами. Настолько популярен, что для любой графической среды (IDE, текстовых редакторов вроде VS Code, Atom, Sublime) всегда есть плагин, включающий возможность редактирования кода в режиме “Vim Mode”.

На освоение работы в Vim нужно потратить достаточно много времени, для этого вы можете воспользоваться интерактивным учебником vimtutor:

Мы лишь скажем, что для выхода из этого редактора (если вы всё-таки осмелились его открыть) нужно нажать клавишу Esc, затем ввести команду :q! — это позволит вам закрыть открытый файл без сохранения изменений.

VS Code

В видео-лекциях используется VS Code. В Windows вы можете правой кнопкой открыть каталог сразу в VS Code.

В Mac OS и Linux вы можете открыть терминал по адресу папки и в терминале выполнить команду code . &, которая откроет выбранный вами каталог в этом редакторе.

Если ни то, ни другое у вас не получилось, то просто откройте VS Code и через File — Open откройте нужный каталог.

Создание каталогов

mkdir — сокращения от “Make Directory”.

Позволяет создавать каталоги (создаст каталог tmp в текущем каталоге):

Стоит обратить внимание на поведение при создании нового каталога в текущей директории. После команды mkdir name ваше текущее расположение в терминале не изменится. Для того, чтобы работать внутри созданного каталога, в него требуется перейти командой cd name. Это справедливо и при клонировании удалённого репозитория с помощью команды git clone <repo_url>. Полностью склонированный репозиторий создаст каталог в текущей директории с именем проекта, в который нужно перейти командой cd repo_name.

Перемещение файлов и каталогов

mv — сокращение от “Move”.

Перемещение (переименование) файлов и каталогов:

Удаление файлов и каталогов

rm — сокращение от “Remove”.

Удаление файла:

Удаление непустого каталога:

Для удаления непустого каталога необходимо указать флаги:

• -r — удалять рекурсивно;
• -f — не спрашивать подтверждения.

На заметку

Важность консольных сообщений

Git является консольной программой — это значит, что у неё нет графического интерфейса, привычного нам по многим оконным приложениям. Программа будет выводить всю важную информацию о своей работе в окно терминала. Обычно программа “молчит”, когда команда выполнена успешно.

При возникновении ошибок Git обязательно сообщит вам об этом, иногда даже подскажет, как поступить дальше.

Внимательно изучая вывод программы, вы сохраняете своё время и понимаете работу программы чуть лучше. Это справедливо для всех консольных приложений.

Выход из программы вывода текста

Бывает, Git пытается нам сказать намного больше, чем умещается в окне терминала. Для этого он пользуется постраничным выводом и когда ему уже нечего выводить появляется метка конца данных (END) или :END. Например, конец вывода команды git log:

Для того чтобы покинуть программу вывода, нужно нажать клавишу q (сокращение от слова “quit” — покинуть) на английской раскладке клавиатуры.

Копирование/вставка

Копирование и вставка из буфера обмена в терминал отличается от тех же действий в обычных текстовых редакторах. Хорошо известная последовательность Ctrl + C и Ctrl + V нужного эффекта не даст. Некоторые последовательности символов зарезервированы в терминале как управляющие, в частности, Ctrl + C служит для прерывания процесса.
Для того чтобы скопировать выделенную область из терминала в буфер обмена, нужно использовать контекстное меню (правая кнопка мышки) или нажать Ctrl + Ins:

Для вставки в поле ввода терминала можно также воспользоваться контекстным меню мышки или зажать Shift + Ins:

Иногда может работать вставка по нажатию на колёсико мышки (средняя кнопка).

“Короткий путь”

Зачастую навигация в терминале сводится к попеременному вводу команд листинга

и, после просмотра содержимого текущей директории, выбору следующей директории.

Но есть способ короче. Если полностью набрать имя следующей директории и нажать два раза клавишу Tab, мы сможем заглянуть внутрь этой директории не прерывая команду.

При этом уже набранный текст команды будет на новой строке, а выше мы увидим содержимое следующей директории.

Хранилище в вычислительной технике известно как центральное место, в котором хранятся и управляются данные. Таким образом, репозиторий Git представляет собой центральное хранилище, в котором будут храниться и управляться все файлы проекта. Git repository-это папка внутри вашей системы, в которой находятся все файлы вашего проекта. Он позволяет сохранять версии вашего кода, так что вы можете получить к ним доступ в любое время.  В вашей системе git repository — это простая папка, как и многие другие папки.

Поскольку теперь мы очень близки к тому, чтобы начать выполнять действия Git, но мы должны знать несколько общих команд каталогов на Git Bash, чтобы сделать процесс простым. К ним относятся:

• Изменение каталога с помощью Git Bash
• Создание каталога с помощью Git Bash
• Посмотреть все каталоги в Git Bash

Изменение каталога очень важно, так как при работе с Git Bash вы постоянно перемещаетесь между разными каталогами. Каталог (директория) — это технический термин для обозначения папки. Вы можете изменить каталог двумя способами:

• Непосредственно через Git Bash с помощью команд
• Открыв Git Bash в нужной папке

Читайте также: Разница между git и github‘

Перейдите в нужный каталог с помощью команд в Git Bash

Вы можете изменить каталог внутри Git Bash с помощью команды cd. Команда cd обычно используется в оболочке вашей системы (cmd) для той же цели. Перейдите в каталог ToolsQA с помощью команды cd

1. Откройте свой Git Bash.
2. Введите следующую команду cd <путь к каталогу> и нажмите клавишу enter.

Примечание: ToolsQA — это папка внутри диска E в данном примере.

Откройте Git Bash прямо в папке

Изменение каталога через открытие его в той же папке — это довольно прямолинейно. Для этого перейдите в каталог, который вы хотите изменить.

После этого щелкните правой кнопкой мыши в любом месте каталога = > откройте Git Bash Here.

После того, как мы научились изменять рабочий каталог, мы можем создать репозиторий в любой папке проекта, где нам нужно работать. Для создания репозитория мы сначала создадим папку, в которой будем работать.

Как создать новый каталог с помощью Git Bash?

Создание каталога с помощью Git Bash — это всего лишь простая команда, которая также используется в системах Linux. Хотя вы можете создать каталог, используя обычный метод создания новой папки, но используйте Git Bash для максимально возможной работы. Давайте посмотрим, как создать каталог с помощью Git Bash.

1. Откройте Git Bash.
2. Перейдите в каталог, в котором вы хотите создать папку.
3. Введите следующую команду mkdir <имя папки> и нажмите клавишу enter, чтобы создать каталог.

Примечание: запомните, что, если вы упоминаете более одного слова имени каталога не в кавычках, он создаст два каталога. Это мы увидим в следующем разделе, а затем удалим эти папки и создадим один каталог под названием «First Project».

Как просмотреть все каталоги в Git Bash?

Теперь, когда мы создали папку, мы также должны знать, как посмотреть на все каталоги/папки внутри нашего рабочего каталога.

1.Перейдите в директорию, в которой вы хотите видеть каталоги (ToolsQA)

1. Введите следующую команду ls и нажмите клавишу Enter. Все каталоги будут видны вам.

Примечание: стоит отметить, что ls не будет показывать скрытые папки. Вам нужно использовать ls-a для этого.

Как удалить папку

Вы можете удалить каталог, используя команду rmdir с именем каталога.

Примечание: mk означает make, а rm  Remove.

Теперь мы все настроены на инициализацию Git внутри нашего каталога проектов. Как уже упоминалось выше, нам нужно знать о команде git init для создания репозитория. Мы кратко рассмотрим команду git init в следующей статье.

Читайте также: Этапы жизненного цикла GIT.

GIT_MERGE_VERBOSITY

A number controlling the amount of output shown by
the recursive merge strategy. Overrides merge.verbosity.
See git-merge[1]

This environment variable overrides $PAGER. If it is set
to an empty string or to the value «cat», Git will not launch
a pager. See also the core.pager option in
git-config[1].

GIT_PROGRESS_DELAY

A number controlling how many seconds to delay before showing
optional progress indicators. Defaults to 2.

GIT_EDITOR

This environment variable overrides $EDITOR and $VISUAL.
It is used by several Git commands when, on interactive mode,
an editor is to be launched. See also git-var[1]
and the core.editor option in git-config[1].

GIT_SEQUENCE_EDITOR

This environment variable overrides the configured Git editor
when editing the todo list of an interactive rebase. See also
git-rebase[1] and the sequence.editor option in
git-config[1].

GIT_SSH

GIT_SSH_COMMAND

If either of these environment variables is set then git fetch
and git push will use the specified command instead of ssh
when they need to connect to a remote system.
The command-line parameters passed to the configured command are
determined by the ssh variant. See ssh.variant option in
git-config[1] for details.

$GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted
by the shell, which allows additional arguments to be included.
$GIT_SSH on the other hand must be just the path to a program
(which can be a wrapper shell script, if additional arguments are
needed).

Usually it is easier to configure any desired options through your
personal .ssh/config file. Please consult your ssh documentation
for further details.

GIT_SSH_VARIANT

If this environment variable is set, it overrides Git’s autodetection
whether GIT_SSH/GIT_SSH_COMMAND/core.sshCommand refer to OpenSSH,
plink or tortoiseplink. This variable overrides the config setting
ssh.variant that serves the same purpose.

GIT_SSL_NO_VERIFY

Setting and exporting this environment variable to any value
tells Git not to verify the SSL certificate when fetching or
pushing over HTTPS.

GIT_ASKPASS

If this environment variable is set, then Git commands which need to
acquire passwords or passphrases (e.g. for HTTP or IMAP authentication)
will call this program with a suitable prompt as command-line argument
and read the password from its STDOUT. See also the core.askPass
option in git-config[1].

GIT_TERMINAL_PROMPT

If this Boolean environment variable is set to false, git will not prompt
on the terminal (e.g., when asking for HTTP authentication).

GIT_CONFIG_GLOBAL

GIT_CONFIG_SYSTEM

Take the configuration from the given files instead from global or
system-level configuration files. If GIT_CONFIG_SYSTEM is set, the
system config file defined at build time (usually /etc/gitconfig)
will not be read. Likewise, if GIT_CONFIG_GLOBAL is set, neither
$HOME/.gitconfig nor $XDG_CONFIG_HOME/git/config will be read. Can
be set to /dev/null to skip reading configuration files of the
respective level.

GIT_CONFIG_NOSYSTEM

Whether to skip reading settings from the system-wide
$(prefix)/etc/gitconfig file. This Boolean environment variable can
be used along with $HOME and $XDG_CONFIG_HOME to create a
predictable environment for a picky script, or you can set it
to true to temporarily avoid using a buggy /etc/gitconfig file while
waiting for someone with sufficient permissions to fix it.

GIT_FLUSH

If this environment variable is set to «1», then commands such
as git blame (in incremental mode), git rev-list, git log,
git check-attr and git check-ignore will
force a flush of the output stream after each record have been
flushed. If this
variable is set to «0», the output of these commands will be done
using completely buffered I/O. If this environment variable is
not set, Git will choose buffered or record-oriented flushing
based on whether stdout appears to be redirected to a file or not.

GIT_TRACE

Enables general trace messages, e.g. alias expansion, built-in
command execution and external command execution.

If this variable is set to «1», «2» or «true» (comparison
is case insensitive), trace messages will be printed to
stderr.

If the variable is set to an integer value greater than 2
and lower than 10 (strictly) then Git will interpret this
value as an open file descriptor and will try to write the
trace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path
(starting with a / character), Git will interpret this
as a file path and will try to append the trace messages
to it.

Unsetting the variable, or setting it to empty, «0» or
«false» (case insensitive) disables trace messages.

GIT_TRACE_FSMONITOR

Enables trace messages for the filesystem monitor extension.
See GIT_TRACE for available trace output options.

GIT_TRACE_PACK_ACCESS

Enables trace messages for all accesses to any packs. For each
access, the pack file name and an offset in the pack is
recorded. This may be helpful for troubleshooting some
pack-related performance problems.
See GIT_TRACE for available trace output options.

GIT_TRACE_PACKET

Enables trace messages for all packets coming in or out of a
given program. This can help with debugging object negotiation
or other protocol issues. Tracing is turned off at a packet
starting with «PACK» (but see GIT_TRACE_PACKFILE below).
See GIT_TRACE for available trace output options.

GIT_TRACE_PACKFILE

Enables tracing of packfiles sent or received by a
given program. Unlike other trace output, this trace is
verbatim: no headers, and no quoting of binary data. You almost
certainly want to direct into a file (e.g.,
GIT_TRACE_PACKFILE=/tmp/my.pack) rather than displaying it on
the terminal or mixing it with other trace output.

Note that this is currently only implemented for the client side
of clones and fetches.

GIT_TRACE_PERFORMANCE

Enables performance related trace messages, e.g. total execution
time of each Git command.
See GIT_TRACE for available trace output options.

GIT_TRACE_REFS

Enables trace messages for operations on the ref database.
See GIT_TRACE for available trace output options.

GIT_TRACE_SETUP

Enables trace messages printing the .git, working tree and current
working directory after Git has completed its setup phase.
See GIT_TRACE for available trace output options.

GIT_TRACE_SHALLOW

Enables trace messages that can help debugging fetching /
cloning of shallow repositories.
See GIT_TRACE for available trace output options.

GIT_TRACE_CURL

Enables a curl full trace dump of all incoming and outgoing data,
including descriptive information, of the git transport protocol.
This is similar to doing curl --trace-ascii on the command line.
See GIT_TRACE for available trace output options.

GIT_TRACE_CURL_NO_DATA

When a curl trace is enabled (see GIT_TRACE_CURL above), do not dump
data (that is, only dump info lines and headers).

GIT_TRACE2

Enables more detailed trace messages from the «trace2» library.
Output from GIT_TRACE2 is a simple text-based format for human
readability.

If this variable is set to «1», «2» or «true» (comparison
is case insensitive), trace messages will be printed to
stderr.

If the variable is set to an integer value greater than 2
and lower than 10 (strictly) then Git will interpret this
value as an open file descriptor and will try to write the
trace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path
(starting with a / character), Git will interpret this
as a file path and will try to append the trace messages
to it. If the path already exists and is a directory, the
trace messages will be written to files (one per process)
in that directory, named according to the last component
of the SID and an optional counter (to avoid filename
collisions).

In addition, if the variable is set to
af_unix:[<socket_type>:]<absolute-pathname>, Git will try
to open the path as a Unix Domain Socket. The socket type
can be either stream or dgram.

Unsetting the variable, or setting it to empty, «0» or
«false» (case insensitive) disables trace messages.

GIT_TRACE2_EVENT

This setting writes a JSON-based format that is suited for machine
interpretation.
See GIT_TRACE2 for available trace output options and
Trace2 documentation for full details.

GIT_TRACE2_PERF

In addition to the text-based messages available in GIT_TRACE2, this
setting writes a column-based format for understanding nesting
regions.
See GIT_TRACE2 for available trace output options and
Trace2 documentation for full details.

GIT_TRACE_REDACT

By default, when tracing is activated, Git redacts the values of
cookies, the «Authorization:» header, the «Proxy-Authorization:»
header and packfile URIs. Set this Boolean environment variable to false to prevent this
redaction.

GIT_LITERAL_PATHSPECS

Setting this Boolean environment variable to true will cause Git to treat all
pathspecs literally, rather than as glob patterns. For example,
running GIT_LITERAL_PATHSPECS=1 git log -- '*.c' will search
for commits that touch the path *.c, not any paths that the
glob *.c matches. You might want this if you are feeding
literal paths to Git (e.g., paths previously given to you by
git ls-tree, --raw diff output, etc).

GIT_GLOB_PATHSPECS

Setting this Boolean environment variable to true will cause Git to treat all
pathspecs as glob patterns (aka «glob» magic).

GIT_NOGLOB_PATHSPECS

Setting this Boolean environment variable to true will cause Git to treat all
pathspecs as literal (aka «literal» magic).

GIT_ICASE_PATHSPECS

Setting this Boolean environment variable to true will cause Git to treat all
pathspecs as case-insensitive.

GIT_REFLOG_ACTION

When a ref is updated, reflog entries are created to keep
track of the reason why the ref was updated (which is
typically the name of the high-level command that updated
the ref), in addition to the old and new values of the ref.
A scripted Porcelain command can use set_reflog_action
helper function in git-sh-setup to set its name to this
variable when it is invoked as the top level command by the
end user, to be recorded in the body of the reflog.

GIT_REF_PARANOIA

If this Boolean environment variable is set to false, ignore broken or badly named refs when iterating
over lists of refs. Normally Git will try to include any such
refs, which may cause some operations to fail. This is usually
preferable, as potentially destructive operations (e.g.,
git-prune[1]) are better off aborting rather than
ignoring broken refs (and thus considering the history they
point to as not worth saving). The default value is 1 (i.e.,
be paranoid about detecting and aborting all operations). You
should not normally need to set this to 0, but it may be
useful when trying to salvage data from a corrupted repository.

GIT_ALLOW_PROTOCOL

If set to a colon-separated list of protocols, behave as if
protocol.allow is set to never, and each of the listed
protocols has protocol.<name>.allow set to always
(overriding any existing configuration). See the description of
protocol.allow in git-config[1] for more details.

GIT_PROTOCOL_FROM_USER

Set this Boolean environment variable to false to prevent protocols used by fetch/push/clone which are
configured to the user state. This is useful to restrict recursive
submodule initialization from an untrusted repository or for programs
which feed potentially-untrusted URLS to git commands. See
git-config[1] for more details.

GIT_PROTOCOL

For internal use only. Used in handshaking the wire protocol.
Contains a colon : separated list of keys with optional values
key[=value]. Presence of unknown keys and values must be
ignored.

Note that servers may need to be configured to allow this variable to
pass over some transports. It will be propagated automatically when
accessing local repositories (i.e., file:// or a filesystem path), as
well as over the git:// protocol. For git-over-http, it should work
automatically in most configurations, but see the discussion in
git-http-backend[1]. For git-over-ssh, the ssh server may need
to be configured to allow clients to pass this variable (e.g., by using
AcceptEnv GIT_PROTOCOL with OpenSSH).

This configuration is optional. If the variable is not propagated, then
clients will fall back to the original «v0» protocol (but may miss out
on some performance improvements or features). This variable currently
only affects clones and fetches; it is not yet used for pushes (but may
be in the future).

GIT_OPTIONAL_LOCKS

If this Boolean environment variable is set to false, Git will complete any requested operation without
performing any optional sub-operations that require taking a lock.
For example, this will prevent git status from refreshing the
index as a side effect. This is useful for processes running in
the background which do not want to cause lock contention with
other operations on the repository. Defaults to 1.

GIT_REDIRECT_STDIN

GIT_REDIRECT_STDOUT

GIT_REDIRECT_STDERR

Windows-only: allow redirecting the standard input/output/error
handles to paths specified by the environment variables. This is
particularly useful in multi-threaded applications where the
canonical way to pass standard handles via CreateProcess() is
not an option because it would require the handles to be marked
inheritable (and consequently every spawned process would
inherit them, possibly blocking regular Git operations). The
primary intended use case is to use named pipes for communication
(e.g. \.pipemy-git-stdin-123).

Two special values are supported: off will simply close the
corresponding standard handle, and if GIT_REDIRECT_STDERR is
2>&1, standard error will be redirected to the same handle as
standard output.

GIT_PRINT_SHA1_ELLIPSIS (deprecated)

If set to yes, print an ellipsis following an
(abbreviated) SHA-1 value. This affects indications of
detached HEADs (git-checkout[1]) and the raw
diff output (git-diff[1]). Printing an
ellipsis in the cases mentioned is no longer considered
adequate and support for it is likely to be removed in the
foreseeable future (along with the variable).