Git как найти папку

All of the results I find say that the local repository is in a folder called «.git», and that this folder can be found within the working directory folder.
However, I have no such folder. I’ve done a search and apparently there is no .git folder on my entire PC.

Context:
I have been using the git CLI on my Windows 10 laptop to manage a repository that is stored on Github. To push my changes, I always do the following:

git add .
git commit -m "lorem ipsum"
git push origin master

This seems to be working, as I see my work on Github, and I have been able to revert local changes using

git reset --hard

Any suggestions are greatly appreciated.

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_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).