Git не индексировать файл
Обновлено: 07.07.2024
В начале использования Git часто возникает вопрос: «Как заставить Git больше не отслеживать какой-либо файл или несколько файлов?» Чтобы удалить файлы из репозитория Git, можно воспользоваться командой git rm . Ее действие противоположно действию команды git add .
Обзор команды git rm
Команда git rm позволяет удалять отдельные файлы или группы файлов. Основное назначение git rm — удаление отслеживаемых файлов из раздела проиндексированных файлов Git. Кроме того, с помощью git rm можно удалить файлы одновременно из раздела проиндексированных файлов и рабочего каталога. Удалить с ее помощью файл только из рабочего каталога нельзя. Файлы, в отношении которых выполняется команда, должны быть идентичны файлам в текущем указателе HEAD . В случае расхождений между версией файла из указателя HEAD и версией из раздела проиндексированных файлов или рабочего дерева Git заблокирует удаление. Такая блокировка является механизмом безопасности, который предотвращает удаление изменений в процессе их внесения.
Обратите внимание, что git rm не удаляет ветки. Подробнее об использовании веток Git см. здесь.
Использование
Указывает файлы, подлежащие удалению. Можно указать один файл, несколько файлов через пробел ( file1 file2 file3 ) или шаблон подстановки (
Параметр -f применяется для отключения проверки безопасности, с помощью которой Git обеспечивает соответствие файлов в указателе HEAD текущему содержимому раздела проиндексированных файлов и рабочего каталога.
Параметр dry run является защитным механизмом. Он позволяет выполнить пробный запуск команды git rm без удаления файлов. В выходных данных отображаются файлы, которые должны были быть удалены.
Параметр -r — это сокращение от слова recursive. При выполнении команды git rm в рекурсивном режиме она удаляет не только каталог назначения, но и все содержимое его вложенных каталогов.
Параметр разделителя позволяет явным образом отличить список имен файлов от аргументов, передаваемых команде git rm . Разделитель полезен, когда какие-либо из файлов имеют имена, аналогичные параметрам команды.
Параметр cached указывает, что должны быть удалены только файлы, находящиеся в разделе проиндексированных файлов. Файлы в рабочем каталоге при этом остаются нетронутыми.
Этот параметр заставляет команду завершиться со статусом sigterm, равным 0, даже если файлы, указанные для удаления, не найдены. Sigterm — это код состояния в Unix. Код 0 указывает на успешный вызов команды. Параметр --ignore-unmatch может быть полезен, если команда git rm используется в составе скрипта оболочки, который должен обеспечивать корректную обработку отказа.
Параметр quiet скрывает вывод команды git rm . Как правило, команда выводит по одной строке на каждый удаленный файл.
Отмена изменений, внесенных командой git rm
Изменения, вносимые при выполнении команды git rm , не являются окончательными. Эта команда обновляет раздел проиндексированных файлов и рабочий каталог. Изменения не сохранятся, пока не будет создан новый коммит и они не будут добавлены в историю коммитов. Так что изменения, внесенные командой git rm, можно «отменить» с помощью стандартных команд Git.
Команда git reset восстановит раздел индексированных файлов и рабочий каталог до коммита HEAD . В результате изменения, внесенные командой git rm , будут отменены.
Такого же результата можно добиться с помощью команды git checkout: она восстановит последнюю версию файла из указателя HEAD .
Если после выполнения git rm был создан новый коммит, из-за которого удаление сохранилось, можно воспользоваться командой git reflog , чтобы найти ссылку, предшествующую выполнению git rm . Подробнее об использовании git reflog см. здесь.
Пояснения
Аргумент , переданный команде, может содержать точные пути, шаблоны поиска файлов или точные имена каталогов. При выполнении команды удаляются только пути, зафиксированные в репозитории Git посредством коммитов.
В шаблонах поиска файлов можно задавать имена каталогов. При использовании шаблонов поиска следует быть внимательным. Рассмотрим примеры: directory/* и directory* . Использование первого шаблона приведет к удалению всех файлов в каталоге directory/ , тогда как второй вызовет удаление всех каталогов, имя которых начинается на directory — например, directory1 , directory2 , directory_whatever и т. д., что может быть нежелательным.
Область действия команды git rm
Действие команды git rm распространяется только на текущую ветку. Удаление выполняется только в деревьях рабочего каталога и раздела проиндексированных файлов. Удаление файла не сохраняется в истории репозитория до тех пор, пока не создан новый коммит.
Почему следует использовать git rm, а не rm
Репозиторий Git обнаруживает выполнение стандартной команды оболочки rm для отслеживаемого им файла и соответствующим образом обновляет рабочий каталог. Но раздел проиндексированных файлов не обновляется. Чтобы внести в него изменения, для удаленных путей к файлам необходимо дополнительно выполнить команду git add . Команда git rm уменьшает количество действий, поскольку обновляет при удалении и рабочий каталог, и раздел проиндексированных файлов.
Примеры
В данном примере шаблон поиска файлов используется для удаления всех файлов *.txt в каталоге Documentation и всех его подкаталогах.
Обратите внимание, что символ звездочки * здесь экранируется символами косой черты. Это сделано, чтобы оболочка не расширяла шаблон. В таком варианте он включает только пути к файлам и подкаталогам, находящимся в каталоге Documentation/ .
В этом примере команда выполняется с параметром force для всех файлов, соответствующих шаблону подстановки git-*.sh . Параметр force явным образом удаляет целевые файлы из рабочего каталога и раздела проиндексированных файлов.
Удаление файлов, которых уже нет в файловой системе
В разделе «Почему следует использовать git rm , а не rm » говорилось о том, что команда git rm предусмотрена для удобства: она сочетает функции стандартной команды оболочки rm и команды git add , позволяя удалить файл из рабочего каталога и раздела проиндексированных файлов. Если удалить несколько файлов с помощью стандартной команды оболочки rm , состояние репозитория может стать проблематичным.
Если требуется записать все явным образом удаленные файлы в следующий коммит, можно выполнить команду git commit -a . Она внесет все события удаления в раздел проиндексированных файлов для подготовки к следующему коммиту.
Если же стоит задача безвозвратно удалить файлы, удаленные с помощью команды оболочки rm , нужно воспользоваться следующей командой:
Эта команда создаст список удаленных файлов из рабочего каталога и передаст его команде git rm --cached , которая обновит раздел проиндексированных файлов.
Команда git rm: заключение
Команда git rm выполняет действия над двумя главными деревьями управления внутренним состоянием Git: рабочим каталогом и разделом проиндексированных файлов. Команда git rm позволяет удалять файлы из репозитория Git. Это удобный инструмент, объединяющий функции стандартной команды оболочки rm и команды git add : сначала git rm удаляет целевой объект из файловой системы, а затем добавляет событие удаления в раздел проиндексированных файлов. Эта команда — одна из многих, которые можно использовать для отмены изменений в Git.
gitignore GIT
Всем доброго времени суток и мы продолжаем знакомство с контролем версий git.
Откроем консольное окно GIT Bash Here в папке с репозиторием.
И давайте сразу рассмотрим следующую команду.
c помощью этой команды мы можем определить все проиндексированные и неиндексированные файлы. Под индексированными файлами подразумевается что они были добавлены в наш git репозиторий с помощью команды git add (файлы) и не занесены в файл .gitignore про него мы поговорим далее. И неиндексированные, следовательно либо они содержаться в файле .gitignore, или мы их только добавили, удалили или изменили.
Все проиндексированные файлы и директории отображаются зеленым цветом, а неиндексированные красным.
Для примера давайте добавим в нашу папку с репозиторием новый файл или директорию, далее повторно выполним команду git status.
И мы увидим что данный файл или директория отображаются красным цветом так как не были проиндексированы версией контроля. Для индексации их необходимо добавить командой:
git add название файла или директории
после этой команды наш файл будет проиндексирован убедится в этом вы можете повторно выполнив команду git status. Такая же ситуация произойдет если мы внесем изменения в какой либо файл или удалим его из репозитория, здесь также придется зафиксировать изменение индексацией в системе контроля git.
Вывод команды git status можно привести к более читабельному виду добавить к ней флаг -s
A file1 - проиндексированный файл
AD file2 - файл который был удален
M file3 - файл в который были внесены изменения
?? file4 - неизвестный файл или неиндексированный.
Вот так вот с помощью команды git status мы можем определять состояния файлов.
Идем дальше, могут возникнуть ситуации когда нам нет необходимости учитывать или индексировать файл в системе контроля.
И для того чтобы этой файл или группа файлов не учитывались, существует специальный файл .gitignore в котором перечисляются все файлы которые не подлежат индексации в системе, то есть они в ней никак не учитываются.
Пример: давайте добавим новый файл в нашу папку репозитория и здесь же создадим файл .gitignore у этого файла как и у .htaccess имя не указывается.
В самом .gitignore необходимо указать какие файлы мы хотим чтобы не учитывались.Пример:
С помощью решетки мы указываем однострочный комментарий, это условные обозначения которые никак не влияют на результат.
Как видите здесь мы запретили индексацию файла file.php, всех файлов заканчивающихся на xml и директорию folder.
В принципе здесь ничего сложного нет, обычно в этом файле указываются различные стороние библиотеки, модули, компоненты и т. д., содержание которых мы как правило не трогаем.
И напоследок я хотел вам рассказать еще об одной команде которая можем вам быть крайне полезна. С помощью команды git status мы можем отследить только внешнее состояние файла. Но что если мы хотим посмотреть внесенные изменения внутри файла? Для этого существует команда git diff
если ваши файлы все проиндексированны, то данная команда ничего не вернет. Давайте внесем изменения в файлы репозитория. И попробуем выполнить данную команду повторно.
Нам вернулись все наши изменения в виде отображения - красным цветом обозначается старое состояние ,зеленым цветом новое.
Тут еще важно понимать что данная команда показывает только все изменения еще неиндексированных файлов.
Если вы выполните команду
то есть добавите(проиндексируете) все файлы тогда, команда git diff вернет вам уже пустой результат.
Если мы хотим просмотреть внесенные изменения уже проиндексированных файлам , нам нужно добавить флаг --cached
в итоге мы увидим все изменения уже в проиндексированных файлах.
Вот так мы можем отслеживать состояние файлов и их изменения.
На этом дорогие друзья данная статья подходит к концу. Надеюсь сегодня вы узнали что то новое.
Я желаю вам успехов и удачи! Пока!
Оцените статью:
Статьи
Комментарии
Внимание. Комментарий теперь перед публикацией проходит модерацию
Все комментарии отправлены на модерацию
Запись экрана
Данное расширение позволяет записывать экран и выводит видео в формате webm
Git поставляется вместе со скриптами, которые упрощают выполнение некоторых задач из командной строки. В этом разделе мы рассмотрим несколько интерактивных команд, которые могут упростить создание коммитов, позволяя включать в них только определённый набор файлов и их частей. Эти инструменты очень полезны, если вы изменили множество файлов, а затем решили, что хотите чтобы эти изменения были в нескольких маленьких понятных коммитах, а не в одном большом и запутанном. Таким способом вы сможете гарантировать, что ваши коммиты представляют логически разделённые изменения и могут быть легко прорецензированы вашими коллегами.
Если вы выполните git add с опцией -i или --interactive , Git перейдёт в интерактивный консольный режим, отобразив что-то подобное:
Вы можете видеть, что эта команда показывает вашу область подготовленных изменений в уникальном представлении — вообще говоря, ту же информацию вы получите с помощью команды git status , но несколько более сжато и информативно. Эта команда показывает проиндексированные изменения слева, а непроиндексированные — справа.
Затем следует раздел со списком команд. С их помощью вы можете выполнить множество вещей — добавить или исключить файлы из индекса, добавить в индекс части файлов, добавить в индекс неотслеживаемые файлы и просмотреть проиндексированные изменения.
Добавление и удаление файлов из индекса
Если вы введете 2 или u в поле ввода What now> , скрипт спросит у вас какие файлы вы хотите добавить в индекс:
Для добавления в индекс файлов TODO и index.html, вы можете ввести их номера:
Символ * у каждого из этих файлов означает, что файл выбран для индексирования. Если вы нажмёте Enter, не вводя ничего в поле ввода Update>> , Git добавит в индекс всё, чтобы было выбрано ранее:
Как вы можете заметить, сейчас файлы TODO и index.html добавлены в индекс, а файл simplegit.rb всё ещё нет. Если вы в этот момент хотите исключить файл TODO из индекса, вы можете использовать опции 3 или r (для выполнения revert):
Посмотрев снова на состояние вашего рабочего каталога Git, вы увидите, что файл TODO исключён из индекса:
Для того, чтобы посмотреть изменения, которые вы добавили в индекс, вы можете использовать команду 6 и d (для выполнения diff). Она покажет вам список добавленных в индекс файлов, и вы можете выбрать один из них, для которого вы хотите увидеть добавленные в индекс изменения. Это очень похоже на вывод команды git diff --cached :
Использование этих основных команд в интерактивном режиме команды add, может упростить вам работу с вашей областью подготовленных изменений.
Индексирование по частям
В Git существует возможность индексировать не только файлы целиком, но и некоторые их части. Например, если вы сделали в файле simplegit.rb два изменения и хотите добавить в индекс только одно из них, добиться этого в Git очень легко. В поле ввода в режиме интерактивного индексирования введите 5 или p (для выполнения patch). Git спросит у вас какие файлы вы хотите добавить в индекс частично; а затем для каждой части выбранных файлов он будет показывать изменения в ней и спрашивать хотите ли вы добавить в индекс эту часть:
В этой точке у вас есть множество вариантов дальнейших действий. Если вы введёте ? , Git отобразит, что именно вы можете сделать:
Обычно вы будете вводить y или n , если вы хотите индексировать каждую часть по отдельности, но индексация всех частей в некоторых файлах или откладывание решения по индексацию части также может быть полезным. Если вы добавили в индекс одну часть файла, но не добавили другую, состояние вашего рабочего каталога будет подобно приведённому далее:
Обратите внимание на состояние файла simplegit.rb. Оно говорит вам, что часть строк файла добавлена в индекс, а часть нет. Таким образом, вы частично проиндексировали этот файл. В данный момент вы можете выйти из интерактивного режима команды git add и выполнить git commit , чтобы зафиксировать частично проиндексированные файлы.
Также вам не обязательно находиться в интерактивном режиме индексирования файлов для выполнения частичной индексации файлов — вы также можете запустить её, используя команды git add -p или git add --patch .
Более того, вы можете использовать работу с отдельными частями файлов для частичного восстановления файлов с помощью команды reset --patch , для переключения частей файлов с помощью команды checkout --patch и для припрятывания частей файлов с помощью stash save --patch . Мы рассмотрим каждую из этих команд более подробно, когда будем изучать более продвинутые варианты их использования.
Если внести файл в .gitignore, то он не будет отслеживаться гитом лишь в том случае, если этого файла нет в удаленном репозитории.
Но если в репозитории уже есть (к примеру конфиги сайта), а мы не хотим, чтобы наши локальные конфиги отслеживались, то можно выполнить команду:
git update-index --assume-unchanged application/config/database.php
либо всю папку
git update-index --assume-unchanged application/config/*
Чтобы перестать игнорировать изменения, нужно использовать параметр --no-assume-unchanged.
git update-index --no-assume-unchanged application/config/*
Update: Если конфиг изменили
Если всё же кто-то изменил структуру файла конфига, то git не даст сделать pull, т.к. все-равно будет считать, что файл конфига с нашими паролями отличается от того, что прийдет с командой pull.
Чтобы все-таки получить новые изменения, но и свои пароли сохранить в конфиге нужно сделать следующее:
1. Сохранить текущие конфиги (с нашими локальными паролями) в отдельную папку например.
2. Отменить игнорирование изменений (параметр --no-assume-unchanged ).
git update-index --no-assume-unchanged application/config/database.php
3. На данном шаге команда git status покажет, что файл application/config/database.php был изменен, но еще не проиндексирован. Именно эти изменения и мешают нам забрать командой git pull новые изменения. Учитывая, что на шаге 1 мы сохранили наши конфиги в отдельную папку — мы можем сейчас отменить эти изменения.
git checkout application/config/database.php
4. Сейчас git status покажет, что изменений нет ( nothing to commit, working tree clean ). Забираем новые изменения:
git pull
5. Опционально: Если мы привыкли работать в отдельной ветке (не в master), то переходим в эту ветку (например: dev-branch) для последующей работы:
git checkout dev-branch
и вливаем в ветку dev-branch новые изменения из ветки master (куда мы их уже получили командой git pull ):
git merge master
6. Изменяем теперь наши обновленные конфиги, возвращая туда наши локальные пароли и все то, что мы желаем там видеть, но не хотим это хранить в репозитории (для этого мы сохранили все в шаге 1). После чего команда git status естественно покажет, что конфиги изменены, но не проиндексированы.
7. И только теперь мы можем снова включить игнорирование ( --assume-unchanged ):
git update-index --assume-unchanged application/config/database.php
После чего git status покажет, что все чисто ( nothing to commit, working tree clean ) и мы сможем снова работать, делать коммиты и переключаться между ветками.
git — очень мощный инструмент, который практически каждый разработчик задействует ежедневно. Но для большинства его использование сводится всего к нескольким командам: pull , commit и push . Чтобы быть эффективным, продуктивным и задействовать всю мощь git , нужно знать еще несколько команд и хитрых приемов. Рассмотрим простые в использовании и настройке, легко запоминающиеся функции git , которые делают работу, связанную с контролем версий, намного более приятной.
Улучшение базового рабочего процесса
Прежде чем использовать даже самые простые команды, такие как pull , commit и push , нужно выяснить, что происходит с ветками и измененными файлами. Для этого задействуем git log . Все о нем знают, но не все умеют делать его вывод действительно красивым и удобным для восприятия человека:
Такой граф дает неплохое общее представление о том, что происходит. Однако иногда бывает необходимо немного углубиться, например посмотреть историю/изменения конкретных файлов или даже отдельных функций. git log (с аргументом -L :<funcname>:<file> ) помогает и в этом:
Теперь, когда мы чуть лучшее представляем, что происходит в репозитории, проверим различия между обновленными файлами и последним коммитом. Для этого будем использовать git diff . Здесь, опять же, ничего нового, но у diff есть несколько параметров и флагов, о которых вы можете не знать. Например, с помощью git diff branch-a..branch-b сравниваются две ветки, а с помощью git diff <commit-a> <commit-b> -- <path(s)> — даже конкретные файлы в разных ветках.
Иногда вывод git diff становится довольно трудным для восприятия. Для решения этой проблемы пробуем использовать флаг -w , который игнорирует все пробелы, делая diff немного спамоподобным. Или же задействуем --word-diff --color-words , благодаря которому работа ведется со словами, а не с целыми строками.
Если нужно что-то получше базового статического вывода в оболочке, запускаем difftool с помощью git difftool=vimdiff , который откроет diff рядом в редакторе vim. Хотите другой редактор? Запустите git difftool --tool-help и выберите из списка пригодных для diff инструментов.
Мы видели, как просматривать историю конкретных частей/строк в файле с помощью git log . Столь же удобно просматривать историю и индексируемых частей файлов. Это довольно легко делается в IDE, например IntelliJ, правда с интерфейсом командной строки git не все так просто, но выручает git add --patch :
В результате открывается редактор, показывающий один фрагмент, т. е. часть кода с несколькими различающимися строками. Что делают с этим куском кода? Есть много вариантов, но наиболее важные из них y — принять изменения (индексировать кусок кода), n — не принять (не индексировать кусок кода) и e — отредактировать кусок кода прежде его индексирования (полный список вариантов доступен здесь).
После завершения интерактивного индексирования запускаем git status и видим, что частично индексированный файл находится и в разделе Changes to be committed: («Изменения, подлежащие фиксации»), и в Changes not staged for commit: («Изменения, не индексированные для коммита»). Запускаем также git add -i (интерактивное индексирование), а затем задействуем команду состояния s (status), которая покажет, какие строки индексированы, а какие — нет.
Устранение типичных ошибок
После индексирования файлов часто (даже слишком часто) понимаешь: добавлено то, что добавлять было не нужно. Но в git нет команды для разындексирования файла или файлов. Проблема решается возвращением репозитория в исходное состояние с помощью git reset --soft HEAD somefile.txt . Добавьте параметр -p после git reset , и вы получите UI, аналогичный тому, что показан с git add -p . Только не забудьте добавить здесь флаг --soft , иначе вы сотрете локальные изменения!
Применение (чуть меньшей) силы
Теперь, когда с индексированием покончили, остается сделать коммит и добавить его. Но что, если мы забыли что-то добавить или допустили ошибку и хотим внести исправления в уже добавленные коммиты? Есть простое решение: использовать git commit -a и git push --force . Но это очень опасно, если мы работаем с общей веткой, такой как master . Поэтому во избежание риска перезаписи чужой работы этим нашим force-push будем задействовать флаг --force-with-lease . В отличие от --force , этот флаг добавляет изменения только в том случае, если в ветку не внесено никаких других изменений. Если ветка изменена, добавление будет отклонено. То есть придется вытащить последние изменения, прежде чем добавлять что-то еще.
Как проводить слияния правильно
Если вы работаете в репозитории бок о бок с другими разработчиками, то наверняка все манипуляции производите в отдельной ветке, а не на master . Но рано или поздно приходится включать свой код в кодовую базу (в ветку master ). И часто случается так, что к этому времени кто-то другой уже успевает добавить туда собственный код. Так что ветка вашей функции остается на несколько коммитов позади, а вам остается только слить свой код в master с помощью git merge . Но в этом случае будет создан дополнительный merge commit , делающий историю излишне сложной и менее удобной для восприятия:
Гораздо лучше здесь было бы сначала переместить изменения из ветки функции в ветку master , а затем выполнить так называемое слияние с перемоткой вперед ( git merge --ff ). Благодаря этому поддерживается линейность истории, облегчающая ее чтение и последующий поиск коммитов, которые привели к появлению конкретной функции или бага.
Но как выполнить это самое перемещение изменений? Выполним в наиболее базовой его форме с помощью git rebase master feature/branch и с последующим force-push: этого обычно бывает достаточно. Чтобы задействовать git rebase по максимуму, включим также параметр -i , запустив сеанс интерактивного перемещения изменений — удобный инструмент, например для переписывания, объединения или вообще очистки коммитов и всей ветки. Попробуем даже переместить изменения ветки в ней самой:
Эта команда фактически позволяет повторно применить последние 4 коммита, внося в них изменения. Например, объединить одни и переписать другие:
В приведенном выше примере демонстрируется, как происходит сеанс перемещения. Наверху показано то, как выглядела ветка до перемещения. Во второй части фрагмента кода — список коммитов, представленных нам после запуска git rebase . , каждый из которых предваряется командой pick . Поменяем эту команду для трех из четырех коммитов и полностью изменим их очередность. В третьей части примера показаны новые команды: reword , которая дает git указание открыть редактор описания коммита; squash , которая объединяет коммит с предшествующим ему; и fixup , отличающаяся от squash тем, что после объединения отбрасывает описание коммита. Применив эти изменения и переписав измененные коммиты, получаем историю, показанную в нижней части примера.
Если во время перемещения возникает какой-то конфликт, то для его разрешения запускаем git mergetool --tool=vimdiff , после чего продолжаем перемещение с помощью git rebase --continue . Если вам еще не знаком git mergetool , не пугайтесь этого зверя. На самом деле он тот же, что и в IDE типа IntelliJ, только в стиле Vim. Как и с любым инструментом, использующим vim, в нем довольно трудно ориентироваться и задействовать его, если не знаешь хотя бы несколько клавиш быстрого доступа. Иногда трудно даже понять, что перед тобой. Так что, если вам здесь понадобится помощь, рекомендую это подробное руководство.
Если все изложенное выше кажется слишком трудным или вам просто страшно использовать rebase , тогда создайте pull request (запрос на включение изменений в репозиторий) в GitHub и задействуйте кнопку Rebase and merge («Переместить и объединить»), чтобы выполнять хотя бы простые перемещения/слияния с перемоткой вперед.
Главное — эффективность
В предыдущих примерах мы показали несколько хитрых приемов и особенностей, но всех их запомнить не так просто. Особенно это касается таких команд, как git log . К счастью, у нас есть глобальная конфигурация и псевдонимы git , делающие использование упомянутых приемов гораздо более удобным. Глобальная конфигурация git находится в
/.gitconfig и обновляется при каждом запуске git config --global . . Даже если вы не пробовали настроить этот файл, наверняка знаете, что в нем находится обычное для таких файлов содержимое, например раздел [user] и т. д. Но никто не мешает добавить в файл гораздо больше данных:
В этом примере добавлен ряд доступных параметров конфигурации. Здесь для длинной команды git log был назначен псевдоним git graph . Значение автозамены установлено на 10 . То есть проходит одна секунда, прежде чем выполняется правильная команда вместо той, которая была введена неправильно. И в конце мы видим конфигурацию для подписи коммита с помощью GPG (подробнее об этом ниже).
Настройка .gitconfig со множеством псевдонимов — уже немало. А кроме них, есть довольно много хороших ресурсов с примерами того, что еще включают в .gitconfig . Поэтому вместо того, чтобы приводить здесь всеобъемлющий список параметров и псевдонимов, ограничимся несколькими ресурсами, которые все это содержат:
Аналогичное повышение производительности, как и в случае с псевдонимами, достигается с помощью автоматического завершения команд. Устанавливается оно просто с помощью:
Дополнительные возможности
Помимо этих удобных псевдонимов, есть еще плагин git-extras со множеством полезных команд, которые тоже способны немного облегчить нам жизнь. Не будем подробно расписывать здесь весь функционал этого плагина. Желающие ознакомятся со списком его команд здесь, мы же быстренько пробежимся по тому, что там внутри:
- git delta выводит список файлов, отличающихся от другой ветки.
- git show-tree отображает декорированное графовое представление коммитов из всех веток аналогично показанному ранее.
- git pull-request создает pull request (запрос на включение изменений в репозиторий) через командную строку.
- git changelog генерирует журнал изменений из описаний коммитов и тегов.
Кроме этого плагина, конечно, есть и другие замечательные инструменты, например тот, который позволяет открывать репозиторий в браузере прямо из интерфейса командной строки. А статус репозитория в терминале настраивается с помощью zsh или bash-it .
Подписывание коммитов
Вам наверняка доводилось просматривать историю коммитов какого-нибудь проекта разработки ПО с открытым исходным кодом, даже если вы никогда не участвовали ни в одном из таких проектов. И в этой истории коммитов вы, скорее всего, видели значок завершения работы с коммитом и/или подписанный/проверенный значок коммита. Но что они означают и для чего используются?
Первый из них — значок завершения работы с коммитом — используется в некоторых проектах, чтобы показать, что его автор подтверждает, что он создал соответствующий код, или подтверждает, что (насколько ему известно) код был создан под соответствующей open-source лицензией. Это делается по юридическим причинам, связанным с авторским статусом кода. Использовать этот значок необязательно, но если однажды вы захотите поделиться своим кодом в каком-нибудь проекте, где будет требоваться такой значок, то вот как это делать:
В этом примере при запуске git commit с параметром --sign-off в конце описания коммита от имени пользователя из конфигурации git автоматически добавилась строка Signed-off-by: . .
Что касается подписанного/проверенного значка коммита, который вы наверняка замечали в некоторых репозиториях — используется он для того, чтобы противодействовать такому распространенному на GitHub явлению, как имперсонализация (т. е. когда одни пользователи выдают себя за других пользователей). Все, что нужно таким пользователям для осуществления своих злонамерений, — это поменять имя автора коммита и адрес электронной почты в конфигурации и добавить изменения кода. Для предотвращения имперсонализации подписывайте коммиты, задействуя GPG-ключи. Так проверяется, действительно ли человек, сделавший коммит и добавивший в него код, является тем, за кого себя выдает. Подписанный/проверенный значок коммита более распространен, чем значок завершения работы с коммитом, ведь часто бывает важно знать, кто на самом деле автор кода.
Если вы хотите начать использовать эту функциональную особенность или, возможно, применить ее в работе своей команды, делайте следующее:
Сначала будет сгенерирована пара ключей GPG (если ее еще нет), затем с помощью git config . установлен ключ подписи и, наконец, при написании коммита кода добавлен параметр -S . Потом при просмотре информации о коммитах в GitHub вы увидите такой же значок, как на этом рисунке:
Заключение
git — очень мощный инструмент со слишком большим количеством подкоманд и параметров, чтобы охватить их всех в одной статье.
Читайте также: