8.1 Настройка Git — Конфигурация Git
До этого момента мы описывали основы того, как Git работает и как его использовать, а так же мы познакомились с некоторыми инструментами Git, которые делают его использование простым и эффективным. В этой главе мы рассмотрим некоторые настройки Git и систему хуков, что позволяет настроить поведение Git. Таким образом, вы сможете заставить Git работать именно так как нужно вам или вашей компании.
Конфигурация Git
В главе Введение кратко упоминалось, что вы можете настроить Git, используя команду git config . Первое, что вы делали, это установили своё имя и e-mail адрес:
$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.comСейчас вы познакомитесь с несколькими наиболее интересными опциями, которые можно установить для настройки поведения Git.
Кратко: Git использует набор конфигурационных файлов для изменения стандартного поведения, если это необходимо. Вначале, Git ищет настройки в файле /etc/gitconfig , который содержит настройки для всех пользователей в системе и всех репозиториев. Если передать опцию —system команде git config , то операции чтения и записи будут производиться именно с этим файлом.
Следующее место, куда смотрит Git — это файл ~/.gitconfig (или ~/.config/git/config ), который хранит настройки конкретного пользователя. Вы можете указать Git читать и писать в него, используя опцию —global .
Наконец, Git ищет параметры конфигурации в файле настроек в каталоге Git ( .git/config ) текущего репозитория. Эти значения относятся только к текущему репозиторию и доступны при передаче параметра —local команде git config . (Если уровень настроек не указан явно, то подразумевается локальный.)
Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из .git/config важнее значений из /etc/gitconfig .
Примечание
Конфигурация Git это обычные текстовые файлы, поэтому можно вручную установить необходимые значения используя соответствующий синтаксис. Как правило, это проще чем вызывать команду git config для каждого параметра.
Базовая конфигурация клиента
Конфигурационные параметры Git разделяются на две категории: настройки клиента и настройки сервера. Большая часть — клиентские, для настройки ваших личных предпочтений в работе. Существует много, очень много настроек, но подавляющее большинство из них применимо только в конкретных случаях; мы рассмотрим только самые основные и самые полезные из них. Для просмотра полного списка настроек, поддерживаемых вашей версией Git, выполните команду:
$ man git-configЭта команда выведет список доступных настроек с довольно подробным описанием. Так же, соответствующую документацию можно найти здесь https://git-scm.com/docs/git-config.html.
core.editor
По умолчанию, Git использует ваш редактор по умолчанию ( $VISUAL или $EDITOR ), если значение не задано — переходит к использованию редактора vi при создании и редактировании сообщений коммитов или тегов. Чтобы изменить редактор по умолчанию, воспользуйтесь настройкой core.editor :
$ git config --global core.editor emacsТеперь, вне зависимости от того, какой редактор является основным для вашего окружения, Git будет вызывать Emacs для редактирования сообщений.
commit.template
Если указать путь к существующему файлу, то он будет использован как сообщение по умолчанию при создании коммита. Смысл создания шаблона сообщения коммита в том, чтобы лишний раз напомнить себе (или другим) о требованиях к формату или стилю оформления сообщения коммита.
Например, предположим что вы создали файл ~/.gitmessage.txt , который выглядит так:
Subject line (try to keep under 50 characters) Multi-line description of commit, feel free to be detailed. [Ticket: X]Обратите внимание, что шаблон напоминает коммитеру о том, чтобы строка заголовка сообщения была короткой (для поддержки однострочного вывода команды git log —oneline ), что дополнительную информацию в сообщении следует располагать ниже, а так же о том, что было бы неплохо при наличии добавить ссылку на номер задачи или сообщения в системе отслеживания ошибок.
Чтобы заставить Git отображать содержимое этого файла в редакторе каждый раз при выполнении команды git commit , следует установить значение параметра commit.template :
$ git config --global commit.template ~/.gitmessage.txt $ git commitТеперь, при создании коммита, в вашем редакторе будет отображаться сообщение изменённого вида:
Subject line (try to keep under 50 characters) Multi-line description of commit, feel free to be detailed. [Ticket: X] # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD . " to unstage) # # modified: lib/test.rb # ~ ~ ".git/COMMIT_EDITMSG" 14L, 297CЕсли ваша команда придерживается требований к сообщениям коммитов, то создание шаблона такого сообщения и настройка Git на его использование увеличит вероятность соответствия заданным требованиям.
core.pager
Данная настройка определяет какая программа будет использована для разбиения текста на страницы при выводе такой информации как log и diff . Вы можете указать more или любую другую (по умолчанию используется less ), а так же выключить совсем, установив пустое значение:
$ git config --global core.pager ''В таком случае, Git будет выводить весь текст полностью, вне зависимости от его длины.
user.signingkey
Если вы создаёте подписанные аннотированные теги (как описано в разделе Подпись главы 7), то установка GPG ключа в настройках облегчит вам задачу. Установить ключ можно следующим образом:
$ git config --global user.signingkey
Теперь, вам не нужно указывать ключ для подписи каждый раз при вызове команды git tag :
$ git tag -s
core.excludesfile
В разделе Игнорирование файлов главы 2 сказано, что вы можете указывать шаблоны исключений в файле .gitignore вашего проекта, чтобы Git не отслеживал их и не добавлял в индекс при выполнении команды git add .
Однако, иногда вам нужно игнорировать определённые файлы во всех ваших репозиториях. Если на вашем компьютере работает Mac OS X, вероятно вы знакомы с файлами .DS_Store . Если вы используете Emacs или Vim, то вы знаете про файлы, имена которых заканчиваются на ~ или .swp .
Данная настройка позволяет вам определить что-то вроде глобального файла .gitignore . Если вы создадите файл ~/.gitignore_global с содержанием:
*~ .*.swp .DS_Store… и выполните команду git config —global core.excludesfile ~/.gitignore_global , то Git больше не потревожит вас на счёт этих файлов.
help.autocorrect
Если вы ошибётесь в написании команды, Git покажет вам что-то вроде этого:
$ git chekcout master git: 'chekcout' is not a git command. See 'git --help'. The most similar command is checkoutGit старается угадать, что вы имели ввиду, но при этом команду не выполняет. Если вы установите help.autocorrect в значение 1, то Git будет выполнять эту команду:
$ git chekcout master WARNING: You called a Git command named 'chekcout', which does not exist. Continuing under the assumption that you meant 'checkout' in 0.1 seconds automatically. Обратите внимание, что команда выполнилась через «0.1» секунды. help.autocorrect — это число, указываемое в десятых долях секунды. Поэтому, если вы установите значение 50, то Git даст вам 5 секунд изменить своё решение перед тем, как выполнить скорректированную команду.
Цвета в Git
Git полностью поддерживает цветовой вывод в терминале, что позволяет быстро и легко визуально анализировать вывод команд. Существует несколько опций для настройки цветов.
color.ui
Git автоматически подсвечивает большую часть своего вывода, но это можно отключить, если вам не нравится такое поведение. Для отключения цветового вывода в терминал, выполните следующую команду:
$ git config --global color.ui falseЗначение по умолчанию — auto , при котором цвета используются при непосредственном выводе в терминал, но исключаются при перенаправлении вывода в именованный канал или файл.
Вы так же можете установить значение always , что делает вывод одинаковым как в терминал, так и в именованный канал. Скорее всего, вам это не понадобится; в большинстве случаев, при желании использовать цвета в перенаправленном выводе, указывается флаг —color команде Git для принудительного использования цветовых кодов. Практически всегда стандартное значение подходит лучше всего.
color.*
Если вы хотите явно указать вывод каких команд должен быть подсвечен и как, Git предоставляет соответствующие настройки. Каждая из них может быть установлена в значения true , false или always :
color.branch color.diff color.interactive color.status
Каждая из них имеет вложенную конфигурацию, которую можно использовать для настройки отдельных частей вывода при желании переопределить их цвет. Например, чтобы установить для метаинформации вывода команды diff синий цвет, чёрный фон и полужирный шрифт, выполните команду:
$ git config --global color.diff.meta "blue black bold"Для установки цвета доступны следующие значения: normal , black , red , green , yellow , blue , magenta , cyan , или white . Для указания атрибутов текста, как bold в предыдущем примере, доступны значения: bold , dim , ul (подчёркнутый), blink и reverse (поменять местами цвет фона и цвет текста).
Внешние программы слияния и сравнения
Хоть в Git и есть встроенная программа сравнения, которая описывается в этой книге, вы можете установить вместо неё другую. Вы также можете настроить графический инструмент разрешения конфликтов слияния вместо того, чтобы разрешать конфликты вручную. Мы покажем как настроить Perforce Visual Merge Tool (P4Merge) для разрешения конфликтов слияния, так как это прекрасный и бесплатный инструмент.
Если у вас есть желание попробовать P4Merge, то она работает на всех основных платформах, так что у вас должно получиться. В примерах мы будем использовать пути к файлам, которые работают в системах Linux и Mac; для Windows вам следует изменить /usr/local/bin на путь к исполняемому файлу у вас в системе.
Для начала скачайте P4Merge. Затем, создайте скрипты обёртки для вызова внешних программ. Мы будем использовать путь к исполняемому файлу в системе Mac; в других системах — это путь к файлу p4merge . Создайте скрипт с названием extMerge для вызова программы слияния и передачи ей заданных параметров:
$ cat /usr/local/bin/extMerge #!/bin/sh /Applications/p4merge.app/Contents/MacOS/p4merge $*Скрипт вызова программы сравнения проверяет наличие 7 аргументов и передаёт 2 из них в скрипт вызова программы слияния. По умолчанию, Git передаёт следующие аргументы программе сравнения:
path old-file old-hex old-mode new-file new-hex new-modeТак как вам нужны только old-file и new-file , следует использовать скрипт, который передаст только необходимые параметры.
$ cat /usr/local/bin/extDiff #!/bin/sh [ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"Так же следует убедиться, что созданные скрипты могут исполняться:
$ sudo chmod +x /usr/local/bin/extMerge $ sudo chmod +x /usr/local/bin/extDiffТеперь можно изменить файл конфигурации для использования ваших инструментов слияния и сравнения. Для этого необходимо изменить ряд настроек: merge.tool — чтобы сказать Git какую стратегию использовать, mergetool..cmd — чтобы сказать Git как запускать команду, mergetool..trustExitCode — чтобы сказать Git как интерпретировать код выхода из программы, diff.external — чтобы сказать Git какую команду использовать для сравнения. Таким образом, команду конфигурации нужно запустить четыре раза:
$ git config --global merge.tool extMerge $ git config --global mergetool.extMerge.cmd \ 'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"' $ git config --global mergetool.extMerge.trustExitCode false $ git config --global diff.external extDiffили вручную отредактировать файл ~/.gitconfig добавив соответствующие строки:
[merge] tool = extMerge [mergetool "extMerge"] cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED" trustExitCode = false [diff] external = extDiffПосле этого, вы можете запускать команды diff следующим образом:
$ git diff 32d1776b1^ 32d1776b1Вместо отображения вывода diff в терминале Git запустит P4Merge, выглядеть это будет примерно так:
Рисунок 142. P4Merge
Если при слиянии двух веток у вас возникнут конфликты, выполните команду git mergetool ; она запустит P4Merge чтобы вы могли разрешить конфликты используя графический интерфейс.
Используя скрипт обёртку для вызова внешних программ, вы можете легко изменить вызываемую программу. Например, чтобы начать использовать KDiff3 вместо P4Merge, достаточно изменить файл extMerge :
$ cat /usr/local/bin/extMerge #!/bin/sh /Applications/kdiff3.app/Contents/MacOS/kdiff3 $*Теперь, Git будет использовать программу KDiff3 для сравнения файлов и разрешения конфликтов слияния.
Git изначально настроен на использование ряда других инструментов для разрешения конфликтов слияния, поэтому вам не нужно дополнительно что-то настраивать. Для просмотра списка поддерживаемых инструментов, выполните команду:
$ git mergetool --tool-help 'git mergetool --tool=' may be set to one of the following: emerge gvimdiff gvimdiff2 opendiff p4merge vimdiff vimdiff2 The following tools are valid, but not currently available: araxis bc3 codecompare deltawalker diffmerge diffuse ecmerge kdiff3 meld tkdiff tortoisemerge xxdiff Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail.Если вы хотите использовать KDiff3 только для разрешения конфликтов слияния, но не для сравнения, выполните команду:
$ git config --global merge.tool kdiff3Если выполнить эту команду вместо настройки использования файлов extMerge и extDiff , то Git будет использовать KDiff3 для разрешения конфликтов слияния, а для сравнения — стандартную программу diff.
Форматирование и пробелы
Проблемы форматирования и пробелов являются одними из самых неприятных и незаметных проблем, с которыми сталкивают разработчики при совместной работе, особенно используя разные платформы. Это легко может произойти с патчами или с любой другой совместной работой, так как редакторы молча исправляют несоответствия, и если ваши файлы когда либо касаются систем Windows, то переносы строк могут быть заменены. В Git есть несколько настроек, чтобы справиться с этими проблемами.
core.autocrlf
Если вы программируете в Windows и работаете с людьми, которые не используют её (или наоборот), рано или поздно, вы столкнётесь с проблемами переноса строк. Это происходит потому, что Windows при создании файлов использует для обозначения переноса строки два символа «возврат каретки» и «перевод строки», в то время как Mac и Linux используют только один — «перевод строки». Это незначительный, но невероятно раздражающий факт кроссплатформенной работы; большинство редакторов в Windows молча заменяют переносы строк вида LF на CRLF или вставляют оба символа, когда пользователь нажимает клавишу ввод.
Git может автоматически конвертировать переносы строк CRLF в LF при добавлении файла в индекс и наоборот — при извлечении кода. Такое поведение можно включить используя настройку core.autocrlf . Если у вас Windows, то установите значение true — при извлечении кода LF окончания строк будут преобразовываться в CRLF:
$ git config --global core.autocrlf trueЕсли у вас система Linux или Mac, то вам не нужно автоматически конвертировать переносы строк при извлечении файлов; однако, если файл с CRLF окончаниями строк случайно попал в репозиторий, то Git может его исправить. Можно указать Git конвертировать CRLF в LF во время коммита, но не наоборот, установив настройке core.autocrlf значение input :
$ git config --global core.autocrlf inputТакая конфигурация позволит вам использовать CRLF переносы строк в Windows, при этом в репозитории и системах Mac и Linux будет использован LF.
Если вы используете Windows и программируете только для Windows, то вы можете отключить описанный функционал задав значение false , сохраняя при этом CR символы в репозитории:
$ git config --global core.autocrlf falsecore.whitespace
Git поставляется настроенным на обнаружение и исправление некоторых проблем с пробелами. Он в состоянии найти шесть основных проблем, обнаружение трёх из них включено по умолчанию, а трёх других — выключено.
Те, что включены по умолчанию — это blank-at-eol , что ищет пробелы в конце строки; blank-at-eof , что ищет пробелы в конце файла; и space-before-tab , что ищет пробелы перед символом табуляции в начале строки.
Те, что выключены по умолчанию — это indent-with-non-tab , что ищет строки с пробелами вначале вместо символа табуляции (и контролируется настройкой tabwidth ); tab-in-indent , что ищет символы табуляции в отступах в начале строки; и cr-at-eol , которая указывает Git на валидность наличия CR в конце строки.
Указав через запятую значения для настройки core.whitespace , можно сказать Git какие из этих опций должны быть включены. Чтобы отключить ненужные проверки, достаточно удалить их из строки значений или поставить знак — перед каждой из них. Например, чтобы включить все проверки, кроме space-before-tab , выполните команду (при этом trailing-space является сокращением и охватывает как blank-at-eol , так и blank-at-eof ):
$ git config --global core.whitespace \ trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eolИли можно указать только часть проверок:
$ git config --global core.whitespace \ -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eolGit будет искать указанные проблемы при выполнении команды git diff и пытаться подсветить их, чтобы вы могли исправить их перед коммитом. Так же эти значения будут использоваться во время применения патчей командой git apply . При применении патчей, можно явно указать Git информировать вас в случае нахождения проблем с пробелами:
$ git apply --whitespace=warn
Так же можно указать Git автоматически исправлять эти проблемы перед применением патча:
$ git apply --whitespace=fix
Эти настройки так же применяются при выполнении команды git rebase . Если проблемные пробелы попали в коммит, но ещё не отправлены в удалённую ветку, можно выполнить git rebase —whitespace=fix для автоматического исправления этих проблем.
Конфигурация сервера
Для серверной части Git не так много настроек, но есть несколько интересных, на которые стоит обратить внимание.
receive.fsckObjects
Git способен убедиться, что каждый объект, отправленный командой push , валиден и соответствует своему SHA-1-хешу. По умолчанию эта функция отключена; это очень дорогая операция и может привести к существенному замедлению, особенно для больших объёмов отправляемых данных или для больших репозиториев. Вы можете включить проверку целостности объектов для каждой операции отправки, установив значение receive.fsckObjects в true :
$ git config --system receive.fsckObjects trueТеперь, Git будет проверять целостность репозитория до принятия новых данных для уверенности, что неисправные или злонамеренные клиенты не смогут отправить повреждённые данные.
receive.denyNonFastForwards
Если вы перебазируете коммиты, которые уже отправлены, и попытаетесь отправить их снова или попытаетесь отправить коммит в удалённую ветку, в которой не содержится коммит, на который она указывает, то данные приняты не будут. В принципе, это правильная политика; но в случае перебазирования — вы знаете, что делаете и можете принудительно обновить удалённую ветку используя флаг -f для команды push .
Для запрета перезаписи истории установите receive.denyNonFastForwards :
$ git config --system receive.denyNonFastForwards trueСделать то же самое можно другим способом — используя хук на стороне сервера, мы рассмотрим его немного позже. Этот подход позволяет более гибко настроить ограничения, например, запретить перезапись истории определённой группе пользователей.
receive.denyDeletes
Политику denyNonFastForwards можно обойти, удалив ветку и создав новую с таким же именем. Для предотвращения этого, установите receive.denyDeletes в значение true :
$ git config --system receive.denyDeletes trueЭта команда запретит удаление веток и тегов всем пользователям. Чтобы удалить ветку, придётся удалить все соответствующие ей файлы на сервере вручную. Куда более интересный способ — это настроить права пользователей, с ним вы познакомитесь в разделе Пример принудительной политики Git.
Как выйти из гитхаба?
Сел за другой пк, авторизовался в гитбаше, запушил изменения, а выйти собственно как?
Ввел git config —list , показал мой user.email и user.name, а как выйти? Получается человек на этом пк может дальше манипулировать моим репозиторием?
- Вопрос задан 16 февр.
- 466 просмотров
Комментировать
Решения вопроса 1
Сергей Кузнецов @sergey-kuznetsov Куратор тега Git
Автоматизатор
Параметры вашей подписи коммитов user.name и user.email вообще никакого отношения к авторизации не имеют. А сама она не хранится в конфиге гита и к самому гиту никакого отношения не имеет. Вы же не имя и мыло вводили когда авторизовались? В гите вообще нет понятия авторизации. Вы авторизуете на внешнем сервере не гит, а пользователя компьютера. За хранение паролей отвечает credential manager, а сами пароли хранятся в недрах операционной системы, независимо от гита и хорошо спрятаны.
«Забыть» авторизацию текущего пользователя можно такой командой.
echo "url=https://github.com" | git credential rejectТакже можно очистить вашу подпись для текущего пользователя компьютера
git config --unset user.name git config --unset user.emailКак выйти из git log?
Написал в git git log Мне вывело несколько моих коммитов, и потом при нажатиии enter выходит ещё коммит, и так пока коммиты не закончатся. И даже после этого я не могу написать в гите другую команду, висит end. Приходится перезапускать git bash. Как выйти из лога коммитов?
Отслеживать
задан 19 фев 2016 в 21:05
jokelocker jokelocker
609 1 1 золотой знак 6 6 серебряных знаков 16 16 бронзовых знаков
19 фев 2016 в 21:10
5 ответов 5
Сортировка: Сброс на вариант по умолчанию
По-умолчанию Git посылает вывод своих комманд на программу-pager. По-умолчанию это программа less. Выйти из less можно пятью способами: q , Q , : q , : Q и Z Z .
Отслеживать
ответ дан 20 фев 2016 в 3:20
11.6k 24 24 серебряных знака 38 38 бронзовых знаков
Примечание: не забудьте переключить раскладку! Русское Й не сработает как надо!
30 янв 2022 в 11:58
как и отовсюду комбинацией клавиш (это linux) CTRL + Z
На виндовом клиенте не работает , поэтому что бы прекратить скрол нажмите q
Отслеживать
ответ дан 19 фев 2016 в 21:09
1,658 10 10 серебряных знаков 15 15 бронзовых знаков
CTRL + Z не выходит из программы, a приостанавливает программу и посылает ее в фон (вернуть ее обратно можно с помощью команды fg).
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Шпаргалка по консольным командам Git
cyberspacedk/Git-commands
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Switch branches/tags
Branches Tags
Could not load branches
Nothing to show
Could not load tags
Nothing to show
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Cancel Create
- Local
- Codespaces
HTTPS GitHub CLI
Use Git or checkout with SVN using the web URL.
Work fast with our official CLI. Learn more about the CLI.
Sign In Required
Please sign in to use Codespaces.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching Xcode
If nothing happens, download Xcode and try again.
Launching Visual Studio Code
Your codespace will open once ready.
There was a problem preparing your codespace, please try again.
Latest commit
e250e0a Mar 16, 2022
Git stats
Files
Failed to load latest commit information.
Latest commit message
Commit time
March 16, 2022 13:23
readme.md
Шпаргалка по консольным командам Git
Добавляйте свои команды и остальные полезности через Pull request .
Общее
Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс ( git add ), потом «сохраняем» ( git commit ).
Любой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).
Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).
Ключ к пониманию
Ключ к пониманию концепции git — знание о «трех деревьях»:
- Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
- Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
- Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).
Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.
У всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.
Простейший цикл работ
- Редактирование, добавление, удаление файлов (собственно, работа).
- Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
- Коммит (фиксация изменений).
- Возврат к шагу 1 или отход ко сну.
Указатели
- HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
- ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
- Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
- Теги — простые указатели на коммиты. Не перемещаются.
Настройки
Перед началом работы нужно выполнить некоторые настройки:
git config --global user.name "Your Name" # указать имя, которым будут подписаны коммиты git config --global user.email "e@w.com" # указать электропочту, которая будет в описании коммитера Если вы в Windows:
git config --global core.autocrlf true # включить преобразование окончаний строк из CRLF в LF Указание неотслеживаемых файлов
Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.
Консоль
Длинный вывод в консоли: Vim
Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .
Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w .
Vim (некоторые команды)
# Нажатия кнопок ESC — переход в командный режим i — переход в режим редактирования текста ZQ (зажат Shift, поочередное нажатие) — выход без сохранения ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти ```bash # Нажатия кнопок ESC — переход в командный режим i — переход в режим редактирования текста ZQ (зажат Shift, поочередное нажатие) — выход без сохранения ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти # Ввод в командном режиме :q! — выйти без сохранения :wq — сохранить файл и выйти :w filename.txt — сохранить файл как filename.txt
Консольные команды
Создать новый репозиторий
git init # создать новый проект в текущей директории git init folder-name # создать новый проект в указанной директории
Клонирование репозитория
# клонировать удаленный репозиторий в одноименную директорию git clone https://github.com/cyberspacedk/Git-commands.git # клонировать удаленный репозиторий в директорию «FolderName» git clone https://github.com/cyberspacedk/Git-commands.git FolderName # клонировать репозиторий в текущую директорию git clone https://github.com:nicothin/web-design.git .
Просмотр изменений
git status # показать состояние репозитория (отслеживаемые, изменённые, новые файлы и пр.) git diff # сравнить рабочую директорию и индекс (неотслеживаемые файлы ИГНОРИРУЮТСЯ) git diff --color-words # сравнить рабочую директорию и индекс, показать отличия в словах (неотслеживаемые файлы ИГНОРИРУЮТСЯ) git diff index.html # сравнить файл из рабочей директории и индекс git diff HEAD # сравнить рабочую директорию и коммит, на который указывает HEAD (неотслеживаемые файлы ИГНОРИРУЮТСЯ) git diff --staged # сравнить индекс и коммит с HEAD git diff master feature # посмотреть что сделано в ветке feature по сравнению с веткой master git diff --name-only master feature # посмотреть что сделано в ветке feature по сравнению с веткой master, показать только имена файлов git diff master. feature # посмотреть что сделано в ветке feature с момента (коммита) расхождения с master
Добавление изменений в индекс
git add . # добавить в индекс все новые, изменённые, удалённые файлы из текущей директории и её поддиректорий git add text.txt # добавить в индекс указанный файл (был изменён, был удалён или это новый файл) git add -i # запустить интерактивную оболочку для добавления в индекс только выбранных файлов git add -p # показать новые/изменённые файлы по очереди с указанием их изменений и вопросом об отслеживании/индексировании
Удаление изменений из индекса
git reset # убрать из индекса все добавленные в него изменения (в рабочей директории все изменения сохранятся), антипод git add git reset readme.txt # убрать из индекса изменения указанного файла (в рабочей директории изменения сохранятся)
Отмена изменений
git checkout text.txt # ОПАСНО: отменить изменения в файле, вернуть состояние файла, имеющееся в индексе git reset --hard # ОПАСНО: отменить изменения; вернуть то, что в коммите, на который указывает HEAD (незакомиченные изменения удалены из индекса и из рабочей директории, неотслеживаемые файлы останутся на месте) git clean -df # удалить неотслеживаемые файлы и директории
Коммиты
git commit -m "Name of commit" # зафиксировать в коммите проиндексированные изменения (закоммитить), добавить сообщение git commit -a -m "Name of commit" # проиндексировать отслеживаемые файлы (ТОЛЬКО отслеживаемые, но НЕ новые файлы) и закоммитить, добавить сообщение
Отмена коммитов и перемещение по истории
Все коммиты, которые уже были отправлены в удалённый репозиторий, должны отменяться новыми коммитами ( git revert ), дабы избежать проблем с историей разработки у других участников проекта.
git revert HEAD --no-edit # создать новый коммит, отменяющий изменения последнего коммита без запуска редактора сообщения git revert b9533bb --no-edit # то же, но отменяются изменения, внесённые коммитом с указанным хешем (b9533bb)
Все команды, приведённые ниже можно выполнять ТОЛЬКО если коммиты еще не были отправлены в удалённый репозиторий.
# ВНИМАНИЕ! Опасные команды, можно потерять незакоммиченные изменения git commit --amend -m "Название" # «перекоммитить» изменения последнего коммита, заменить его новым коммитом с другим сообщением (сдвинуть текущую ветку на один коммит назад, сохранив рабочую директорию и индекс «как есть», создать новый коммит с данными из «отменяемого» коммита, но новым сообщением) git reset --hard @~ # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию и индекс сделать такими, какими они были в момент предыдущего коммита git reset --hard 75e2d51 # передвинуть HEAD (и ветку) на коммит с указанным хешем, рабочую директорию и индекс сделать такими, какими они были в момент указанного коммита git reset --soft @~ # передвинуть HEAD (и ветку) на предыдущий коммит, но в рабочей директории и индексе оставить все изменения git reset --soft @~2 # то же, но передвинуть HEAD (и ветку) на 2 коммита назад git reset @~ # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию оставить как есть, индекс сделать таким, каким он был в момент предыдущего коммита (удобнее, чем git reset --soft @~, если индекс нужно задать заново) # Почти как git reset --hard, но безопаснее: не получится потерять изменения в рабочей директории git reset --keep @~ # передвинуть HEAD (и ветку) на предыдущий коммит, сбросить индекс, но в рабочей директории оставить изменения, если возможно (если файл с изменениями между коммитами менялся, будет выдана ошибка и переключение не произойдёт)
Временно переключиться на другой коммит
git checkout b9533bb # переключиться на коммит с указанным хешем (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита) git checkout master # переключиться на коммит, на который указывает master (переместить HEAD на коммит, на который указывает master, рабочую директорию вернуть к состоянию на момент этого коммита)
Переключиться на другой коммит и продолжить работу с него
Потребуется создание новой ветки, начинающейся с указанного коммита.
git checkout -b new-branch 5589877 # создать ветку new-branch, начинающуюся с коммита c хешем 5589877 (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита, создать указатель на этот коммит (ветку) с указанным именем)
Восстановление изменений
git checkout 5589877 index.html # восстановить в рабочей директории указанный файл на момент указанного коммита (и добавить это изменение в индекс) (git reset index.html для удаления из индекса, но сохранения изменений в файле)
Копирование коммита (перенос коммитов)
git cherry-pick 5589877 # скопировать на активную ветку изменения из указанного коммита, закоммитить эти изменения git cherry-pick master~2..master # скопировать на активную ветку изменения из master (2 последних коммита) git cherry-pick -n 5589877 # скопировать на активную ветку изменения из указанного коммита, но НЕ КОММИТИТЬ (подразумевается, что мы сами потом закоммитим) git cherry-pick master..feature # скопировать на активную ветку изменения из всех коммитов ветки feature с момента её расхождения с master (похоже на слияние веток, но это копирование изменений, а не слияние), закоммитить эти изменения; это может вызвать конфликт git cherry-pick --abort # прервать конфликтный перенос коммитов git cherry-pick --continue # продолжить конфликтный перенос коммитов (сработает только после решения конфликта)
Удаление файла
git rm text.txt # удалить отслеживаемый неизменённый файл и проиндексировать это изменение git rm -f text.txt # удалить отслеживаемый изменённый файл и проиндексировать это изменение git rm -r log/ # удалить всё содержимое отслеживаемой директории log/ и проиндексировать это изменение git rm ind* # удалить все отслеживаемые файлы с именем, начинающимся на «ind» в текущей директории и проиндексировать это изменение git rm --cached readme.txt # удалить из отслеживаемых индексированный файл (ФАЙЛ ОСТАНЕТСЯ НА МЕСТЕ) (часто используется для нечаянно добавленных в отслеживаемые файлов)
Перемещение/переименование файлов
Для git не существует переименования. Переименование воспринимается как удаление старого файла и создание нового. Факт переименования может быть определен только после индексации изменения.
git mv text.txt test_new.txt # переименовать файл «text.txt» в «test_new.txt» и проиндексировать это изменение git mv readme_new.md folder/ # переместить файл readme_new.md в директорию folder/ (должна существовать) и проиндексировать это изменение
История коммитов
Выход из длинного лога вывода: q .
git log master # показать коммиты в указанной ветке git log -2 # показать последние 2 коммита в активной ветке git log -2 --stat # показать последние 2 коммита и статистику внесенных ими изменений git log -p -22 # показать последние 22 коммита и внесенную ими разницу на уровне строк git log --graph -10 # показать последние 10 коммитов с ASCII-представлением ветвления git log --since=2.weeks # показать коммиты за последние 2 недели git log --after '2018-06-30' # показать коммиты, сделанные после указанной даты git log index.html # показать историю изменений файла index.html (только коммиты) git log -5 index.html # показать историю изменений файла index.html, последние 5 коммитов (только коммиты) git log -p index.html # показать историю изменений файла index.html (коммиты и изменения) git log -G'myFunction' -p # показать все коммиты, в которых менялись строки с myFunction (в кавычках регулярное выражение) git log -L '//','//':index.html # показать изменения от указанного до указанного регулярных выражений в указанном файле git log --grep fix # показать коммиты, в описании которых есть буквосочетание fix (регистрозависимо, только коммиты текущей ветки) git log --grep fix -i # показать коммиты, в описании которых есть буквосочетание fix (регистроНЕзависимо, только коммиты текущей ветки) git log --grep 'fix(ing|me)' -P # показать коммиты, в описании которых есть совпадения для регулярного выражения (только коммиты текущей ветки) git log --pretty=format:"%h - %an, %ar : %s" -4 # показать последние 4 коммита с форматированием выводимых данных git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short # мой формат вывода, висящий на алиасе оболочки git log master..branch_99 # показать коммиты из ветки branch_99, которые не влиты в master git log branch_99..master # показать коммиты из ветки master, которые не влиты в branch_99 git log master. branch_99 --boundary -- graph # показать коммиты из указанных веток, начиная с их расхождения (коммит расхождения будет показан)
git show 60d6582 # показать изменения из коммита с указанным хешем git show HEAD~ # показать данные о предыдущем коммите в активной ветке git show @~ # аналогично предыдущему git show HEAD~3 # показать данные о коммите, который был 3 коммита назад git show my_branch~2 # показать данные о коммите, который был 2 коммита назад в указанной ветке git show @~:index.html # показать контент указанного файла на момент предыдущего (от HEAD) коммита git show :/"подвал" # показать самый новый коммит, в описании которого есть указанное слово (из любой ветки)
Кто написал строку
git blame README.md --date=short -L 5,8 # показать строки 5-8 указанного файла и коммиты, в которых строки были добавлены
История изменений указателей (веток, HEAD)
git reflog -20 # показать последние 20 изменений положения указателя HEAD git reflog --format='%C(auto)%h %<|(20)%gd %C(blue)%cr%C(reset) %gs (%s)' -20 # то же, но с указанием давности действий Ветки
git branch # показать список веток git branch -v # показать список веток и последний коммит в каждой git branch new_branch # создать новую ветку с указанным именем на текущем коммите git branch new_branch 5589877 # создать новую ветку с указанным именем на указанном коммите git branch -f master 5589877 # переместить ветку master на указанный коммит git branch -f master master~2 # переместить ветку master на 2 коммита назад git checkout new_branch # перейти в указанную ветку git checkout -b new_branch # создать новую ветку с указанным именем и перейти в неё git checkout -B master 5589877 # переместить ветку с указанным именем на указанный коммит и перейти в неё git merge hotfix # влить в ветку, в которой находимся, данные из ветки hotfix git merge hotfix -m "Горячая правка" # влить в ветку, в которой находимся, данные из ветки hotfix (указано сообщение коммита слияния) git merge hotfix --log # влить в ветку, в которой находимся, данные из ветки hotfix, показать редактор описания коммита, добавить в него сообщения вливаемых коммитов git merge hotfix --no-ff # влить в ветку, в которой находимся, данные из ветки hotfix, запретить простой сдвиг указателя, изменения из hotfix «останутся» в ней, а в активной ветке появится только коммит слияния git branch -d hotfix # удалить ветку hotfix (используется, если её изменения уже влиты в главную ветку) git branch --merged # показать ветки, уже слитые с активной git branch --no-merged # показать ветки, не слитые с активной git branch -a # показать все имеющиеся ветки (в т.ч. на удаленных репозиториях) git branch -m old_branch_name new_branch_name # переименовать локально ветку old_branch_name в new_branch_name git branch -m new_branch_name # переименовать локально ТЕКУЩУЮ ветку в new_branch_name git push origin :old_branch_name new_branch_name # применить переименование в удаленном репозитории git branch --unset-upstream # завершить процесс переименования
Теги
git tag v1.0.0 # создать тег с указанным именем на коммите, на который указывает HEAD git tag -a -m 'В продакшен!' v1.0.1 master # создать тег с описанием на том коммите, на который смотрит ветка master git tag -d v1.0.0 # удалить тег с указанным именем(ами) git tag -n # показать все теги, и по 1 строке сообщения коммитов, на которые они указывают git tag -n -l 'v1.*' # показать все теги, которые начинаются с 'v1.*'
Временное сохранение изменений без коммита
git stash # временно сохранить незакоммиченные изменения и убрать их из рабочей директории git stash pop # вернуть сохраненные командой git stash изменения в рабочую директорию
Удалённые репозитории
Есть два распространённых способа привязать удалённый репозиторий к локальному: по HTTPS и по SSH. Если SSH у вас не настроен (или вы не знаете что это), привязывайте удалённый репозиторий по HTTPS (адрес привязываемого репозитория должен начинаться с https://).
git remote -v # показать список удалённых репозиториев, связанных с локальным git branch -r # показать удаленные ветки git branch -a # показать все ветки(локальные и удаленные) git remote remove origin # убрать привязку удалённого репозитория с сокр. именем origin git remote add origin https://github.com:nicothin/test.git # добавить удалённый репозиторий (с сокр. именем origin) с указанным URL git remote rm origin # удалить привязку удалённого репозитория git remote show origin # получить данные об удалённом репозитории с сокращенным именем origin git fetch origin # скачать все ветки с удаленного репозитория (с сокр. именем origin), но не сливать со своими ветками git fetch origin master # то же, но скачивается только указанная ветка git checkout --track origin/github_branch # создать локальную ветку github_branch (данные взять из удалённого репозитория с сокр. именем origin, ветка github_branch) и переключиться на неё git push origin master # отправить в удалённый репозиторий (с сокр. именем origin) данные своей ветки master git pull origin # влить изменения с удалённого репозитория (все ветки) git pull origin master # влить изменения с удалённого репозитория (только указанная ветка)
Конфликт слияния
Предполагается ситуация: есть ветка master и есть ветка feature . В обеих ветках есть коммиты, сделанные после расхождения веток. В ветку master пытаемся влить ветку feature ( git merge feature ), получаем конфликт, т.к. в обеих ветках есть изменения одной и той же строки в файле index.html .
При возникновении конфликта, репозиторий находится в состоянии прерванного слияния. Нужно оставить в конфликтующих местах файлов только нужный код, проиндексировать изменения и закоммитить.
git merge feature # влить в активную ветку изменения из ветки feature git merge-base master feature # показать хеш последнего общего коммита для двух указанных веток git checkout --ours index.html # оставить в конфликтном файле (index.html) состояние ветки, В КОТОРУЮ мы вливаем (в примере — из ветки master) git checkout --theirs index.html # оставить в конфликтном файле (index.html) состояние ветки, ИЗ КОТОРОЙ мы вливаем (в примере — из ветки feature) git checkout --merge index.html # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток (для ручного редактирования) git checkout --conflict=diff3 --merge index.html # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток плюс то, что было в месте конфликта в коммите, на котором разошлись сливаемые ветки
git reset --hard # прекратить это прерванное слияние, вернуть рабочую директорию и индекс как было в момент коммита, на который указывает HEAD, а я пойду немного поплачу git reset --merge # прекратить это прерванное слияние, но оставить изменения, не закоммиченные до слияния (для случая, когда слияние делается не на чистом статусе) git reset --abort # то же, что и строкой выше
«Перенос» ветки
Можно «переместить» ответвление какой-либо ветки от основной на произвольный коммит. Это нужно для того, чтобы в «переносимой» ветке появились какие-либо изменения, внесённые в основной ветке (уже после ответвления переносимой).
Нельзя «переносить» ветку, если она уже отправлена на удалённый репозиторий.
git rebase master # перенести все коммиты (создать их копии) активной ветки так, будто активная ветка ответвилась от master на нынешней вершине master (часто вызывает конфликты) git rebase --onto master feature # перенести коммиты активной ветки на master, начиная с того места, в котором активная ветка отделилась от ветки feature git rebase --abort # прервать конфликтный rebase, вернуть рабочую директорию и индекс к состоянию до начала rebase git rebase --continue # продолжить конфликтный rebase (сработает только после разрешения конфликта и индексации такого разрешения)
Как отменить rebase
git reflog feature -2 # смотрим лог перемещений ветки, которой делали rebase (в этом примере — feature), видим последний коммит ПЕРЕД rebase, на него и нужно перенести указатель ветки git reset --hard feature@ # переместить указатель ветки feature на один коммит назад, обновить рабочую директорию и индекс
Разное
git archive -o ./project.zip HEAD # создать архив с файловой структурой проекта по указанному пути (состояние репозитория, соответствующее указателю HEAD)
Примеры
Собираем коллекцию простых и сложных примеров работы.
Начало работы
Создание нового репозитория, первый коммит, привязка удалённого репозитория с gthub.com, отправка изменений в удалённый репозиторий.
# указана последовательность действий: # создана директория проекта, мы в ней git init # создаём репозиторий в этой директории touch readme.md # создаем файл readme.md git add readme.md # добавляем файл в индекс git commit -m "Старт" # создаем коммит git remote add origin https://github.com:nicothin/test.git # добавляем предварительно созданный пустой удаленный репозиторий git push -u origin master # отправляем данные из локального репозитория в удаленный (в ветку master)
«Внесение изменений» в коммит
Только если коммит ещё не был отправлен в удалённые репозиторий.
# указана последовательность действий: subl inc/header.html # редактируем и сохраняем разметку «шапки» git add inc/header.html # индексируем измененный файл git commit -m "Убрал телефон из шапки" # делаем коммит # ВНИМАНИЕ: коммит пока не был отправлен в удалённый репозиторий # сознаём, что нужно было еще что-то сделать в этом коммите. subl inc/header.html # вносим изменения git add inc/header.html # индексируем измененный файл (можно git add .) git commit --amend -m "«Шапка»: выполнена задача №34" # заново делаем коммит
Работа с ветками
Есть master (публичная версия сайта), выполняем масштабную задачу (переверстать «шапку»), но по ходу работ возникает необходимость подправить критичный баг (неправильно указан контакт в «подвале»).
# указана последовательность действий: git checkout -b new-page-header # создадим новую ветку для задачи изменения «шапки» и перейдём в неё subl inc/header.html # редактируем разметку «шапки» git commit -a -m "Новая шапка: смена логотипа" # делаем коммит (работа еще не завершена) # тут выясняется, что есть баг с контактом в «подвале» git checkout master # возвращаемся к ветке master subl inc/footer.html # устраняем баг и сохраняем разметку «подвала» git commit -a -m "Исправление контакта в подвале" # делаем коммит git push # отправляем коммит с быстрым критическим изменением в master в удалённом репозитории git checkout new-page-header # переключаемся обратно в ветку new-page-header для продолжения работ над «шапкой» subl inc/header.html # редактируем и сохраняем разметку «шапки» git commit -a -m "Новая шапка: смена навигации" # делаем коммит (работа над «шапкой» завершена) git checkout master # переключаемся в ветку master git merge new-page-header # вливаем в master изменения из ветки new-page-header git branch -d new-page-header # удаляем ветку new_page_header
Работа с ветками, слияние и откат к состоянию до слияния
Была ветка fix , в которой исправляли баг. Исправили, влили fix в master . но тут выяснилось, что это исправление ломает какую-то функциональность, Нужно откатить master к состоянию без слияния (наличие бага менее критично, чем порча функциональности).
# находимся в ветке fix, баг уже «исправлен» git checkout master # переключаемся на master git merge fix # вливаем изменения из fix в master # видим проблему: часть функциональности сломалась git checkout fix # переключаемся на fix (пока мы в master, git не даст ее двигать) git branch -f master ORIG_HEAD # передвигаем ветку master на коммит, указанный в ORIG_HEAD (тот, на который указывала master до вливания fix)
Работа с ветками, конфликт слияния
Есть ветка master (публичная версия сайта), в двух параллельных ветках ( branch-1 и branch-2 ) было отредактировано одно и то же место одного и того же файла, первую ветку ( branch-1 ) влили в master, попытка влить вторую вызывает конфликт.
# указана последовательность действий: git checkout master # переключаемся на ветку master git checkout -b branch-1 # создаём ветку branch-1, основанную на ветке master subl . # редактируем и сохраняем файлы git commit -a -m "Правка 1" # коммитим git checkout master # возвращаемся к ветке master git checkout -b branch-2 # создаём ветку branch-2, основанную на ветке master subl . # редактируем и сохраняем файлы git commit -a -m "Правка 2" # коммитим git checkout master # возвращаемся к ветке master git merge branch-1 # вливаем изменения из ветки branch-1 в текущую ветку (master), удача (автослияние) git merge branch-2 # вливаем изменения из ветки branch-2 в текущую ветку (master), КОНФЛИКТ автослияния # Automatic merge failed; fix conflicts and then commit the result. subl . # выбираем в конфликтных файлах те участки, которые нужно оставить, сохраняем git commit -a -m "Устранение конфликта" # коммитим результат устранения конфликта
Синхронизация репозитория-форка с мастер-репозиторием
Есть некий репозиторий на github.com, он него нами был сделан форк, добавлены какие-то изменения. Оригинальный (мастер-)репозиторий был как-то обновлён. Задача: стянуть с мастер-репозитория изменения (которые там внесены уже после того, как мы его форкнули).
# указана последовательность действий: git remote add upstream https://github.com:address.git # добавляем удаленный репозиторий: сокр. имя — upstream, URL мастер-репозитория git fetch upstream # стягиваем все ветки мастер-репозитория, но пока не сливаем со своими git checkout master # переключаемся на ветку master своего репозитория git merge upstream/master # вливаем стянутую ветку master удалённого репозитория upstream в свою ветку master
Ошибка в работе: закоммитили в мастер, но поняли, что нужно было коммитить в новую ветку
ВАЖНО: это сработает только если коммит еще не отправлен в удалённый репозиторий.
# указана последовательность действий: # сделали изменения, проиндексировали их, закоммитили в master, но ЕЩЁ НЕ ОТПРАВИЛИ (не делали git push) git checkout -b new-branch # создаём новую ветку из master git checkout master # переключаемся на master git reset HEAD~ --hard # сдвигаем указатель (ветку) master на 1 коммит назад git checkout new-branch # переключаемся обратно на новую ветку для продолжения работы
Нужно вернуть содержимое файла к состоянию, бывшему в каком-либо коммите (известен хеш коммита)
# указана последовательность действий: git checkout f26ed88 -- index.html # восстановить в рабочей директории состояние указанного файла на момент указанного коммита, добавить это изменение в индекс git commit -am "Navigation fixs" # сделать коммит
При любом действии с github (или другим удалённым сервисом) запрашивается логин и пароль
Речь именно о запросе пары логин + пароль, а не ключевой фразы. Происходит это потому, что git по умолчанию не сохранит пароль для доступа к репозиторию по HTTPS.
.gitattributes
* text=auto *.html diff=html *.css diff=css *.scss diff=css