gitfaq

Следует указать свое имя, обычно в форме, состоящей из имени и фамилии. Например, действующий сопровождающий Git использует имя «Junio C Hamano». Эта часть имени будет сохраняться в каждом создаваемом вами коммите.

Эта настройка не влияет на аутентификацию при подключении к удаленным службам; сведения об этом см. в credential.username в git-config[1].

Этот параметр изменяет размер буфера, который Git использует при отправке данных на удаленный сервер по HTTP или HTTPS. Если объем данных превышает этот размер, libcurl, обеспечивающая поддержку HTTP в Git, использует кодирование передачи с разбиением на фрагменты, поскольку заранее неизвестен размер отправляемых данных.

Можно оставить значение по умолчанию, если только вам не известно, что удаленный сервер или прокси-сервер на пути передачи не поддерживает HTTP/1.1 (в котором появилось кодирование передачи с разбиением на фрагменты) или некорректно работает с такими данными. Этот параметр часто (ошибочно) рекомендуют в качестве решения общих проблем с отправкой, но, поскольку почти все серверы и прокси-серверы поддерживают как минимум HTTP/1.1, увеличение этого значения обычно не решает большинство проблем с отправкой. Сервер или прокси-сервер, который не поддерживает HTTP/1.1 и кодирование передачи с разбиением на фрагменты, сегодня был бы мало полезен в Интернете, поскольку нарушал бы работу большого объема трафика.

Обратите внимание, что увеличение этого значения увеличит объем памяти, используемый при каждой соответствующей отправке данных через HTTP или HTTPS: весь буфер выделяется независимо от того, используется ли он целиком. Поэтому лучше оставить значение по умолчанию, если вы не уверены, что вам необходимо другое значение.

Если вы не указали редактор специально для Git, по умолчанию будет использоваться редактор, настроенный с помощью переменных среды VISUAL или EDITOR, а если не указана ни одна из них — системный редактор (обычно vi). Некоторым пользователям сложно работать с vi или они предпочитают другой редактор, поэтому может возникнуть необходимость изменить используемый редактор.

Если вы хотите настроить редактор по умолчанию для большинства программ, которым он нужен, можно изменить конфигурацию оболочки (например, ~/.bashrc или ~/.zshenv), добавив строку, которая задает переменной среды EDITOR или VISUAL подходящее значение. Например, если вы предпочитаете редактор nano, можно добавить следующую строку:

export VISUAL=nano

Если вы хотите настроить редактор специально для Git, можно задать параметр конфигурации core.editor или переменную среды GIT_EDITOR. Сведения о порядке проверки этих параметров см. в git-var[1].

Обратите внимание, что во всех случаях значение редактора будет передано оболочке, поэтому аргументы, содержащие пробелы, следует заключать в кавычки. Кроме того, если обычно редактор при запуске отключается от терминала, укажите аргумент, который запретит ему это делать, иначе Git не увидит внесенные изменения. Пример настройки для Windows, учитывающей обе эти особенности: "C:\Program Files\Vim\gvim.exe" --nofork. В ней имя файла с пробелами заключено в кавычки, а параметр --nofork предотвращает запуск процесса в фоновом режиме.

Git намеренно не предоставляет (и не будет предоставлять) такую переменную конфигурации, как commit.signoff, которая автоматически добавляла бы --signoff по умолчанию. Причина в том, чтобы сохранить юридическую и осознанную значимость подтверждения авторства. Если бы существовало больше автоматизированных и широко известных способов добавлять такие подтверждения, кому-либо было бы проще впоследствии утверждать, что строка «Signed-off-by» была добавлена по привычке или автоматически, без полного понимания коммиттером и без его намерения подтвердить согласие с Сертификатом происхождения разработчика (DCO) или аналогичным заявлением. Это могло бы подорвать юридическую или договорную значимость такого подтверждения.

Параметр format.signoff существует, но это историческая ошибка, и она не оправдывает добавление новых ошибок того же рода.

Проще всего использовать вспомогательную программу для учетных данных, настроив параметр credential.helper. Большинство систем предлагают стандартный способ интеграции с системным диспетчером учетных данных. Например, Git для Windows предоставляет диспетчер учетных данных wincred, в macOS есть диспетчер учетных данных osxkeychain, а в Unix-системах со стандартной средой рабочего стола можно использовать диспетчер учетных данных libsecret. Все они хранят учетные данные в зашифрованном хранилище, защищая пароли и токены.

Кроме того, можно использовать диспетчер учетных данных store, который хранит их в файле в домашнем каталоге, или диспетчер cache, который не сохраняет учетные данные постоянно, но позволяет не вводить их повторно в течение определенного времени.

Можно также просто вводить пароль по запросу. Хотя пароль (который необходимо кодировать в формате percent-encoding) можно поместить в URL, это не особенно безопасно и может привести к случайному раскрытию учетных данных, поэтому такой способ не рекомендуется.

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

Такую команду оболочки можно задать, начав значение параметра с восклицательного знака. Если пароль или токен хранится в переменной среды GIT_TOKEN, для настройки вспомогательной программы учетных данных можно выполнить следующую команду:

$ git config credential.helper \
        '!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'

Обычно, если пароль или токен недействителен, Git удаляет его и запрашивает новый. Однако иногда это происходит не всегда. Чтобы изменить пароль или токен, можно удалить существующие учетные данные, после чего Git запросит новые. Чтобы удалить учетные данные, используйте команду следующего вида (подставив свое имя пользователя и имя узла):

$ echo url=https://author@git.example.org | git credential reject

Обычно проще всего различать эти учетные записи, указывая имя пользователя в URL. Например, если у вас есть учетные записи author и committer на git.example.org, можно использовать URL https://author@git.example.org/org1/project1.git и https://committer@git.example.org/org2/project2.git. Тогда при использовании вспомогательной программы для учетных данных она автоматически попытается найти нужные учетные данные. Если для удаленного репозитория уже задан адрес, его можно изменить командой вроде git remote set-url origin https://author@git.example.org/org1/project1.git (подробности см. в git-remote[1]).

У большинства хостинг-провайдеров, поддерживающих SSH, одна пара ключей однозначно идентифицирует пользователя. Поэтому для работы с несколькими учетными записями необходимо создать отдельную пару ключей для каждой из них. Если вы используете достаточно современную версию OpenSSH, новую пару ключей можно создать командой вроде ssh-keygen -t ed25519 -f ~/.ssh/id_committer. Затем можно зарегистрировать открытый ключ (в данном случае ~/.ssh/id_committer.pub; обратите внимание на .pub) у хостинг-провайдера.

Большинство хостинг-провайдеров используют одну учетную запись SSH для отправки данных; то есть все пользователи отправляют данные от имени учетной записи git (например, git@git.example.org). Если ваш провайдер работает именно так, можно настроить в SSH несколько псевдонимов, чтобы явно указать, какую пару ключей использовать. Например, можно добавить в файл ~/.ssh/config следующую запись, подставив нужный файл закрытого ключа:

# This is the account for author on git.example.org.
Host example_author
        HostName git.example.org
        User git
        # This is the key pair registered for author with git.example.org.
        IdentityFile ~/.ssh/id_author
        IdentitiesOnly yes
# This is the account for committer on git.example.org.
Host example_committer
        HostName git.example.org
        User git
        # This is the key pair registered for committer with git.example.org.
        IdentityFile ~/.ssh/id_committer
        IdentitiesOnly yes

Затем можно изменить URL для отправки, указав git@example_author или git@example_committer вместо git@example.org (например, git remote set-url git@example_author:org1/project1.git).

Сначала решите, действительно ли вам это нужно. Git лучше всего работает, когда вы отправляете или получаете изменения с помощью стандартных команд git push и git fetch; он не предназначен для совместного использования рабочего дерева между системами. Это потенциально рискованно и в некоторых случаях может привести к повреждению репозитория или потере данных.

Обычно в результате git status приходится заново считывать каждый файл рабочего дерева. Кроме того, модель безопасности Git не допускает совместного использования рабочего дерева недоверенными пользователями, поэтому синхронизировать его безопасно только в том случае, если на всех компьютерах им пользуется один и тот же пользователь.

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

Пример возможного повреждения — конфликт состояний ссылок, при котором в итоге обе стороны имеют разные коммиты в ветке, отсутствующие у другой стороны. Это может привести к тому, что важные объекты останутся без ссылок и, возможно, будут удалены командой git gc, что вызовет потерю данных.

Поэтому лучше отправлять изменения в другую систему или на центральный сервер с помощью обычного механизма отправки и получения. В Git 2.51 появилась возможность импортировать и экспортировать stash-записи, поэтому состояние рабочего дерева можно синхронизировать, сохранив изменения в stash командой git stash, а затем экспортировав все stash-записи командой git stash export --to-ref refs/heads/stashes (если вы хотите экспортировать их в ветку stashes) либо выбрав нужные записи, добавив их номера в конец этой команды. Также можно включить неотслеживаемые файлы, указав аргумент --include-untracked при сохранении изменений в stash, но будьте осторожны и не делайте этого, если какие-либо из этих файлов содержат конфиденциальную информацию.

Затем можно отправить ветку stashes (или другую ветку, в которую был выполнен экспорт), получить ее в локальную систему (например, с помощью git fetch origin +stashes:stashes) и импортировать stash-записи в другой системе командой git stash import stashes (при необходимости изменив имя). Применить изменения к рабочему дереву можно с помощью git stash pop или git stash apply. Этот подход наиболее надежен и с наибольшей вероятностью позволяет избежать непредвиденных проблем.

Тем не менее бывают случаи, когда пользователи предпочитают совместно использовать рабочее дерево между системами. Если вы решите так поступить, рекомендуется использовать rsync -a --delete-after (желательно через зашифрованное соединение, например ssh) в корневом каталоге репозитория. При этом убедитесь в следующем:

Внесите нужные изменения в рабочее дерево, выполните git add <file> или git rm <file>, в зависимости от ситуации, чтобы добавить изменения в индекс, а затем выполните git commit --amend. Ваши изменения будут включены в коммит, и вам будет предложено снова отредактировать сообщение коммита. Если вы хотите дословно использовать исходное сообщение, можно дополнительно указать параметр --no-edit для команды git commit или просто сохранить сообщение и закрыть редактор.

Обычно для этого используют команду git revert. Она сохраняет в истории сведения о том, что исходное изменение было внесено и являлось ценным вкладом, но также создает новый коммит, отменяющий это изменение из-за проблемы в исходном варианте. В сообщении коммита, отменяющего изменение, указывается отмененный коммит; обычно сообщение редактируют, добавляя объяснение причины отмены.

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

Может возникнуть соблазн использовать для этого некоторые возможности git update-index, а именно биты assume-unchanged и skip-worktree, но они не подходят для этой цели и не должны использоваться таким образом.

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

Файл gitignore гарантирует, что определенные файлы, которые не отслеживаются Git, останутся неотслеживаемыми. Однако некоторые файлы могли отслеживаться еще до добавления в .gitignore, поэтому они по-прежнему отслеживаются. Чтобы прекратить отслеживание файлов или шаблонов и игнорировать их, используйте команду git rm --cached <file/pattern> и добавьте в .gitignore шаблон, соответствующий файлу <file>. Подробности см. в gitignore[5].

Команда fetch сохраняет копию последних изменений из удаленного репозитория, не изменяя рабочее дерево или текущую ветку. После этого вы можете в удобное время изучить изменения из вышестоящего репозитория, выполнить слияние или перебазирование поверх них либо проигнорировать их. Команда pull выполняет fetch, за которым сразу следует слияние или перебазирование. См. git-pull[1].

Да, Git поддерживает использование прокси-серверов. Git учитывает стандартные переменные среды http_proxy, https_proxy и no_proxy, обычно используемые в Unix, а для HTTPS его также можно настроить с помощью http.proxy и подобных параметров (см. git-config[1]). Параметр http.proxy и связанные с ним параметры можно настраивать отдельно для шаблонов URL. Кроме того, Git в теории может нормально работать с прозрачными прокси-серверами в сети.

Для SSH Git поддерживает прокси-серверы с помощью параметра ProxyCommand OpenSSH. Среди часто используемых инструментов — netcat и socat. Однако их необходимо настроить так, чтобы они не завершали работу при получении EOF в стандартном потоке ввода. Обычно это означает, что для netcat потребуется параметр -q, а для socat потребуется указать тайм-аут, например -t 10. Это необходимо, потому что SSH-сервер Git понимает, что новых запросов не будет, по EOF в стандартном потоке ввода, но к этому моменту сервер может еще не обработать последний запрос. Поэтому разрыв соединения в этот момент прервет выполнение запроса.

Пример записи конфигурации в ~/.ssh/config для HTTP-прокси может выглядеть так:

Host git.example.org
    User git
    ProxyCommand socat -t 10 - PROXY:proxy.example.org:%h:%p,proxyport=8080

Обратите внимание, что для корректной работы Git прокси-сервер во всех случаях должен быть полностью прозрачным. Он не должен изменять соединение, вмешиваться в него или буферизовать его каким-либо образом, иначе Git почти наверняка не будет работать. Многие прокси-серверы, в том числе многие посредники TLS, антивирусные программы и брандмауэры Windows, кроме Защитника Windows и Брандмауэра Windows, а также прокси-серверы с фильтрацией не соответствуют этому требованию и в результате нарушают работу Git. Учитывая многочисленные сообщения о проблемах и неудовлетворительную историю безопасности, мы не рекомендуем использовать эти классы программ и устройств.

В целом при многократном слиянии двух веток с помощью squash-слияний могут возникнуть различные проблемы. Например, в выводе git log, графическом интерфейсе или при использовании обозначения диапазона ... могут отображаться лишние коммиты; также может потребоваться снова и снова разрешать конфликты.

При обычном слиянии двух веток Git учитывает ровно три точки: две ветки и третий коммит, называемый merge base, который обычно является общим предком коммитов. Результат слияния представляет собой совокупность изменений между базой слияния и каждой из вершин веток. Если выполнить обычное слияние двух веток с созданием коммита слияния, новый коммит станет базой слияния при следующем слиянии, поскольку появится новый общий предок. Git не придется учитывать изменения, внесенные до базы слияния, поэтому повторно разрешать конфликты, уже разрешенные ранее, не потребуется.

При выполнении squash-слияния коммит слияния не создается; вместо этого изменения одной стороны применяются к другой стороне как обычный коммит. Это означает, что база слияния для этих веток не изменится, и при следующем слиянии Git учтет все изменения, которые учитывались в прошлый раз, а также новые изменения. Поэтому конфликты, возможно, придется разрешать повторно. Аналогично, при использовании обозначения ... в git diff, git log или графическом интерфейсе будут показаны все изменения со времени исходной базы слияния.

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

По умолчанию при слиянии Git использует стратегию ort, выполняющую сложное трехстороннее слияние. В этом случае Git учитывает ровно три точки: две вершины веток и третью точку, называемую merge base, которая обычно является общим предком этих коммитов. Git совсем не учитывает историю или отдельные коммиты, появившиеся в этих ветках.

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

Если это создает проблему, можно выполнить перебазирование ветки с отменой поверх другой ветки. В этом случае перебазирование отменит изменение, поскольку применяет каждый отдельный коммит, включая отменяющий. Обратите внимание, что перебазирование переписывает историю, поэтому не следует перебазировать опубликованные ветки, если вы не уверены, что готовы к этому. Дополнительные сведения см. в разделе ПРИМЕЧАНИЯ в git-rebase[1].

Единственное безопасное место для применения таких ограничений — удаленный репозиторий (то есть сервер Git), обычно с помощью перехватчика pre-receive или системы непрерывной интеграции (CI). Именно в этих местах можно эффективно применять правила.

Часто для проверки таких условий пытаются использовать перехватчики pre-commit (или, для сообщений коммитов, перехватчики commit-msg). Это хорошо подходит для индивидуальной разработки, когда вы хотите, чтобы инструменты помогали вам. Однако использование перехватчиков на компьютере разработчика не позволяет эффективно контролировать соблюдение правил: пользователь может обойти их с помощью --no-verify, и это останется незамеченным (а также существует множество других способов). Git исходит из того, что пользователь контролирует свои локальные репозитории, и не пытается этому препятствовать или сообщать о действиях пользователя.

Кроме того, некоторые опытные пользователи считают, что перехватчики pre-commit мешают рабочим процессам, в которых временные коммиты используются для промежуточного сохранения незавершенной работы или создаются исправляющие коммиты. Поэтому такие проверки в любом случае лучше перенести на сервер.

Git лучше всего работает, когда текстовые файлы хранятся в кодировке UTF-8. Многие программы для Windows поддерживают UTF-8, но некоторые — нет и используют только формат UTF-16 с порядком байтов от младшего к старшему, который Git определяет как двоичный. Если ваши программы не поддерживают UTF-8, можно указать кодировку рабочей копии: она определит, в какой кодировке следует извлекать файлы, при этом в репозитории они будут по-прежнему храниться в UTF-8. Это позволит таким инструментам, как git-diff[1], работать как обычно, а вашим программам — продолжать работать.

Для этого можно задать шаблон gitattributes[5] с атрибутом working-tree-encoding. Например, следующий шаблон задаёт для всех файлов C кодировку UTF-16LE-BOM, распространённую в Windows:

*.c        working-tree-encoding=UTF-16LE-BOM

Чтобы изменения вступили в силу, потребуется выполнить git add --renormalize. Обратите внимание: если вы вносите эти изменения в проект, который используется на разных платформах, вероятно, лучше задать их в пользовательском файле конфигурации или в файле $GIT_DIR/info/attributes, поскольку указание их в файле .gitattributes в репозитории затронет всех пользователей этого репозитория.

Информацию о нормализации окончаний строк см. в следующем разделе, а дополнительные сведения о файлах атрибутов — в gitattributes[5].

По умолчанию Git предполагает, что файлы хранятся с окончаниями строк Unix. Поэтому возврат каретки (^M), являющийся частью окончания строки Windows, отображается, поскольку считается пробелом в конце строки. По умолчанию Git показывает пробелы в конце строки только в новых строках, но не в существующих.

Можно хранить файлы в репозитории с окончаниями строк Unix и автоматически преобразовывать их в окончания строк вашей платформы. Для этого задайте параметру конфигурации core.eol значение native и ознакомьтесь с разделом о рекомендуемых параметрах хранения, чтобы узнать, как указать, что файлы являются текстовыми или двоичными.

Управлять этим поведением также можно с помощью параметра core.whitespace, если вы не хотите удалять возвраты каретки из окончаний строк.

Внутри Git всегда хранит имена файлов как последовательности байтов и не выполняет преобразование кодировки или приведение регистра. Однако Windows и macOS по умолчанию не различают регистр в именах файлов. В результате могут появиться несколько файлов или каталогов, имена которых отличаются только регистром. Git без проблем работает с такими именами, но файловая система может хранить только один из этих файлов. Поэтому, когда Git считывает другой файл, чтобы проверить его содержимое, он выглядит изменённым.

Лучше удалить один из файлов, чтобы остался только один. Это можно сделать следующими командами (предполагается, что есть два файла AFile.txt и afile.txt), если рабочая копия не содержит других изменений:

$ git rm --cached AFile.txt
$ git commit -m 'Remove files conflicting in case'
$ git checkout .

Это позволяет не обращаться к диску, но удаляет лишний файл. Чтобы избежать повторения этой проблемы, в проекте можно принять соглашение об именовании, например использовать только строчные буквы; соблюдение такого соглашения можно проверять с помощью хука pre-receive или в рамках системы непрерывной интеграции (CI).

Файлы могут постоянно помечаться как изменённые на любой платформе, если в системе используется фильтр smudge или clean, но файл был ранее зафиксирован без применения этого фильтра. Чтобы исправить ситуацию, выполните следующую команду, если рабочая копия не содержит других изменений:

$ git add --renormalize .

Git может хранить файлы любых типов и работать с ними, однако некоторые настройки предпочтительнее других. В целом мы рекомендуем хранить текстовые файлы в UTF-8 без метки порядка байтов (BOM) и с окончаниями строк LF (в стиле Unix). Мы также рекомендуем использовать UTF-8 (также без BOM) в сообщениях коммитов. Такие настройки лучше всего подходят для разных платформ и инструментов, например git diff и git merge.

Кроме того, если можно выбрать между текстовым и нетекстовым форматом хранения, мы рекомендуем хранить файлы в текстовом формате и при необходимости преобразовывать их в другой формат. Например, текстовый дамп SQL с одной записью на строку значительно лучше подходит для сравнения и слияния, чем файл базы данных. Аналогично, текстовые форматы, такие как Markdown и AsciiDoc, предпочтительнее двоичных форматов, таких как Microsoft Word и PDF.

Как правило, не рекомендуется хранить в репозитории двоичные зависимости (например, разделяемые библиотеки или JAR-файлы) и результаты сборки. Зависимости и результаты сборки лучше хранить на сервере артефактов или пакетов, а в репозитории — только ссылки, URL-адреса и хеши.

Мы также рекомендуем создать файл gitattributes[5], явно указывающий, какие файлы являются текстовыми, а какие — двоичными. Если вы хотите, чтобы Git определял это автоматически, можно задать атрибут text=auto.

Для текстовых файлов Git обычно обеспечивает использование окончаний LF в репозитории. Переменные конфигурации core.autocrlf и core.eol определяют, какие окончания строк используются при извлечении текстовых файлов. Также можно использовать атрибут eol (например, eol=crlf), чтобы переопределить обработку окончаний строк для отдельных файлов.

Например, для файлов оболочки обычно требуются окончания LF, а для пакетных файлов — CRLF, поэтому в некоторых проектах может подойти следующее:

# By default, guess.
*        text=auto
# Mark all C files as text.
*.c        text
# Ensure all shell files have LF endings and all batch files have CRLF
# endings in the working tree and both have LF in the repo.
*.sh text eol=lf
*.bat text eol=crlf
# Mark all JPEG files as binary.
*.jpg        binary

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