Пользователь
-
Автор темы
- #1
Это незаконченная тема, мне действительно лень переводить всё сразу.
Полная презентация состоит из 61 главы, ещё более 100 разделов.
Чуть позже я буду всё обновлять и добавлять новые главы.
Содержание:
Глава 1: Начало работы с Git
Раздел 1.1: Создайте свой первый репозиторий, затем добавьте и зафиксируйте файлы
Раздел 1.2: Клонирование репозитория
Раздел 1.3: Общий код
Раздел 1.4: Настройка имени пользователя и электронной почты
Раздел 1.5: Настройка вышестоящего пульта дистанционного управления
Раздел 1.6: Изучение команды
Раздел 1.7: Настройка SSH для Git
Раздел 1.8: Установка Git.
Глава 2: Просмотр истории
Раздел 2.1: "Обычный" журнал Git
Раздел 2.2: Более красивый журнал
Раздел 2.3: Раскрашивание журналов
Раздел 2.4: Онлайн журнал
Раздел 2.5: Поиск в журнале
Раздел 2.6: Перечислите все материалы, сгруппированные по имени автора
Раздел 2.7: Поиск строки фиксации в журнале git
Раздел 2.8: Ведение журнала для диапазона строк в файле
Раздел 2.9: Фильтрация журналов
Раздел 2.10: Журнал с изменениями в строке
Раздел 2.11: Журнал, показывающий зарегистрированные файлы
Раздел 2.12: Показать содержимое одного коммита
Раздел 2.13: Журнал Git Между Двумя Ветвями
Раздел 2.14: Одна строка, показывающая имя коммитера и время с момента фиксации.
Глава 3: Работа с пультами дистанционного управления.
Раздел 3.1: Удаление удаленной ветви
Раздел 3.2: Изменение удаленного URL-адреса Git
Раздел 3.3: Список существующих пультов дистанционного управления
Раздел 3.4. Удаление локальных копий удаленных удаленных филиалов
Раздел 3.5: Обновление из вышестоящего репозитория
Раздел 3.6: ls-пульт дистанционного управления
Раздел 3.7. Добавление нового удаленного хранилища
Раздел 3.8: Установка вверх по течению на новой ветке
Раздел 3.9: Начало работы
Раздел 3.10: Переименование удаленного
Раздел 3.11: Отображение информации о конкретном удаленном устройстве
Раздел 3.12: Задайте URL-адрес для определенного удаленного
Раздел 3.13. Получение URL-адреса для определенного удаленного
Раздел 3.14: Изменение удаленного хранилища
Глава 4: Постановка
Раздел 4.1: Подготовка всех изменений в файлах
Раздел 4.2: Удаление файла, содержащего изменения
Раздел 4.3: Добавление изменений по частям
Раздел 4.4: Интерактивное добавление
Раздел 4.5: Показать поэтапные изменения
Раздел 4.6. Размещение одного файла
Раздел 4.7: Этап удаления файлов
Глава 5. Игнорирование файлов и папок
Раздел 5.1: Игнорирование файлов и каталогов с помощью файла .gitignore
Раздел 5.2: Проверка, игнорируется ли файл
Раздел 5.3: Исключения в файле .gitignore
Раздел 5.4: Глобальный файл .gitignore
Раздел 5.5: Игнорируйте файлы, которые уже были зафиксированы в репозитории Git
Раздел 5.6: Игнорировать файлы локально без фиксации правил игнорирования
Раздел 5.7: Игнорирование последующих изменений в файле (без его удаления)
Раздел 5.8: Игнорирование файла в любом каталоге
Раздел 5.9: Предварительно заполненные шаблоны .gitignore
Раздел 5.10: Игнорирование файлов во вложенных папках (несколько файлов gitignore)
Раздел 5.11: Создайте пустую папку
Раздел 5.12: Поиск файлов, игнорируемых .gitignore
Раздел 5.13: Игнорирование только части файла [stub]
Раздел 5.14: Игнорирование изменений в отслеживаемых файлах. [stub]
Раздел 5.15: Очистить уже зафиксированные файлы, но включенные в .gitignore
Глава 6: Разница в Git
Раздел 6.1: Показать различия в рабочей ветви
Раздел 6.2: Показать изменения между двумя фиксациями
Раздел 6.3: Показать различия для поэтапных файлов
Раздел 6.4: Сравнение филиалов
Раздел 6.5: Показать как поэтапные, так и нестационарные изменения
Полная презентация состоит из 61 главы, ещё более 100 разделов.
Чуть позже я буду всё обновлять и добавлять новые главы.
Содержание:
Глава 1: Начало работы с Git
Раздел 1.1: Создайте свой первый репозиторий, затем добавьте и зафиксируйте файлы
Раздел 1.2: Клонирование репозитория
Раздел 1.3: Общий код
Раздел 1.4: Настройка имени пользователя и электронной почты
Раздел 1.5: Настройка вышестоящего пульта дистанционного управления
Раздел 1.6: Изучение команды
Раздел 1.7: Настройка SSH для Git
Раздел 1.8: Установка Git.
Глава 2: Просмотр истории
Раздел 2.1: "Обычный" журнал Git
Раздел 2.2: Более красивый журнал
Раздел 2.3: Раскрашивание журналов
Раздел 2.4: Онлайн журнал
Раздел 2.5: Поиск в журнале
Раздел 2.6: Перечислите все материалы, сгруппированные по имени автора
Раздел 2.7: Поиск строки фиксации в журнале git
Раздел 2.8: Ведение журнала для диапазона строк в файле
Раздел 2.9: Фильтрация журналов
Раздел 2.10: Журнал с изменениями в строке
Раздел 2.11: Журнал, показывающий зарегистрированные файлы
Раздел 2.12: Показать содержимое одного коммита
Раздел 2.13: Журнал Git Между Двумя Ветвями
Раздел 2.14: Одна строка, показывающая имя коммитера и время с момента фиксации.
Глава 3: Работа с пультами дистанционного управления.
Раздел 3.1: Удаление удаленной ветви
Раздел 3.2: Изменение удаленного URL-адреса Git
Раздел 3.3: Список существующих пультов дистанционного управления
Раздел 3.4. Удаление локальных копий удаленных удаленных филиалов
Раздел 3.5: Обновление из вышестоящего репозитория
Раздел 3.6: ls-пульт дистанционного управления
Раздел 3.7. Добавление нового удаленного хранилища
Раздел 3.8: Установка вверх по течению на новой ветке
Раздел 3.9: Начало работы
Раздел 3.10: Переименование удаленного
Раздел 3.11: Отображение информации о конкретном удаленном устройстве
Раздел 3.12: Задайте URL-адрес для определенного удаленного
Раздел 3.13. Получение URL-адреса для определенного удаленного
Раздел 3.14: Изменение удаленного хранилища
Глава 4: Постановка
Раздел 4.1: Подготовка всех изменений в файлах
Раздел 4.2: Удаление файла, содержащего изменения
Раздел 4.3: Добавление изменений по частям
Раздел 4.4: Интерактивное добавление
Раздел 4.5: Показать поэтапные изменения
Раздел 4.6. Размещение одного файла
Раздел 4.7: Этап удаления файлов
Глава 5. Игнорирование файлов и папок
Раздел 5.1: Игнорирование файлов и каталогов с помощью файла .gitignore
Раздел 5.2: Проверка, игнорируется ли файл
Раздел 5.3: Исключения в файле .gitignore
Раздел 5.4: Глобальный файл .gitignore
Раздел 5.5: Игнорируйте файлы, которые уже были зафиксированы в репозитории Git
Раздел 5.6: Игнорировать файлы локально без фиксации правил игнорирования
Раздел 5.7: Игнорирование последующих изменений в файле (без его удаления)
Раздел 5.8: Игнорирование файла в любом каталоге
Раздел 5.9: Предварительно заполненные шаблоны .gitignore
Раздел 5.10: Игнорирование файлов во вложенных папках (несколько файлов gitignore)
Раздел 5.11: Создайте пустую папку
Раздел 5.12: Поиск файлов, игнорируемых .gitignore
Раздел 5.13: Игнорирование только части файла [stub]
Раздел 5.14: Игнорирование изменений в отслеживаемых файлах. [stub]
Раздел 5.15: Очистить уже зафиксированные файлы, но включенные в .gitignore
Глава 6: Разница в Git
Раздел 6.1: Показать различия в рабочей ветви
Раздел 6.2: Показать изменения между двумя фиксациями
Раздел 6.3: Показать различия для поэтапных файлов
Раздел 6.4: Сравнение филиалов
Раздел 6.5: Показать как поэтапные, так и нестационарные изменения
- Глава 1: Начало работы с Git
Дата выпуска версии:
2.13 2017-05-10
2.12 2017-02-24
2.11.1 2017-02-02
2.11 2016-11-29
2.10.2 2016-10-28
2.10 2016-09-02
2.9 2016-06-13
2.8 2016-03-28
2.7 2015-10-04
2.6 2015-09-28
2.5 2015-07-27
2.4 2015-04-30
2.3 2015-02-05
2.2 2014-11-26
2.1 2014-08-16
2.0 2014-05-28
1.9 2014-02-14
1.8.3 2013-05-24
1.8 2012-10-21
1.7.10 2012-04-06
1.7 2010-02-13
1.6.5 2009-10-10
1.6.3 2009-05-07
1.6 2008-08-17
1.5.3 2007-09-02
1.5 2007-02-14
1.4 2006-06-10
1.3 2006-04-18
1.2 2006-02-12
1.1 2006-01-08
1.0 2005-12-21
0.99 2005-07-11
Раздел 1.1: Создайте свой первый репозиторий, затем добавьте и зафиксируйте файлы
В командной строке сначала убедитесь, что у вас установлен Git:
На всех операционных системах:
git --version
В UNIX-подобных операционных системах:
which git
Если ничего не возвращено или команда не распознана, возможно, вам придется установить Git в вашей системе, загрузив и запустив установщик. Смотрите домашнюю страницу Git для получения исключительно четких и простых инструкций по установке.
После установки Git настройте свое имя пользователя и адрес электронной почты. Сделайте это, прежде чем брать на себя обязательства.
После установки Git перейдите в каталог, который вы хотите поместить под управление версиями, и создайте пустое хранилище Git:
git init
Это создает скрытую папку .git, в которой содержится сантехника, необходимая для работы Git
Затем проверьте, какие файлы Git добавит в ваш новый репозиторий; этот шаг заслуживает особого внимания:
git status
Просмотрите полученный список файлов; вы можете указать Git, какие файлы следует поместить в систему управления версиями (избегайте добавления файлов с конфиденциальной информацией, такой как пароли, или файлов, которые просто загромождают репозиторий):
git add <file/directory name #1> <file/directory name #2> < ... >
Если все файлы в списке должны быть доступны всем, у кого есть доступ к хранилищу, одна команда добавит все в ваш текущий каталог и его подкаталоги:
git add .
Это "этапирует" все файлы, которые будут добавлены в систему управления версиями, подготавливая их к фиксации в вашей первой фиксации.
Для файлов, которые вы не хотите использовать под контролем версий, создайте и заполните файл с именем .gitignore перед выполнением команды добавить.
Зафиксируйте все добавленные файлы вместе с сообщением о фиксации:
git commit -m "Initial commit"
Это создает новую фиксацию с данным сообщением. Фиксация похожа на сохранение или снимок всего вашего проекта. Теперь вы можете отправить или загрузить его в удаленное хранилище, а затем при необходимости вернуться к нему. Если вы опустите параметр -m, откроется редактор по умолчанию, в котором вы сможете отредактировать и сохранить сообщение о фиксации.
Добавление удаленного
Чтобы добавить новый пульт дистанционного управления, используйте команду git remote add на терминале, в каталоге, в котором хранится ваш репозиторий.
Команда удаленного добавления git принимает два аргумента:
Команда добавления git remote принимает два аргумента:
1. Удаленное имя, например, origin
2. Удаленный URL-адрес, например, https://<адрес вашей службы git>/пользователь/repo.git
git remote добавить origin https://<ваш-git-адрес службы>/владелец/репозиторий.git
ПРИМЕЧАНИЕ: Перед добавлением пульта дистанционного управления вам необходимо создать необходимый репозиторий в своей службе git, вы сможете отправлять / извлекать коммиты после добавления пульта дистанционного управления
Раздел 1.2: Клонирование репозитория
Команда git clone используется для копирования существующего репозитория Git с сервера на локальную машину.
Например, для клонирования проекта GitHub:
cd <путь, по которому вы хотите, чтобы клон создал каталог>
git clone
Чтобы клонировать проект BitBucket:
cd <путь, по которому вы хотите, чтобы клон создал каталог>
git clone
Это создает каталог с именем проекта на локальном компьютере, содержащий все файлы в удаленном репозитории Git. Это включает в себя исходные файлы для проекта, а также подкаталог .git, который содержит всю историю и конфигурацию проекта.
Чтобы указать другое имя каталога, например MyFolder:
git clone
Или клонировать в текущем каталоге:
git clone
Примечание:
1. При клонировании в указанный каталог каталог должен быть пустым или отсутствовать.
2. Вы также можете использовать ssh-версию команды:
git clone git@github.com:username/projectname.git
Версия https и версия ssh эквивалентны. Однако некоторые службы хостинга, такие как GitHub, рекомендуют использовать https, а не ssh.
Раздел 1.3: Общий код
Чтобы поделиться своим кодом, вы создаете репозиторий на удаленном сервере, на который вы скопируете свой локальный репозиторий.
Чтобы свести к минимуму использование пространства на удаленном сервере, вы создаете пустой репозиторий: тот, который содержит только объекты .git и не создает рабочую копию в файловой системе. В качестве бонуса вы устанавливаете этот удаленный сервер в качестве вышестоящего сервера, чтобы легко обмениваться обновлениями с другими программистами.
На удаленном сервере:
git init --bare /path/to/repo.git
На локальном компьютере:
git remote add origin ssh://username@server:/path/to/repo.git
(Обратите внимание, что ssh: это всего лишь один из возможных способов доступа к удаленному хранилищу.)
Теперь скопируйте свой локальный репозиторий на удаленный:
git push --set-upstream origin master
Добавление --set-upstream (или -u) создало ссылку на восходящий поток (отслеживание), которая используется командами Git без аргументов, например, git pull.
Раздел 1.4: Настройка имени пользователя и электронной почты
Вам нужно установить, кто вы, прежде чем создавать какие-либо фиксации. Это позволит коммитам иметь правильное имя автора и адрес электронной почты, связанные с ними.
Это не имеет ничего общего с аутентификацией при отправке в удаленное хранилище (например, при отправке в удаленное хранилище с помощью вашей учетной записи GitHub, BitBucket или GitLab)
Чтобы объявить эту идентификацию для всех репозиториев, используйте git config --global
Это сохранит настройки в файле .gitconfig вашего пользователя: например, $HOME/.gitconfig или для Windows, %USERPROFILE%\.gitconfig.
git config --global user.name "Your Name"
git config --global user.email mail@example.com
Чтобы объявить идентификатор для одного репозитория, используйте git config внутри репозитория.
Это сохранит настройку внутри отдельного репозитория в файле $GIT_DIR/config. например, /путь/к/вашему/репозиторию/.git/config.
cd /путь/к/моему/репозиторию
git config user.name "Your Login At Work"
git config user.email mail_at_work@example.com
Настройки, хранящиеся в файле конфигурации репозитория, будут иметь приоритет над глобальной конфигурацией при использовании этого репозитория.
Советы: если у вас разные идентификаторы (один для проекта с открытым исходным кодом, один на работе, один для частных репозиториев, ...), и вы не хотите забывать устанавливать правильный для каждого отдельного репозитория, над которым вы работаете:
Удалить глобальную идентификацию
git config --global --remove-section user.name
git config --global --remove-section user.email
Версия ≥ 2.8
Чтобы заставить git искать вашу личность только в настройках репозитория, а не в глобальной конфигурации:
git config --global user.useConfigOnly true
Таким образом, если вы забудете установить свой user.name и user.email для данного репозитория и попытайтесь совершить фиксацию, вы увидите:
имя не было указано, и автоматическое обнаружение отключено
адрес электронной почты не был указан, и автоматическое обнаружение отключено
Раздел 1.5: Настройка вышестоящего пульта дистанционного управления
Если вы клонировали форк (например, проект с открытым исходным кодом на Github), у вас может не быть принудительного доступа к вышестоящему репозиторию, поэтому вам нужны оба форка, но вы можете получить доступ к вышестоящему репозиторию.
Сначала проверьте удаленные имена:
$ git remote -v
origin
origin
upstream # эта строка может быть здесь, а может и не быть
Если upstream уже существует (он есть в некоторых версиях Git), вам нужно установить URL-адрес (в настоящее время он пуст):
$ git remote set-url upstream
Если восходящего потока нет, или если вы также хотите добавить вилку друга / коллеги (в настоящее время их не существует):
$ git remote add upstream
$ git remote add dave
Раздел 1.6: Изучение команды
Чтобы получить дополнительную информацию о любой команде git, т.е. подробную информацию о том, что делает команда, доступных параметрах и другой документации, используйте опцию --help или команду help.
Например, чтобы получить всю доступную информацию о команде git diff, используйте:
git diff --help
git help diff
Аналогично, чтобы получить всю доступную информацию о команде status, используйте:
git status --help
git help status
Если вам нужна только краткая справка, показывающая значение наиболее часто используемых флагов командной строки, используйте -h:
git checkout -h
Раздел 1.7: Настройка SSH для Git
Если вы используете Windows, откройте Git Bash. Если вы используете Mac или Linux, откройте свой терминал.
Прежде чем сгенерировать SSH-ключ, вы можете проверить, есть ли у вас какие-либо существующие SSH-ключи.
Перечислите содержимое вашего каталога ~/.ssh:
$ ls -al ~/.ssh
# Перечисляет все файлы в вашем каталоге ~/.ssh
Проверьте список каталогов, чтобы узнать, есть ли у вас уже открытый SSH-ключ. По умолчанию имена файлов открытых ключей являются одним из следующих:
id_dsa.pub
id_ecdsa.pub
id_ed25519.pub
id_rsa.pub
Если вы видите в списке существующую пару открытых и закрытых ключей, которую вы хотели бы использовать в своей учетной записи Bitbucket, GitHub (или аналогичной), вы можете скопировать содержимое файла id_*.pub.
Если нет, вы можете создать новую пару открытого и закрытого ключей с помощью следующей команды:
$ ssh-keygen
Нажмите клавишу Ввода или возврата, чтобы принять расположение по умолчанию. Введите и повторно введите кодовую фразу при появлении запроса или оставьте ее пустой.
Убедитесь, что ваш SSH-ключ добавлен в ssh-агент. Запустите ssh-агент в фоновом режиме, если он еще не запущен:
$ eval "$(ssh-agent -s)"
Добавьте свой SSH-ключ в ssh-агент. Обратите внимание, что вам нужно будет заменить id_rsa в команде именем вашего файла закрытого ключа:
$ ssh-add ~/.ssh/id_rsa
Если вы хотите изменить восходящий поток существующего репозитория с HTTPS на SSH, вы можете выполнить следующую команду:
$ git remote set-url origin ssh://git@bitbucket.server.com:7999/projects/your_project.git
Чтобы клонировать новый репозиторий по SSH, вы можете выполнить следующую команду:
$ git clone ssh://git@bitbucket.server.com:7999/projects/your_proje
Раздел 1.8: Установка Git
Давайте займемся использованием какого-нибудь мерзавца. Перво-наперво - вы должны его установить. Вы можете получить его несколькими способами; два основных из них - установить его из исходного кода или установить существующий пакет для вашей платформы.
Установка из исходного кода
Если вы можете, обычно полезно установить Git из исходного кода, потому что вы получите самую последнюю версию. Каждая версия Git, как правило, включает полезные улучшения пользовательского интерфейса, поэтому получение последней версии часто является лучшим способом, если вы чувствуете себя комфортно при компиляции программного обеспечения из исходного кода. Это также тот случай, когда многие дистрибутивы Linux содержат очень старые пакеты; поэтому, если вы не используете очень современный дистрибутив или не используете бэкпорты, установка из исходного кода может быть лучшим выбором.
Чтобы установить Git, вам необходимо иметь следующие библиотеки, от которых зависит Git: curl, zlib, openssl, expat и libiconv. Например, если вы находитесь в системе, в которой есть yum (например, Fedora) или apt-get (например, система на базе Debian), вы можете использовать одну из этих команд для установки всех зависимостей:
$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev
Когда у вас будут все необходимые зависимости, вы можете продолжить и получить последний снимок с веб-сайта Git:
$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
После того, как это будет сделано, вы также можете получить Git через сам Git для обновлений:
$ git clone git://git.kernel.org/pub/scm/git/git.git
Установка в Linux
Если вы хотите установить Git в Linux с помощью двоичного установщика, вы обычно можете сделать это с помощью базового инструмента управления пакетами, который поставляется с вашим дистрибутивом. Если вы используете Fedora, вы можете использовать yum:
$ yum install git
Или, если вы используете дистрибутив на основе Debian, такой как Ubuntu, попробуйте apt-get:
$ apt-get install git
Установка на Mac
Существует три простых способа установки Git на Mac. Проще всего использовать графический установщик Git, который вы можете скачать со страницы SourceForge.
Рисунок 1-7. Установщик Git OS X. Другой важный способ - установить Git через MacPorts (
$ sudo port install git +svn +doc +bash_completion +gitweb
Вам не нужно добавлять все дополнительные функции, но вы, вероятно, захотите включить +svn на случай, если вам когда-нибудь придется использовать Git с репозиториями Subversion
Домашнее пиво (
$ brew install git
Установка в Windows
Установить Git в Windows очень просто. Проект msysGit имеет одну из самых простых процедур установки. Просто скачайте exe-файл установщика со страницы GitHub и запустите его:
После его установки у вас будет как версия командной строки (включая SSH-клиент, который пригодится позже), так и стандартный графический интерфейс.
Примечание по использованию Windows: вы должны использовать Git с предоставленной оболочкой msysGit (в стиле UNIX), она позволяет использовать сложные строки команд, приведенные в этой книге. Если вам по какой-либо причине нужно использовать собственную оболочку Windows / консоль командной строки, вы должны использовать двойные кавычки вместо одинарных кавычек (для параметров с пробелами в них), и вы должны указывать параметры, заканчивающиеся знаком окружности (^), если они последние в строке, так как это символ продолжения в Windows.
Раздел 2.1: "Обычный" журнал Git
git log
Отобразит все ваши коммиты с автором и хэшем. Это будет показано в нескольких строках для каждой фиксации. ((Если вы хотите показать одну строку за фиксацию, посмотрите на одну подкладку). Используйте клавишу q для выхода из журнала.
По умолчанию, без аргументов, в журнале git перечисляются коммиты, сделанные в этом репозитории, в обратном хронологическом порядке, то есть сначала отображаются самые последние коммиты. Как вы можете видеть, эта команда перечисляет каждую фиксацию с контрольной суммой SHA-1, именем автора и электронной почтой, датой написания и сообщением о фиксации. - источник
Пример (из репозитория freeCodeCamp):
git log -2
Раздел 2.2: Более красивый журнал
Чтобы увидеть журнал в более красивой графической структуре, используйте:
git log --decorate --oneline --graph
Пример вывода :
git config --global alias.lol "log --decorate --oneline --graph"
Чтобы использовать версию псевдонима:
# история текущей ветви :
git lol
# объединенная история активной ветви (ГОЛОВНОЙ), ветвей разработки и происхождения/основных ветвей :
git lol HEAD develop origin/master
# объединенная история всего, что находится в вашем репо :
git lol --all
Раздел 2.3: Раскрашивание журналов
git log --graph --pretty=format:'%C(red)%h%Creset -%C(yellow)%d%Creset %s %C(green)(%cr) %C(yellow)<%an>%Creset
Опция Формат позволяет вам указать свой собственный формат вывода журнала:
Раздел 2.4: Онлайн-журнал
git log --oneline
Покажет все ваши коммиты только с первой частью хэша и сообщением о фиксации. Каждая фиксация будет в одной строке, как предполагает флаг одной строки.
Опция oneline выводит каждую фиксацию в одной строке, что полезно, если вы просматриваете много фиксаций. - источник
Пример (из репозитория freeCodeCamp, с тем же разделом кода из другого примера):
git log -2 --oneline
Раздел 2.5: Поиск в журнале
git log -S"#define SAMPLES"
Выполняет поиск добавления или удаления определенной строки или строки, соответствующей предоставленному регулярному выражению. В этом случае мы ищем добавление/удаление строки #define SAMPLES. Например:
+#define SAMPLES 100000
или
-#define SAMPLES 100000
git log -G"#define SAMPLES"
Выполняет поиск изменений в строках, содержащих определенную строку или строку, соответствующую предоставленному регулярному выражению. Например:
-#define SAMPLES 100000
+#define SAMPLES 100000000
Раздел 2.6: Перечислите все материалы, сгруппированные по имени автора
git shortlog обобщает git log и группирует по авторам
Если параметры не указаны, список всех коммитов, сделанных для каждого комитета, будет показан в хронологическом порядке
-s
--summary
$ git shortlog -s
Committer 1
Committer 2
Чтобы отсортировать выходные данные по количеству фиксаций, а не по алфавиту по названию комитета, введите параметр с номером:
-n
--numbered
Чтобы добавить адрес электронной почты комитета, добавьте опцию электронной почты:
-e
--email
Также можно указать параметр пользовательского формата, если вы хотите отображать информацию, отличную от темы фиксации:
--format
Это может быть любая строка, принятая параметром --format в git log.
Дополнительные сведения об этом см. в разделе "Раскрашивание журналов" выше.
Раздел 2.7: Поиск строки фиксации в журнале git
Поиск в журнале git с использованием некоторой строки в журнале:
git log [options] --grep "search_string"
Пример:
git log --all --grep "removed file"
Будет искать удаленную строку файла во всех журналах во всех ветвях.
Начиная с git 2.4+, поиск можно инвертировать с помощью опции --invert-grep .
Пример:
git log --grep="add file" --invert-grep
Покажет все коммиты, которые не содержат файла добавления.
Раздел 2.8: Ведение журнала для диапазона строк в файле
git log --after '3 days ago'
Конкретные даты тоже работают:
git log --after 2016-05-01
Как и в случае с другими командами и флагами, которые принимают параметр даты, разрешенный формат даты поддерживается GNU date (очень гибкий).
Псевдоним --after - это --since.
Флаги существуют и для обратного: --before и --until.
Вы также можете фильтровать журналы по авторам. например
git log --author=author
Раздел 2.10: Журнал с изменениями в строке
Чтобы просмотреть журнал с изменениями в строке, используйте параметры -por --patch.
git log --patch
Пример (из репозитория Trello Scientist)
git log --stat
Пример:
Используя git show, мы можем просмотреть один коммит
git show 48c83b3
git show 48c83b3690dfc7b0e622fd220f8f37c26a77c934
Пример:
git log master..foo покажет коммиты, которые находятся на foo, а не на master. Полезно посмотреть, какие коммиты вы добавили с момента ветвления!
Раздел 2.14: Одна строка, показывающая имя участника и время с момента совершения
tree = log --oneline --decorate --source --pretty=format:'"%Cblue %h %Cgreen %ar %Cblue %an %C(yellow) %d %Creset %s"' --all --graph
Пример:
Глава 3: Работа с удаленными устройствами
Раздел 3.1: Удаление удаленного филиала
Чтобы удалить удаленную ветвь в Git:
git push [remote-name] --delete [branch-name]
или
git push [remote-name] :[branch-name]
Раздел 3.2: Изменение удаленного URL-адреса Git
Проверьте существующий пульт дистанционного управления
git remote -v
# origin
# origin
Изменение URL-адреса репозитория
git remote set-url origin
# # Измените удаленный URL-адрес источника
Проверьте новый удаленный URL-адрес
git remote -v
# origin
# origin
Раздел 3.3: Список Существующих Пультов Дистанционного Управления
Перечислите все существующие удаленные устройства, связанные с этим хранилищем:
git remote
Подробно перечислите все существующие удаленные устройства, связанные с этим хранилищем, включая URL-адреса для извлечения и отправки:
git remote --verbose
или просто
git remote -v
Раздел 3.4. Удаление локальных копий удаленных удаленных филиалов
Если удаленная ветвь была удалена, необходимо указать вашему локальному репозиторию, чтобы он удалил ссылку на нее.
Чтобы обрезать удаленные ветви с определенного удаленного:
git fetch [remote-name] --prune
Чтобы обрезать удаленные ветви со всех удаленных устройств:
git fetch --all --prune
Раздел 3.5: Обновление из вышестоящего репозитория
Предполагая, что вы установили восходящий поток (как в разделе "настройка восходящего репозитория")
git fetch remote-name
git merge remote-name/branch-name
Команда pull объединяет выборку и слияние.
git pull
Команда pull с флагом --rebase объединяет выборку и перебазирование вместо слияния.
git pull --rebase remote-name branch-name
Раздел 3.6: ls-пульт дистанционного управления
git ls-remote - это уникальная команда, позволяющая запрашивать удаленное репозиторий без необходимости его клонирования / извлечения
В нем будут перечислены ссылки / заголовки и ссылки / теги указанного удаленного репо.
Иногда вы увидите ссылки/теги/v0.1.6 и ссылки/теги/v0.1.6 ^{}: ^{} для перечисления разыменованного аннотированного тега (т.Е. фиксации, на которую указывает тег)
Начиная с git 2.8 (март 2016 г.), вы можете избежать этой двойной записи для тега и напрямую перечислить разыменованные теги с помощью:
git ls-remote --ref
Это также может помочь решить фактический URL-адрес, используемый удаленным репозиторием, если у вас есть настройка конфигурации "url.<база>.вместо". Если git remote --set-url <удаленное имя> возвращает
git ls-remote --get-url
ssh://git@server.com:user/repo
Раздел 3.7. Добавление нового удаленного хранилища
git remote add upstream git-repository-url
Добавляет удаленный репозиторий git, представленный URL-адресом репозитория git, в качестве нового удаленного хранилища с именем вверх по течению в репозиторий git
Раздел 3.8: Установка вверх по течению на новой ветке
Вы можете создать новую ветвь и переключиться на нее с помощью
git checkout -b AP-57
После того, как вы используете git checkout для создания новой ветви, вам нужно будет указать, что источник восходящего потока будет использоваться
git push --set-upstream origin AP-57
После этого вы можете использовать git push, пока находитесь в этой ветке
Раздел 3.9: Начало работы
Синтаксис для отправки в удаленную ветвь
git push <remote_name> <branch_name>
Пример
git push origin master
Раздел 3.10: Переименование удаленного
Чтобы переименовать удаленный, используйте команду git remote rename
Команда удаленного переименования git принимает два аргумента:
Существующее удаленное имя, например : origin
Новое имя для удаленного устройства, например : destination
Получить существующее удаленное имя
git remote
# origin
Проверьте существующий пульт дистанционного управления с помощью URL
git remote -v
# origin
# origin
Переименование удаленного
git remote rename origin destination
# Измените удаленное имя с "origin" на "destination"
Подтвердите новое имя
git remote -v
# destination
# destination
====== Возможные ошибки ===
1. Не удалось переименовать раздел конфигурации "удаленный".[старое имя] "на "пульт дистанционного управления.[новое имя]'
Эта ошибка означает, что пульт дистанционного управления, на котором вы пытались использовать старое удаленное имя (источник), не существует.
2. Пульт дистанционного управления [новое имя] уже существует.
Сообщение об ошибке не требует пояснений.
Раздел 3.11: Отображение информации о конкретном удаленном устройстве
Выведите некоторую информацию об известном удаленном устройстве: origin
git remote show origin
Распечатайте только удаленный URL-адрес:
git config --get remote.origin.url
С 2.7+ это также возможно сделать, что, возможно, лучше, чем приведенное выше, в котором используется команда config.
git remote get-url origin
Раздел 3.12: Задайте URL-адрес для определенного удаленного
Вы можете изменить URL-адрес существующего удаленного устройства с помощью команды
git remote set-url remote-name url
Раздел 3.13. Получение URL-адреса для определенного удаленного
Вы можете получить URL-адрес существующего удаленного устройства с помощью команды
git remote get-url
По умолчанию это будет
git remote get-url origin
Раздел 3.14: Изменение удаленного хранилища
Чтобы изменить URL-адрес хранилища, на которое должен указывать ваш пульт дистанционного управления, вы можете использовать параметр set-url, например:
git remote set-url
Пример:
git remote set-url heroku
git add -A
Version ≥ 2.0
git add .
В версии 2.x git add . будет выполнять все изменения файлов в текущем каталоге и всех его подкаталогах. Однако в 1.x он будет отображать только новые и измененные файлы, а не удаленные файлы.
Используйте git add -A или эквивалентную команду git add --all, чтобы вносить все изменения в файлы в любой версии git.
Раздел 4.2: Удаление файла, содержащего изменения
git reset <filePath>
Раздел 4.3: Добавление изменений по частям
Вы можете увидеть, какие "куски" работы будут подготовлены для фиксации, используя флаг исправления:
git add -p
или
git add --patch
Откроется интерактивное приглашение, которое позволит вам просмотреть различия и решить, хотите ли вы включить их или нет.
Поставьте этот кусок [y, n, q, a, d,/, s, e,?]?
Это позволяет легко улавливать изменения, которые вы не хотите фиксировать.
Вы также можете открыть это с помощью git add --interactive и выбора свойств.
Раздел 4.4: Интерактивное добавление
git add -i (или --interactive) предоставит вам интерактивный интерфейс, в котором вы сможете редактировать индекс, чтобы подготовить то, что вы хотите иметь в следующем коммите. Вы можете добавлять и удалять изменения в целые файлы, добавлять неотслеживаемые файлы и удалять файлы из отслеживания, а также выбирать подраздел изменений для включения в индекс, выбирая фрагменты добавляемых изменений, разделяя эти фрагменты или даже редактируя разницу. Многие графические инструменты фиксации для Git (например, git gui) включают такую функцию; это может быть проще в использовании, чем версия командной строки.
Это очень полезно (1), если у вас есть запутанные изменения в рабочем каталоге, которые вы хотите поместить в отдельные фиксации, а не все в одну фиксацию (2), если вы находитесь в середине интерактивной перебазировки и хотите разделить слишком большую фиксацию.
1. index.js было добавлено 4 строки и удалено 4 строки. В настоящее время он не поставлен, так как текущий статус сообщает "без изменений". Когда этот файл станет промежуточным, +4/-4, но будет перенесено в столбец промежуточный, а в неустановленном столбце будет указано "ничего".
2. в package.json была добавлена одна строка, и она была подготовлена. Дальнейших изменений нет, так как он был поэтапным, как указано в строке "ничего" под неустановленным столбцом.
Нижняя половина показывает, что вы можете сделать. Введите либо число (1-8), либо букву (s, u, r, a, p, d, q, h).
status показывает вывод, идентичный верхней части вывода выше.
update позволяет вносить дальнейшие изменения в поэтапные коммиты с дополнительным синтаксисом
revert вернет информацию о поэтапной фиксации обратно в НАЧАЛО.
add untracked позволяет добавлять пути к файлам, ранее не отслеживаемые системой управления версиями.
patch позволяет выбрать один путь из вывода, аналогичного статусу, для дальнейшего анализа.
diff отображает, что будет зафиксировано.
quit завершает выполнение команды.
help содержит дополнительную справку по использованию этой команды.
Раздел 4.5: Показать поэтапные изменения
Чтобы отобразить фрагменты, подготовленные для фиксации:
git diff --cached
Раздел 4.6. Размещение Одного Файла
Чтобы подготовить файл для фиксации, запустите
git add <filename>
Раздел 4.7: Этап удаления файлов
git rm filename
Чтобы удалить файл из git, не удаляя его с диска, используйте флаг --cached
git rm --cached filename
В этом разделе показано, как избежать добавления нежелательных файлов (или изменений файлов) в репозиторий Git. Существует несколько способов (глобальный или локальный .gitignore, .git/exclude, git update-index --assume-unchanged и git update-index -- skip-tree ), но имейте в виду, что Git управляет содержимым, что означает: игнорирование фактически игнорирует содержимое папки (т.Е. файлы). Пустая папка по умолчанию игнорируется, так как ее все равно нельзя добавить.
Раздел 5.1: Игнорирование файлов и каталогов с помощью файла .gitignore
Вы можете заставить Git игнорировать определенные файлы и каталоги, то есть исключить их из отслеживания Git, создав один или несколько файлов .gitignore в своем репозитории.
В программных проектах .gitignore обычно содержит список файлов и/или каталогов, которые создаются в процессе сборки или во время выполнения. Записи в файле .gitignore могут включать имена или пути, указывающие на:
1. временные ресурсы, например, кэш, файлы журналов, скомпилированный код и т.д.
2. локальные файлы конфигурации, которыми не следует делиться с другими разработчиками
3. файлы, содержащие секретную информацию, такую как пароли для входа, ключи и учетные данные
При создании в каталоге верхнего уровня правила будут рекурсивно применяться ко всем файлам и подкаталогам во всем хранилище. При создании в подкаталоге правила будут применяться к этому конкретному каталогу и его подкаталогам.
Когда файл или каталог игнорируется, он не будет:
1. отслеживается Git
2. сообщается с помощью таких команд, как git status или git diff
3. поэтапно с помощью таких команд, как git add -A
В необычном случае, когда вам необходимо игнорировать отслеживаемые файлы, следует проявлять особую осторожность. См. раздел: Игнорирование файлов, которые уже были зафиксированы в репозитории Git.
Пример:
Вот несколько общих примеров правил в файле .gitignore, основанных на шаблонах файлов glob:
Другие формы .gitignore
файлы .gitignore предназначены для фиксации как часть репозитория. Если вы хотите игнорировать определенные файлы без соблюдения правил игнорирования, вот несколько вариантов:
Отредактируйте файл .git/info/exclude (используя тот же синтаксис, что и .gitignore). Правила будут глобальными в рамках репозитория;
Настройте глобальный файл gitignore, который будет применять правила игнорирования ко всем вашим локальным репозиториям:
Кроме того, вы можете игнорировать локальные изменения отслеживаемых файлов без изменения глобальной конфигурации git с помощью:
git update-index --skip-worktree [<file>...]: для незначительных локальных изменений
git update-index --assume-unchanged [<file>...]: для готовых к производству, неизменяемых файлов выше по потоку
Очистка игнорируемых файлов
Вы можете использовать git clean -X для очистки игнорируемых файлов:
git clean -Xn #отобразить список игнорируемых файлов
git clean -Xf #удалить ранее отображенные файлы
Примечание: -X (заглавные буквы) очищает только игнорируемые файлы. Используйте -x (без заглавных букв), чтобы также удалить неотслеживаемые файлы.
Более подробную информацию смотрите в документации git clean
Раздел 5.2: Проверка, игнорируется ли файл
Команда git check-ignore сообщает о файлах, игнорируемых Git.
Вы можете передать имена файлов в командной строке, и git check-ignore выведет список имен файлов, которые игнорируются. Например:
$ cat .gitignore
*.o
$ git check-ignore example.o Readme.md
example.o
Здесь в файле .gitignore определены только файлы *.o, поэтому Readme.md не указан в выводе git check-ignore.
Если вы хотите увидеть строку, в которой .gitignore отвечает за игнорирование файла, добавьте -v в команду git check-ignore:
$ git check-ignore -v example.o Readme.md
.gitignore:1:*.o example.o
Начиная с Git 1.7.6 и далее, вы также можете использовать git status --ignored для просмотра игнорируемых файлов. Вы можете найти более подробную информацию об этом в официальной документации или в разделе Поиск файлов, игнорируемых .gitignore.
Раздел 5.3: Исключения в файле .gitignore
Если вы игнорируете файлы с помощью шаблона, но у вас есть исключения, добавьте восклицательный знак (!) к исключению. Например:
*.txt
!important.txt
В приведенном выше примере Git предписывает игнорировать все файлы с расширением .txt, за исключением файлов с именем important.txt .
Если файл находится в игнорируемой папке, вы не сможете повторно включить его так легко:
folder/
!folder/*.txt
В этом примере все файлы .txt в папке будут игнорироваться.
Правильный способ - повторно включить саму папку в отдельную строку, затем игнорировать все файлы в папке с помощью *, и, наконец, повторно включить *.txt в папку, как показано ниже:
!folder/
folder/*
!folder/*.txt
Примечание. Для имен файлов, начинающихся с восклицательного знака, добавьте два восклицательных знака или экранируйте символом \:
!!includethis
\!excludethis
Раздел 5.4: Глобальный файл .gitignore
Чтобы Git игнорировал определенные файлы во всех репозиториях, вы можете создать глобальный файл .gitignore с помощью следующей команды в терминале или командной строке:
$ git config --global core.excludesfile <Path_To_Global_gitignore_file>
Git теперь будет использовать это в дополнение к собственному файлу .gitignore каждого репозитория.
Правила для этого таковы:
- Если локальный файл .gitignore явно включает файл, в то время как глобальный файл .gitignore игнорирует его, локальный файл .gitignore имеет приоритет (файл будет включен)
- Если репозиторий клонирован на нескольких машинах, то global .gitignore должен быть загружен на все машины или, по крайней мере, включать его, так как игнорируемые файлы будут помещены в репозиторий, в то время как компьютер с global .gitignore не обновит его. Вот почему конкретный репо .gitignore - лучшая идея, чем глобальная, если над проектом работает команда
Этот файл является хорошим местом для игнорирования платформы, компьютера или конкретного пользователя, например, OSX .DS_Store, Windows Thumbs.db или Vim *.ext ~ и *.ext.swp игнорируют, если вы не хотите хранить их в хранилище. Таким образом, один член команды, работающий над OS X, может добавить all .DS_STORE и _MAC OS X (что на самом деле бесполезно), в то время как другой член команды в Windows может игнорировать все thumbs.bd
Раздел 5.5: Игнорируйте файлы, которые уже были зафиксированы в репозитории Git
Если вы уже добавили файл в свой репозиторий Git и теперь хотите прекратить его отслеживание (чтобы он не присутствовал в будущих фиксациях), вы можете удалить его из индекса:
git rm --cached <file>
Это удалит файл из репозитория и предотвратит отслеживание дальнейших изменений Git. Параметр --cached гарантирует, что файл физически не будет удален.
Обратите внимание, что ранее добавленное содержимое файла по-прежнему будет видно в истории Git.
Имейте в виду, что если кто-либо еще извлечет файл из хранилища после того, как вы удалили файл из индекса, его копия будет физически удалена.
Вы можете сделать вид, что версия файла в рабочем каталоге обновлена, и вместо этого прочитать версию индекса (таким образом, игнорируя изменения в нем) с помощью бита "пропустить рабочее дерево".:
git update-index --skip-worktree <file>
Этот бит не влияет на написание, безопасность контента по-прежнему является первоочередной задачей. Вы никогда не потеряете свои драгоценные проигнорированные изменения; с другой стороны, этот бит конфликтует с сохранением: чтобы удалить этот бит, используйте
git update-index --no-skip-worktree <file>
Иногда ошибочно рекомендуется лгать Git и заставлять его предполагать, что файл не изменился, не изучая его. На первый взгляд это выглядит как игнорирование любых дальнейших изменений в файле, без удаления его из индекса:
git update-index --assume-unchanged <file>
Это заставит git игнорировать любые изменения, внесенные в файл (имейте в виду, что если вы внесете какие-либо изменения в этот файл или спрячете его, ваши проигнорированные изменения будут потеряны)
Если вы хотите, чтобы git снова "позаботился" об этом файле, выполните следующую команду:
git update-index --no-assume-unchanged <file>
Раздел 5.6: Игнорировать файлы локально без фиксации правил игнорирования
.gitignore игнорирует файлы локально, но он предназначен для фиксации в репозитории и совместного использования с другими участниками и пользователями. Вы можете установить глобальный .gitignore, но тогда все ваши репозитории будут совместно использовать эти настройки.
Если вы хотите игнорировать определенные файлы в репозитории локально и не делать файл частью какого-либо репозитория, отредактируйте файл .git/info/exclude внутри своего репозитория.
Например:
# эти файлы игнорируются только в этом отчете
# эти правила никому не сообщаются
# поскольку они являются личными
gtk_tests.py
gui/gtk/tests/*
localhost
pushReports.py
server/
Раздел 5.7: Игнорирование последующих изменений в файле (без его удаления)
Иногда вы хотите, чтобы файл хранился в Git, но игнорировали последующие изменения.
Попросите Git игнорировать изменения в файле или каталоге с помощью update-index:
git update-index --assume-unchanged my-file.txt
Приведенная выше команда предписывает Git предположить my-file.txt не было изменено, и не для того, чтобы проверять или сообщать об изменениях. Файл все еще присутствует в репозитории.
Это может быть полезно для предоставления значений по умолчанию и разрешения переопределений локальной среды, например:
# создайте файл с некоторыми значениями в
cat <<EOF
MYSQL_USER=app
MYSQL_PASSWORD=FIXME_SECRET_PASSWORD
EOF > .env
# обязательство перед Git
git add .env
git commit -m "Добавление шаблона .env"
# игнорировать будущие изменения в .environmental
git update-index --assume-unchanged .env
# обновите свой пароль
vi .env
# никаких изменений!
git status
Раздел 5.8: Игнорирование файла в любом каталоге
Чтобы игнорировать файл foo.txt в любом каталоге вы должны просто написать его название:
foo.txt # соответствует всем файлам 'foo.txt ' в любом справочнике
Если вы хотите игнорировать файл только в части дерева, вы можете указать подкаталоги определенного каталога с шаблоном **:
bar/**/foo.txt # соответствует всем файлам 'foo.txt "в "баре" и во всех подкаталогах
Или вы можете создать файл .gitignore в каталоге bar/. Эквивалентом предыдущего примера было бы создание файла bar/.gitignore с этим содержимым:
foo.txt # соответствует всем файлам 'foo.txt ' в любом каталоге под var/
Раздел 5.9: Предварительно заполненные шаблоны .gitignore
Если вы не уверены, какие правила следует перечислить в вашем файле .gitignore, или вы просто хотите добавить общепринятые исключения в свой проект, вы можете выбрать или создать файл .gitignore:
Многие сервисы хостинга, такие как GitHub и BitBucket, предлагают возможность создавать файлы .gitignore на основе языков программирования и IDE, которые вы можете использовать:
Раздел 5.10: Игнорирование файлов во вложенных папках (несколько файлов gitignore)
Предположим, у вас есть такая структура репозитория:
Есть два способа игнорировать этот файл. Вы можете поместить абсолютный путь в файл .gitignore в корне рабочего каталога:
# /.gitignore
src/output.log
В качестве альтернативы вы можете создать файл .gitignore в каталоге src/ и игнорировать файл, относящийся к этому .gitignore:
# /src/.gitignore
output.log
Раздел 5.11: Создайте пустую папку
Невозможно добавить и зафиксировать пустую папку в Git из-за того, что Git управляет файлами и прикрепляет к ним их каталог, что уменьшает количество фиксаций и повышает скорость. Чтобы обойти это, есть два способа:
Способ первый: .gitkeep
Один из способов обойти это - использовать файл .gitkeep для регистрации папки для Git. Для этого просто создайте необходимый каталог и добавьте в него файл .gitkeep. Этот файл пустой и не служит никакой другой цели, кроме как просто зарегистрировать папку. Чтобы сделать это в Windows (которая имеет неудобные соглашения об именовании файлов), просто откройте git bash в директории и выполните команду:
$ touch .gitkeep
Эта команда просто создает пустой файл .gitkeep в текущем каталоге
Способ второй: dummy.txt
Другой хак для этого очень похож на описанный выше, и можно выполнить те же шаги, но вместо .gitkeep просто используйте dummy.txt вместо этого. Это дает дополнительный бонус в виде возможности легко создавать его в Windows с помощью контекстного меню. И вы тоже можете оставлять в них забавные сообщения.Вы также можете использовать файл .gitkeep для отслеживания пустого каталога. .gitkeep обычно представляет собой пустой файл, который добавляется для отслеживания пустого каталога.
Раздел 5.12: Поиск файлов, игнорируемых .gitignore
Вы можете перечислить все файлы, игнорируемые git, в текущем каталоге с помощью команды:
git status --ignored
Итак, если у нас есть такая структура репозитория:
.git
.gitignore
./example_1
./dir/example_2
./example_2
...и .gitignore файл, содержащий:
example_2
...чем результат выполнения команды будет:
$ git status --ignored
Результат будет выглядеть так:
Иногда вам может потребоваться внести локальные изменения в файл, который вы не хотите фиксировать или публиковать. В идеале локальные настройки должны быть сосредоточены в отдельном файле, который можно поместить в файл .gitignore, но иногда в качестве краткосрочного решения может быть полезно иметь что-то локальное в зарегистрированном файле.
Вы можете заставить Git "не видеть" эти строки, используя чистый фильтр. Они даже не появятся в диффах.
Предположим, что здесь приведен фрагмент из файла file1.c:
Создайте фильтр "без фиксации", добавив его в файл конфигурации Git, например .git/config:
[filter "nocommit"]
clean=grep -v NOCOMMIT
Добавьте (или создайте) это в .git/info/атрибуты или .gitмодули:
file1.c filter=nocommit
И ваши строки NOCOMMIT скрыты от Git.
Предостережения:
Использование чистого фильтра замедляет обработку файлов, особенно в Windows.
Игнорируемая строка может исчезнуть из файла, когда Git обновит ее. Этому можно противостоять с помощью фильтра размазывания, но это сложнее.
Не тестировался в Windows
Раздел 5.14: Игнорирование изменений в отслеживаемых файлах. [stub]
Чтобы установить флаг игнорирования для отслеживаемого файла, используйте команду
git update-index --skip-worktree myfile.c
Чтобы отменить это, используйте:
git update-index --no-skip-worktree myfile.c
Вы можете добавить этот фрагмент в свою глобальную
[alias]
hide = update-index --skip-worktree
unhide = update-index --no-skip-worktree
hidden = "!git ls-files -v | grep ^[hsS] | cut -c 3-"
Вы также можете использовать опцию --предположить-без изменений с помощью функции update-index
git update-index --assume-unchanged <file>
Если вы хотите еще раз просмотреть этот файл на предмет изменений, используйте
git update-index --no-assume-unchanged <file>
Когда указан флаг --assume-unchanged , пользователь обещает не изменять файл и позволяет Git предполагать, что файл рабочего дерева соответствует тому, что записано в индексе.Git потерпит неудачу в случае, если ему потребуется изменить этот файл в индексе, например, при слиянии в фиксации; таким образом, в случае, если предполагаемый неотслеживаемый файл будет изменен вверх по течению, вам нужно будет справиться с ситуацией вручную. В данном случае основное внимание уделяется производительности.
В то время как флаг --skip-worktree полезен, когда вы даете указание git никогда не прикасаться к определенному файлу, потому что файл будет изменен локально, и вы не хотите случайно зафиксировать изменения (т. е. файл конфигурации/свойств, настроенный для определенной среды). Пропустить-рабочее дерево имеет приоритет над предполагать неизменным, когда оба заданы.
Раздел 5.15: Очистить уже зафиксированные файлы, но включенные в .gitignore
Иногда случается, что файл отслеживался git, но в более поздний момент времени был добавлен в .gitignore, чтобы прекратить его отслеживание. Это очень распространенный сценарий, когда забывают очистить такие файлы перед их добавлением в .gitignore.
В этом случае старый файл все еще будет висеть в хранилище.
Чтобы устранить эту проблему, можно было бы выполнить "пробное" удаление всего, что находится в репозитории, с последующим повторным добавлением всех файлов обратно. Пока у вас нет ожидающих изменений и передан параметр -cached, эта команда достаточно безопасна для выполнения:
# Удалить все из индекса (файлы останутся в файловой системе)
$ git rm -r --cached .
# Повторно добавьте все (они будут добавлены в текущем состоянии, включая изменения)
$ git add .
# Зафиксировать, если что-то изменилось. Вы должны видеть только удаления
$ git commit -m "Удалите все файлы, которые находятся в .gitignore"
# Обновите пульт дистанционного управления
$ git push origin master
Раздел 6.1: Показать различия в рабочей ветви
git diff
Это покажет нестационарные изменения в текущей ветке с момента фиксации до нее. Он будет показывать только изменения относительно индекса, то есть он показывает, что вы могли бы добавить в следующую фиксацию, но не сделали этого. Чтобы добавить (поэтапно) эти изменения, вы можете использовать git add.
Если файл является промежуточным, но был изменен после его подготовки, git diff покажет различия между текущим файлом и промежуточной версией.
Раздел 6.2: Показать изменения между двумя фиксациями
git diff 1234abc..6789def
Например: Показать изменения, внесенные в последние 3 коммита:
git diff @~3..@
Примечание: две точки (..) необязательны, но добавляют ясности.
Это покажет текстовую разницу между фиксациями, независимо от того, где они находятся в дереве.
Раздел 6.3: Показать различия для поэтапных файлов
git diff --staged
Это покажет изменения между предыдущей фиксацией и текущими промежуточными файлами.
ПРИМЕЧАНИЕ: Вы также можете использовать следующие команды для выполнения того же самого:
git diff --cached
Что является просто синонимом --staged или git status -v
Который вызовет подробные настройки команды statusd.
Раздел 6.4: Сравнение филиалов
Показать изменения между наконечником нового и наконечником оригинального:
git diff original new #эквивалент оригиналу..новый
Показать все изменения на новом, так как он разветвился от оригинала:
git diff original...new #эквивалентно $(git merge - исходная новая база)..новый
Использование только одного параметра, такого как
git diff original,
эквивалентно
git diff original..HEAD
Раздел 6.5: Показать как поэтапные, так и нестационарные изменения
Чтобы отобразить все поэтапные и нестационарные изменения, используйте:
git diff HEAD
ПРИМЕЧАНИЕ: Вы также можете использовать следующую команду:
git status -vv
Разница в том, что вывод последнего фактически сообщит вам, какие изменения подготовлены для фиксации, а какие нет.
Дата выпуска версии:
2.13 2017-05-10
2.12 2017-02-24
2.11.1 2017-02-02
2.11 2016-11-29
2.10.2 2016-10-28
2.10 2016-09-02
2.9 2016-06-13
2.8 2016-03-28
2.7 2015-10-04
2.6 2015-09-28
2.5 2015-07-27
2.4 2015-04-30
2.3 2015-02-05
2.2 2014-11-26
2.1 2014-08-16
2.0 2014-05-28
1.9 2014-02-14
1.8.3 2013-05-24
1.8 2012-10-21
1.7.10 2012-04-06
1.7 2010-02-13
1.6.5 2009-10-10
1.6.3 2009-05-07
1.6 2008-08-17
1.5.3 2007-09-02
1.5 2007-02-14
1.4 2006-06-10
1.3 2006-04-18
1.2 2006-02-12
1.1 2006-01-08
1.0 2005-12-21
0.99 2005-07-11
Раздел 1.1: Создайте свой первый репозиторий, затем добавьте и зафиксируйте файлы
В командной строке сначала убедитесь, что у вас установлен Git:
На всех операционных системах:
git --version
В UNIX-подобных операционных системах:
which git
Если ничего не возвращено или команда не распознана, возможно, вам придется установить Git в вашей системе, загрузив и запустив установщик. Смотрите домашнюю страницу Git для получения исключительно четких и простых инструкций по установке.
После установки Git настройте свое имя пользователя и адрес электронной почты. Сделайте это, прежде чем брать на себя обязательства.
После установки Git перейдите в каталог, который вы хотите поместить под управление версиями, и создайте пустое хранилище Git:
git init
Это создает скрытую папку .git, в которой содержится сантехника, необходимая для работы Git
Затем проверьте, какие файлы Git добавит в ваш новый репозиторий; этот шаг заслуживает особого внимания:
git status
Просмотрите полученный список файлов; вы можете указать Git, какие файлы следует поместить в систему управления версиями (избегайте добавления файлов с конфиденциальной информацией, такой как пароли, или файлов, которые просто загромождают репозиторий):
git add <file/directory name #1> <file/directory name #2> < ... >
Если все файлы в списке должны быть доступны всем, у кого есть доступ к хранилищу, одна команда добавит все в ваш текущий каталог и его подкаталоги:
git add .
Это "этапирует" все файлы, которые будут добавлены в систему управления версиями, подготавливая их к фиксации в вашей первой фиксации.
Для файлов, которые вы не хотите использовать под контролем версий, создайте и заполните файл с именем .gitignore перед выполнением команды добавить.
Зафиксируйте все добавленные файлы вместе с сообщением о фиксации:
git commit -m "Initial commit"
Это создает новую фиксацию с данным сообщением. Фиксация похожа на сохранение или снимок всего вашего проекта. Теперь вы можете отправить или загрузить его в удаленное хранилище, а затем при необходимости вернуться к нему. Если вы опустите параметр -m, откроется редактор по умолчанию, в котором вы сможете отредактировать и сохранить сообщение о фиксации.
Добавление удаленного
Чтобы добавить новый пульт дистанционного управления, используйте команду git remote add на терминале, в каталоге, в котором хранится ваш репозиторий.
Команда удаленного добавления git принимает два аргумента:
Команда добавления git remote принимает два аргумента:
1. Удаленное имя, например, origin
2. Удаленный URL-адрес, например, https://<адрес вашей службы git>/пользователь/repo.git
git remote добавить origin https://<ваш-git-адрес службы>/владелец/репозиторий.git
ПРИМЕЧАНИЕ: Перед добавлением пульта дистанционного управления вам необходимо создать необходимый репозиторий в своей службе git, вы сможете отправлять / извлекать коммиты после добавления пульта дистанционного управления
Раздел 1.2: Клонирование репозитория
Команда git clone используется для копирования существующего репозитория Git с сервера на локальную машину.
Например, для клонирования проекта GitHub:
cd <путь, по которому вы хотите, чтобы клон создал каталог>
git clone
Пожалуйста, авторизуйтесь для просмотра ссылки.
Чтобы клонировать проект BitBucket:
cd <путь, по которому вы хотите, чтобы клон создал каталог>
git clone
Пожалуйста, авторизуйтесь для просмотра ссылки.
Это создает каталог с именем проекта на локальном компьютере, содержащий все файлы в удаленном репозитории Git. Это включает в себя исходные файлы для проекта, а также подкаталог .git, который содержит всю историю и конфигурацию проекта.
Чтобы указать другое имя каталога, например MyFolder:
git clone
Пожалуйста, авторизуйтесь для просмотра ссылки.
MyFolderИли клонировать в текущем каталоге:
git clone
Пожалуйста, авторизуйтесь для просмотра ссылки.
.Примечание:
1. При клонировании в указанный каталог каталог должен быть пустым или отсутствовать.
2. Вы также можете использовать ssh-версию команды:
git clone git@github.com:username/projectname.git
Версия https и версия ssh эквивалентны. Однако некоторые службы хостинга, такие как GitHub, рекомендуют использовать https, а не ssh.
Раздел 1.3: Общий код
Чтобы поделиться своим кодом, вы создаете репозиторий на удаленном сервере, на который вы скопируете свой локальный репозиторий.
Чтобы свести к минимуму использование пространства на удаленном сервере, вы создаете пустой репозиторий: тот, который содержит только объекты .git и не создает рабочую копию в файловой системе. В качестве бонуса вы устанавливаете этот удаленный сервер в качестве вышестоящего сервера, чтобы легко обмениваться обновлениями с другими программистами.
На удаленном сервере:
git init --bare /path/to/repo.git
На локальном компьютере:
git remote add origin ssh://username@server:/path/to/repo.git
(Обратите внимание, что ssh: это всего лишь один из возможных способов доступа к удаленному хранилищу.)
Теперь скопируйте свой локальный репозиторий на удаленный:
git push --set-upstream origin master
Добавление --set-upstream (или -u) создало ссылку на восходящий поток (отслеживание), которая используется командами Git без аргументов, например, git pull.
Раздел 1.4: Настройка имени пользователя и электронной почты
Вам нужно установить, кто вы, прежде чем создавать какие-либо фиксации. Это позволит коммитам иметь правильное имя автора и адрес электронной почты, связанные с ними.
Это не имеет ничего общего с аутентификацией при отправке в удаленное хранилище (например, при отправке в удаленное хранилище с помощью вашей учетной записи GitHub, BitBucket или GitLab)
Чтобы объявить эту идентификацию для всех репозиториев, используйте git config --global
Это сохранит настройки в файле .gitconfig вашего пользователя: например, $HOME/.gitconfig или для Windows, %USERPROFILE%\.gitconfig.
git config --global user.name "Your Name"
git config --global user.email mail@example.com
Чтобы объявить идентификатор для одного репозитория, используйте git config внутри репозитория.
Это сохранит настройку внутри отдельного репозитория в файле $GIT_DIR/config. например, /путь/к/вашему/репозиторию/.git/config.
cd /путь/к/моему/репозиторию
git config user.name "Your Login At Work"
git config user.email mail_at_work@example.com
Настройки, хранящиеся в файле конфигурации репозитория, будут иметь приоритет над глобальной конфигурацией при использовании этого репозитория.
Советы: если у вас разные идентификаторы (один для проекта с открытым исходным кодом, один на работе, один для частных репозиториев, ...), и вы не хотите забывать устанавливать правильный для каждого отдельного репозитория, над которым вы работаете:
Удалить глобальную идентификацию
git config --global --remove-section user.name
git config --global --remove-section user.email
Версия ≥ 2.8
Чтобы заставить git искать вашу личность только в настройках репозитория, а не в глобальной конфигурации:
git config --global user.useConfigOnly true
Таким образом, если вы забудете установить свой user.name и user.email для данного репозитория и попытайтесь совершить фиксацию, вы увидите:
имя не было указано, и автоматическое обнаружение отключено
адрес электронной почты не был указан, и автоматическое обнаружение отключено
Раздел 1.5: Настройка вышестоящего пульта дистанционного управления
Если вы клонировали форк (например, проект с открытым исходным кодом на Github), у вас может не быть принудительного доступа к вышестоящему репозиторию, поэтому вам нужны оба форка, но вы можете получить доступ к вышестоящему репозиторию.
Сначала проверьте удаленные имена:
$ git remote -v
origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(fetch)origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(push)upstream # эта строка может быть здесь, а может и не быть
Если upstream уже существует (он есть в некоторых версиях Git), вам нужно установить URL-адрес (в настоящее время он пуст):
$ git remote set-url upstream
Пожалуйста, авторизуйтесь для просмотра ссылки.
Если восходящего потока нет, или если вы также хотите добавить вилку друга / коллеги (в настоящее время их не существует):
$ git remote add upstream
Пожалуйста, авторизуйтесь для просмотра ссылки.
$ git remote add dave
Пожалуйста, авторизуйтесь для просмотра ссылки.
Раздел 1.6: Изучение команды
Чтобы получить дополнительную информацию о любой команде git, т.е. подробную информацию о том, что делает команда, доступных параметрах и другой документации, используйте опцию --help или команду help.
Например, чтобы получить всю доступную информацию о команде git diff, используйте:
git diff --help
git help diff
Аналогично, чтобы получить всю доступную информацию о команде status, используйте:
git status --help
git help status
Если вам нужна только краткая справка, показывающая значение наиболее часто используемых флагов командной строки, используйте -h:
git checkout -h
Раздел 1.7: Настройка SSH для Git
Если вы используете Windows, откройте Git Bash. Если вы используете Mac или Linux, откройте свой терминал.
Прежде чем сгенерировать SSH-ключ, вы можете проверить, есть ли у вас какие-либо существующие SSH-ключи.
Перечислите содержимое вашего каталога ~/.ssh:
$ ls -al ~/.ssh
# Перечисляет все файлы в вашем каталоге ~/.ssh
Проверьте список каталогов, чтобы узнать, есть ли у вас уже открытый SSH-ключ. По умолчанию имена файлов открытых ключей являются одним из следующих:
id_dsa.pub
id_ecdsa.pub
id_ed25519.pub
id_rsa.pub
Если вы видите в списке существующую пару открытых и закрытых ключей, которую вы хотели бы использовать в своей учетной записи Bitbucket, GitHub (или аналогичной), вы можете скопировать содержимое файла id_*.pub.
Если нет, вы можете создать новую пару открытого и закрытого ключей с помощью следующей команды:
$ ssh-keygen
Нажмите клавишу Ввода или возврата, чтобы принять расположение по умолчанию. Введите и повторно введите кодовую фразу при появлении запроса или оставьте ее пустой.
Убедитесь, что ваш SSH-ключ добавлен в ssh-агент. Запустите ssh-агент в фоновом режиме, если он еще не запущен:
$ eval "$(ssh-agent -s)"
Добавьте свой SSH-ключ в ssh-агент. Обратите внимание, что вам нужно будет заменить id_rsa в команде именем вашего файла закрытого ключа:
$ ssh-add ~/.ssh/id_rsa
Если вы хотите изменить восходящий поток существующего репозитория с HTTPS на SSH, вы можете выполнить следующую команду:
$ git remote set-url origin ssh://git@bitbucket.server.com:7999/projects/your_project.git
Чтобы клонировать новый репозиторий по SSH, вы можете выполнить следующую команду:
$ git clone ssh://git@bitbucket.server.com:7999/projects/your_proje
Раздел 1.8: Установка Git
Давайте займемся использованием какого-нибудь мерзавца. Перво-наперво - вы должны его установить. Вы можете получить его несколькими способами; два основных из них - установить его из исходного кода или установить существующий пакет для вашей платформы.
Установка из исходного кода
Если вы можете, обычно полезно установить Git из исходного кода, потому что вы получите самую последнюю версию. Каждая версия Git, как правило, включает полезные улучшения пользовательского интерфейса, поэтому получение последней версии часто является лучшим способом, если вы чувствуете себя комфортно при компиляции программного обеспечения из исходного кода. Это также тот случай, когда многие дистрибутивы Linux содержат очень старые пакеты; поэтому, если вы не используете очень современный дистрибутив или не используете бэкпорты, установка из исходного кода может быть лучшим выбором.
Чтобы установить Git, вам необходимо иметь следующие библиотеки, от которых зависит Git: curl, zlib, openssl, expat и libiconv. Например, если вы находитесь в системе, в которой есть yum (например, Fedora) или apt-get (например, система на базе Debian), вы можете использовать одну из этих команд для установки всех зависимостей:
$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev
Когда у вас будут все необходимые зависимости, вы можете продолжить и получить последний снимок с веб-сайта Git:
Пожалуйста, авторизуйтесь для просмотра ссылки.
Затем скомпилируйте и установите:$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
После того, как это будет сделано, вы также можете получить Git через сам Git для обновлений:
$ git clone git://git.kernel.org/pub/scm/git/git.git
Установка в Linux
Если вы хотите установить Git в Linux с помощью двоичного установщика, вы обычно можете сделать это с помощью базового инструмента управления пакетами, который поставляется с вашим дистрибутивом. Если вы используете Fedora, вы можете использовать yum:
$ yum install git
Или, если вы используете дистрибутив на основе Debian, такой как Ubuntu, попробуйте apt-get:
$ apt-get install git
Установка на Mac
Существует три простых способа установки Git на Mac. Проще всего использовать графический установщик Git, который вы можете скачать со страницы SourceForge.
Пожалуйста, авторизуйтесь для просмотра ссылки.
Рисунок 1-7. Установщик Git OS X. Другой важный способ - установить Git через MacPorts (
Пожалуйста, авторизуйтесь для просмотра ссылки.
). Если у вас установлен MacPorts, установите Git через$ sudo port install git +svn +doc +bash_completion +gitweb
Вам не нужно добавлять все дополнительные функции, но вы, вероятно, захотите включить +svn на случай, если вам когда-нибудь придется использовать Git с репозиториями Subversion
Домашнее пиво (
Пожалуйста, авторизуйтесь для просмотра ссылки.
/) является еще одной альтернативой установке Git. Если у вас установлен Homebrew, установите Git через$ brew install git
Установка в Windows
Установить Git в Windows очень просто. Проект msysGit имеет одну из самых простых процедур установки. Просто скачайте exe-файл установщика со страницы GitHub и запустите его:
Пожалуйста, авторизуйтесь для просмотра ссылки.
После его установки у вас будет как версия командной строки (включая SSH-клиент, который пригодится позже), так и стандартный графический интерфейс.
Примечание по использованию Windows: вы должны использовать Git с предоставленной оболочкой msysGit (в стиле UNIX), она позволяет использовать сложные строки команд, приведенные в этой книге. Если вам по какой-либо причине нужно использовать собственную оболочку Windows / консоль командной строки, вы должны использовать двойные кавычки вместо одинарных кавычек (для параметров с пробелами в них), и вы должны указывать параметры, заканчивающиеся знаком окружности (^), если они последние в строке, так как это символ продолжения в Windows.
Глава 2: Просмотр истории
Параметр | Объяснение |
| -q, --quiet | Тихий, подавляет выход diff |
| --source | Показывает источник фиксации |
| --use-mailmap | Используйте файл карты почты (изменяет информацию о пользователе для фиксации пользователя) |
| --decorate[=...] | Варианты украшения |
| --L <n,m:file> | Показывать журнал для определенного диапазона строк в файле, считая от 1. Начинается со строки n, переходит в строку m. Также показывает другое. |
| --show-signature | Отображение подписей подписанных коммитов |
| -i, --regexp-ignore-case | Сопоставьте шаблоны ограничения регулярных выражений без учета регистра букв |
Раздел 2.1: "Обычный" журнал Git
git log
Отобразит все ваши коммиты с автором и хэшем. Это будет показано в нескольких строках для каждой фиксации. ((Если вы хотите показать одну строку за фиксацию, посмотрите на одну подкладку). Используйте клавишу q для выхода из журнала.
По умолчанию, без аргументов, в журнале git перечисляются коммиты, сделанные в этом репозитории, в обратном хронологическом порядке, то есть сначала отображаются самые последние коммиты. Как вы можете видеть, эта команда перечисляет каждую фиксацию с контрольной суммой SHA-1, именем автора и электронной почтой, датой написания и сообщением о фиксации. - источник
Пример (из репозитория freeCodeCamp):
Если вы хотите ограничить свою команду журналом последних n фиксаций, вы можете просто передать параметр. Например, если вы хотите перечислить последние 2 журнала фиксаций
git log -2
Раздел 2.2: Более красивый журнал
Чтобы увидеть журнал в более красивой графической структуре, используйте:
git log --decorate --oneline --graph
Пример вывода :
Поскольку это довольно большая команда, вы можете назначить псевдоним:
git config --global alias.lol "log --decorate --oneline --graph"
Чтобы использовать версию псевдонима:
# история текущей ветви :
git lol
# объединенная история активной ветви (ГОЛОВНОЙ), ветвей разработки и происхождения/основных ветвей :
git lol HEAD develop origin/master
# объединенная история всего, что находится в вашем репо :
git lol --all
Раздел 2.3: Раскрашивание журналов
git log --graph --pretty=format:'%C(red)%h%Creset -%C(yellow)%d%Creset %s %C(green)(%cr) %C(yellow)<%an>%Creset
Опция Формат позволяет вам указать свой собственный формат вывода журнала:
Параметр | Подробности |
| %C(color_name) | опция окрашивает вывод, который следует за ней |
| %h or %H | сокращает хэш фиксации (используйте %H для полного хэша) |
| %Creset | сбрасывает цвет до цвета терминала по умолчанию |
| %d | имена ссылок |
| %s | тема [сообщение о фиксации] |
| %cr | дата фиксатора, относительно текущей даты |
| %an | имя автора |
Раздел 2.4: Онлайн-журнал
git log --oneline
Покажет все ваши коммиты только с первой частью хэша и сообщением о фиксации. Каждая фиксация будет в одной строке, как предполагает флаг одной строки.
Опция oneline выводит каждую фиксацию в одной строке, что полезно, если вы просматриваете много фиксаций. - источник
Пример (из репозитория freeCodeCamp, с тем же разделом кода из другого примера):
Если вы хотите ограничить свою команду журналом последних n фиксаций, вы можете просто передать параметр. Например, если вы хотите перечислить последние 2 журнала фиксаций
git log -2 --oneline
Раздел 2.5: Поиск в журнале
git log -S"#define SAMPLES"
Выполняет поиск добавления или удаления определенной строки или строки, соответствующей предоставленному регулярному выражению. В этом случае мы ищем добавление/удаление строки #define SAMPLES. Например:
+#define SAMPLES 100000
или
-#define SAMPLES 100000
git log -G"#define SAMPLES"
Выполняет поиск изменений в строках, содержащих определенную строку или строку, соответствующую предоставленному регулярному выражению. Например:
-#define SAMPLES 100000
+#define SAMPLES 100000000
Раздел 2.6: Перечислите все материалы, сгруппированные по имени автора
git shortlog обобщает git log и группирует по авторам
Если параметры не указаны, список всех коммитов, сделанных для каждого комитета, будет показан в хронологическом порядке
Чтобы просто увидеть количество фиксаций и подавить описание фиксации, введите параметр сводка:
-s
--summary
$ git shortlog -s
Committer 1
Committer 2
Чтобы отсортировать выходные данные по количеству фиксаций, а не по алфавиту по названию комитета, введите параметр с номером:
-n
--numbered
Чтобы добавить адрес электронной почты комитета, добавьте опцию электронной почты:
-e
Также можно указать параметр пользовательского формата, если вы хотите отображать информацию, отличную от темы фиксации:
--format
Это может быть любая строка, принятая параметром --format в git log.
Дополнительные сведения об этом см. в разделе "Раскрашивание журналов" выше.
Раздел 2.7: Поиск строки фиксации в журнале git
Поиск в журнале git с использованием некоторой строки в журнале:
git log [options] --grep "search_string"
Пример:
git log --all --grep "removed file"
Будет искать удаленную строку файла во всех журналах во всех ветвях.
Начиная с git 2.4+, поиск можно инвертировать с помощью опции --invert-grep .
Пример:
git log --grep="add file" --invert-grep
Покажет все коммиты, которые не содержат файла добавления.
Раздел 2.8: Ведение журнала для диапазона строк в файле
Раздел 2.9: Фильтрация журналов
git log --after '3 days ago'
Конкретные даты тоже работают:
git log --after 2016-05-01
Как и в случае с другими командами и флагами, которые принимают параметр даты, разрешенный формат даты поддерживается GNU date (очень гибкий).
Псевдоним --after - это --since.
Флаги существуют и для обратного: --before и --until.
Вы также можете фильтровать журналы по авторам. например
git log --author=author
Раздел 2.10: Журнал с изменениями в строке
Чтобы просмотреть журнал с изменениями в строке, используйте параметры -por --patch.
git log --patch
Пример (из репозитория Trello Scientist)
Раздел 2.11: Журнал, показывающий зарегистрированные файлы
git log --stat
Пример:
Раздел 2.12: Показать содержимое одного коммита
Используя git show, мы можем просмотреть один коммит
git show 48c83b3
git show 48c83b3690dfc7b0e622fd220f8f37c26a77c934
Пример:
Раздел 2.13: Журнал Git Между Двумя Ветвями
git log master..foo покажет коммиты, которые находятся на foo, а не на master. Полезно посмотреть, какие коммиты вы добавили с момента ветвления!
Раздел 2.14: Одна строка, показывающая имя участника и время с момента совершения
tree = log --oneline --decorate --source --pretty=format:'"%Cblue %h %Cgreen %ar %Cblue %an %C(yellow) %d %Creset %s"' --all --graph
Пример:
Глава 3: Работа с удаленными устройствами
Чтобы удалить удаленную ветвь в Git:
git push [remote-name] --delete [branch-name]
или
git push [remote-name] :[branch-name]
Раздел 3.2: Изменение удаленного URL-адреса Git
Проверьте существующий пульт дистанционного управления
git remote -v
# origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(fetch) # origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(push)Изменение URL-адреса репозитория
git remote set-url origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
# # Измените удаленный URL-адрес источника
Проверьте новый удаленный URL-адрес
git remote -v
# origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(fetch) # origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(push)Раздел 3.3: Список Существующих Пультов Дистанционного Управления
Перечислите все существующие удаленные устройства, связанные с этим хранилищем:
git remote
Подробно перечислите все существующие удаленные устройства, связанные с этим хранилищем, включая URL-адреса для извлечения и отправки:
git remote --verbose
или просто
git remote -v
Раздел 3.4. Удаление локальных копий удаленных удаленных филиалов
Если удаленная ветвь была удалена, необходимо указать вашему локальному репозиторию, чтобы он удалил ссылку на нее.
Чтобы обрезать удаленные ветви с определенного удаленного:
git fetch [remote-name] --prune
Чтобы обрезать удаленные ветви со всех удаленных устройств:
git fetch --all --prune
Раздел 3.5: Обновление из вышестоящего репозитория
Предполагая, что вы установили восходящий поток (как в разделе "настройка восходящего репозитория")
git fetch remote-name
git merge remote-name/branch-name
Команда pull объединяет выборку и слияние.
git pull
Команда pull с флагом --rebase объединяет выборку и перебазирование вместо слияния.
git pull --rebase remote-name branch-name
Раздел 3.6: ls-пульт дистанционного управления
git ls-remote - это уникальная команда, позволяющая запрашивать удаленное репозиторий без необходимости его клонирования / извлечения
В нем будут перечислены ссылки / заголовки и ссылки / теги указанного удаленного репо.
Иногда вы увидите ссылки/теги/v0.1.6 и ссылки/теги/v0.1.6 ^{}: ^{} для перечисления разыменованного аннотированного тега (т.Е. фиксации, на которую указывает тег)
Начиная с git 2.8 (март 2016 г.), вы можете избежать этой двойной записи для тега и напрямую перечислить разыменованные теги с помощью:
git ls-remote --ref
Это также может помочь решить фактический URL-адрес, используемый удаленным репозиторием, если у вас есть настройка конфигурации "url.<база>.вместо". Если git remote --set-url <удаленное имя> возвращает
Пожалуйста, авторизуйтесь для просмотра ссылки.
, и вы установили git config url.ssh://git@server.com:.insteadOf
Пожалуйста, авторизуйтесь для просмотра ссылки.
:git ls-remote --get-url
ssh://git@server.com:user/repo
Раздел 3.7. Добавление нового удаленного хранилища
git remote add upstream git-repository-url
Добавляет удаленный репозиторий git, представленный URL-адресом репозитория git, в качестве нового удаленного хранилища с именем вверх по течению в репозиторий git
Раздел 3.8: Установка вверх по течению на новой ветке
Вы можете создать новую ветвь и переключиться на нее с помощью
git checkout -b AP-57
После того, как вы используете git checkout для создания новой ветви, вам нужно будет указать, что источник восходящего потока будет использоваться
git push --set-upstream origin AP-57
После этого вы можете использовать git push, пока находитесь в этой ветке
Раздел 3.9: Начало работы
Синтаксис для отправки в удаленную ветвь
git push <remote_name> <branch_name>
Пример
git push origin master
Раздел 3.10: Переименование удаленного
Чтобы переименовать удаленный, используйте команду git remote rename
Команда удаленного переименования git принимает два аргумента:
Существующее удаленное имя, например : origin
Новое имя для удаленного устройства, например : destination
Получить существующее удаленное имя
git remote
# origin
Проверьте существующий пульт дистанционного управления с помощью URL
git remote -v
# origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(fetch) # origin
Пожалуйста, авторизуйтесь для просмотра ссылки.
(push)Переименование удаленного
git remote rename origin destination
# Измените удаленное имя с "origin" на "destination"
Подтвердите новое имя
git remote -v
# destination
Пожалуйста, авторизуйтесь для просмотра ссылки.
(fetch) # destination
Пожалуйста, авторизуйтесь для просмотра ссылки.
(push)====== Возможные ошибки ===
1. Не удалось переименовать раздел конфигурации "удаленный".[старое имя] "на "пульт дистанционного управления.[новое имя]'
Эта ошибка означает, что пульт дистанционного управления, на котором вы пытались использовать старое удаленное имя (источник), не существует.
2. Пульт дистанционного управления [новое имя] уже существует.
Сообщение об ошибке не требует пояснений.
Раздел 3.11: Отображение информации о конкретном удаленном устройстве
Выведите некоторую информацию об известном удаленном устройстве: origin
git remote show origin
Распечатайте только удаленный URL-адрес:
git config --get remote.origin.url
С 2.7+ это также возможно сделать, что, возможно, лучше, чем приведенное выше, в котором используется команда config.
git remote get-url origin
Раздел 3.12: Задайте URL-адрес для определенного удаленного
Вы можете изменить URL-адрес существующего удаленного устройства с помощью команды
git remote set-url remote-name url
Раздел 3.13. Получение URL-адреса для определенного удаленного
Вы можете получить URL-адрес существующего удаленного устройства с помощью команды
git remote get-url
По умолчанию это будет
git remote get-url origin
Раздел 3.14: Изменение удаленного хранилища
Чтобы изменить URL-адрес хранилища, на которое должен указывать ваш пульт дистанционного управления, вы можете использовать параметр set-url, например:
git remote set-url
Пример:
git remote set-url heroku
Пожалуйста, авторизуйтесь для просмотра ссылки.
Глава 4: Постановка
Раздел 4.1: Подготовка всех изменений в файлах
git add -A
Version ≥ 2.0
git add .
В версии 2.x git add . будет выполнять все изменения файлов в текущем каталоге и всех его подкаталогах. Однако в 1.x он будет отображать только новые и измененные файлы, а не удаленные файлы.
Используйте git add -A или эквивалентную команду git add --all, чтобы вносить все изменения в файлы в любой версии git.
Раздел 4.2: Удаление файла, содержащего изменения
git reset <filePath>
Раздел 4.3: Добавление изменений по частям
Вы можете увидеть, какие "куски" работы будут подготовлены для фиксации, используя флаг исправления:
git add -p
или
git add --patch
Откроется интерактивное приглашение, которое позволит вам просмотреть различия и решить, хотите ли вы включить их или нет.
Поставьте этот кусок [y, n, q, a, d,/, s, e,?]?
y | подготовьте этот кусок для следующего коммита |
n | не ставьте этот кусок для следующего коммита |
q | бросьте; не ставьте этот кусок или любой из оставшихся кусков |
a | поместите этот кусок и все последующие куски в файл |
d | не размещайте этот кусок или любой из более поздних кусков в файле |
g | выберите ломоть, чтобы перейти к |
/ | найдите кусок, соответствующий заданному регулярному выражению |
j | оставьте этот кусок нерешенным, посмотрите следующий нерешенный кусок |
J | оставьте этот кусок нерешенным, смотрите следующий кусок |
k | оставьте этот кусок нерешенным, см. Предыдущий нерешенный кусок |
| K | оставьте этот кусок нерешенным, см. Предыдущий кусок |
| s | разделите текущий кусок на более мелкие куски |
| e | вручную отредактируйте текущий кусок |
| ? | распечатайте справку по куску |
Это позволяет легко улавливать изменения, которые вы не хотите фиксировать.
Вы также можете открыть это с помощью git add --interactive и выбора свойств.
Раздел 4.4: Интерактивное добавление
git add -i (или --interactive) предоставит вам интерактивный интерфейс, в котором вы сможете редактировать индекс, чтобы подготовить то, что вы хотите иметь в следующем коммите. Вы можете добавлять и удалять изменения в целые файлы, добавлять неотслеживаемые файлы и удалять файлы из отслеживания, а также выбирать подраздел изменений для включения в индекс, выбирая фрагменты добавляемых изменений, разделяя эти фрагменты или даже редактируя разницу. Многие графические инструменты фиксации для Git (например, git gui) включают такую функцию; это может быть проще в использовании, чем версия командной строки.
Это очень полезно (1), если у вас есть запутанные изменения в рабочем каталоге, которые вы хотите поместить в отдельные фиксации, а не все в одну фиксацию (2), если вы находитесь в середине интерактивной перебазировки и хотите разделить слишком большую фиксацию.
В верхней половине этого вывода показано текущее состояние индекса, разбитого на поэтапные и нестационарные столбцы:
1. index.js было добавлено 4 строки и удалено 4 строки. В настоящее время он не поставлен, так как текущий статус сообщает "без изменений". Когда этот файл станет промежуточным, +4/-4, но будет перенесено в столбец промежуточный, а в неустановленном столбце будет указано "ничего".
2. в package.json была добавлена одна строка, и она была подготовлена. Дальнейших изменений нет, так как он был поэтапным, как указано в строке "ничего" под неустановленным столбцом.
Нижняя половина показывает, что вы можете сделать. Введите либо число (1-8), либо букву (s, u, r, a, p, d, q, h).
status показывает вывод, идентичный верхней части вывода выше.
update позволяет вносить дальнейшие изменения в поэтапные коммиты с дополнительным синтаксисом
revert вернет информацию о поэтапной фиксации обратно в НАЧАЛО.
add untracked позволяет добавлять пути к файлам, ранее не отслеживаемые системой управления версиями.
patch позволяет выбрать один путь из вывода, аналогичного статусу, для дальнейшего анализа.
diff отображает, что будет зафиксировано.
quit завершает выполнение команды.
help содержит дополнительную справку по использованию этой команды.
Раздел 4.5: Показать поэтапные изменения
Чтобы отобразить фрагменты, подготовленные для фиксации:
git diff --cached
Раздел 4.6. Размещение Одного Файла
Чтобы подготовить файл для фиксации, запустите
git add <filename>
Раздел 4.7: Этап удаления файлов
git rm filename
Чтобы удалить файл из git, не удаляя его с диска, используйте флаг --cached
git rm --cached filename
Глава 5. Игнорирование файлов и папок
В этом разделе показано, как избежать добавления нежелательных файлов (или изменений файлов) в репозиторий Git. Существует несколько способов (глобальный или локальный .gitignore, .git/exclude, git update-index --assume-unchanged и git update-index -- skip-tree ), но имейте в виду, что Git управляет содержимым, что означает: игнорирование фактически игнорирует содержимое папки (т.Е. файлы). Пустая папка по умолчанию игнорируется, так как ее все равно нельзя добавить.
Раздел 5.1: Игнорирование файлов и каталогов с помощью файла .gitignore
Вы можете заставить Git игнорировать определенные файлы и каталоги, то есть исключить их из отслеживания Git, создав один или несколько файлов .gitignore в своем репозитории.
В программных проектах .gitignore обычно содержит список файлов и/или каталогов, которые создаются в процессе сборки или во время выполнения. Записи в файле .gitignore могут включать имена или пути, указывающие на:
1. временные ресурсы, например, кэш, файлы журналов, скомпилированный код и т.д.
2. локальные файлы конфигурации, которыми не следует делиться с другими разработчиками
3. файлы, содержащие секретную информацию, такую как пароли для входа, ключи и учетные данные
При создании в каталоге верхнего уровня правила будут рекурсивно применяться ко всем файлам и подкаталогам во всем хранилище. При создании в подкаталоге правила будут применяться к этому конкретному каталогу и его подкаталогам.
Когда файл или каталог игнорируется, он не будет:
1. отслеживается Git
2. сообщается с помощью таких команд, как git status или git diff
3. поэтапно с помощью таких команд, как git add -A
В необычном случае, когда вам необходимо игнорировать отслеживаемые файлы, следует проявлять особую осторожность. См. раздел: Игнорирование файлов, которые уже были зафиксированы в репозитории Git.
Пример:
Вот несколько общих примеров правил в файле .gitignore, основанных на шаблонах файлов glob:
Большинство файлов .gitignore являются стандартными для разных языков, поэтому для начала приведем набор примеров файлов .gitignore, перечисленных по языкам, с которых можно клонировать или копировать / изменять в свой проект. В качестве альтернативы, для нового проекта вы можете рассмотреть возможность автоматического создания начального файла с помощью онлайн-инструмента.
Другие формы .gitignore
файлы .gitignore предназначены для фиксации как часть репозитория. Если вы хотите игнорировать определенные файлы без соблюдения правил игнорирования, вот несколько вариантов:
Отредактируйте файл .git/info/exclude (используя тот же синтаксис, что и .gitignore). Правила будут глобальными в рамках репозитория;
Настройте глобальный файл gitignore, который будет применять правила игнорирования ко всем вашим локальным репозиториям:
Кроме того, вы можете игнорировать локальные изменения отслеживаемых файлов без изменения глобальной конфигурации git с помощью:
git update-index --skip-worktree [<file>...]: для незначительных локальных изменений
git update-index --assume-unchanged [<file>...]: для готовых к производству, неизменяемых файлов выше по потоку
Очистка игнорируемых файлов
Вы можете использовать git clean -X для очистки игнорируемых файлов:
git clean -Xn #отобразить список игнорируемых файлов
git clean -Xf #удалить ранее отображенные файлы
Примечание: -X (заглавные буквы) очищает только игнорируемые файлы. Используйте -x (без заглавных букв), чтобы также удалить неотслеживаемые файлы.
Более подробную информацию смотрите в документации git clean
Раздел 5.2: Проверка, игнорируется ли файл
Команда git check-ignore сообщает о файлах, игнорируемых Git.
Вы можете передать имена файлов в командной строке, и git check-ignore выведет список имен файлов, которые игнорируются. Например:
$ cat .gitignore
*.o
$ git check-ignore example.o Readme.md
example.o
Здесь в файле .gitignore определены только файлы *.o, поэтому Readme.md не указан в выводе git check-ignore.
Если вы хотите увидеть строку, в которой .gitignore отвечает за игнорирование файла, добавьте -v в команду git check-ignore:
$ git check-ignore -v example.o Readme.md
.gitignore:1:*.o example.o
Начиная с Git 1.7.6 и далее, вы также можете использовать git status --ignored для просмотра игнорируемых файлов. Вы можете найти более подробную информацию об этом в официальной документации или в разделе Поиск файлов, игнорируемых .gitignore.
Раздел 5.3: Исключения в файле .gitignore
Если вы игнорируете файлы с помощью шаблона, но у вас есть исключения, добавьте восклицательный знак (!) к исключению. Например:
*.txt
!important.txt
В приведенном выше примере Git предписывает игнорировать все файлы с расширением .txt, за исключением файлов с именем important.txt .
Если файл находится в игнорируемой папке, вы не сможете повторно включить его так легко:
folder/
!folder/*.txt
В этом примере все файлы .txt в папке будут игнорироваться.
Правильный способ - повторно включить саму папку в отдельную строку, затем игнорировать все файлы в папке с помощью *, и, наконец, повторно включить *.txt в папку, как показано ниже:
!folder/
folder/*
!folder/*.txt
Примечание. Для имен файлов, начинающихся с восклицательного знака, добавьте два восклицательных знака или экранируйте символом \:
!!includethis
\!excludethis
Раздел 5.4: Глобальный файл .gitignore
Чтобы Git игнорировал определенные файлы во всех репозиториях, вы можете создать глобальный файл .gitignore с помощью следующей команды в терминале или командной строке:
$ git config --global core.excludesfile <Path_To_Global_gitignore_file>
Git теперь будет использовать это в дополнение к собственному файлу .gitignore каждого репозитория.
Правила для этого таковы:
- Если локальный файл .gitignore явно включает файл, в то время как глобальный файл .gitignore игнорирует его, локальный файл .gitignore имеет приоритет (файл будет включен)
- Если репозиторий клонирован на нескольких машинах, то global .gitignore должен быть загружен на все машины или, по крайней мере, включать его, так как игнорируемые файлы будут помещены в репозиторий, в то время как компьютер с global .gitignore не обновит его. Вот почему конкретный репо .gitignore - лучшая идея, чем глобальная, если над проектом работает команда
Этот файл является хорошим местом для игнорирования платформы, компьютера или конкретного пользователя, например, OSX .DS_Store, Windows Thumbs.db или Vim *.ext ~ и *.ext.swp игнорируют, если вы не хотите хранить их в хранилище. Таким образом, один член команды, работающий над OS X, может добавить all .DS_STORE и _MAC OS X (что на самом деле бесполезно), в то время как другой член команды в Windows может игнорировать все thumbs.bd
Раздел 5.5: Игнорируйте файлы, которые уже были зафиксированы в репозитории Git
Если вы уже добавили файл в свой репозиторий Git и теперь хотите прекратить его отслеживание (чтобы он не присутствовал в будущих фиксациях), вы можете удалить его из индекса:
git rm --cached <file>
Это удалит файл из репозитория и предотвратит отслеживание дальнейших изменений Git. Параметр --cached гарантирует, что файл физически не будет удален.
Обратите внимание, что ранее добавленное содержимое файла по-прежнему будет видно в истории Git.
Имейте в виду, что если кто-либо еще извлечет файл из хранилища после того, как вы удалили файл из индекса, его копия будет физически удалена.
Вы можете сделать вид, что версия файла в рабочем каталоге обновлена, и вместо этого прочитать версию индекса (таким образом, игнорируя изменения в нем) с помощью бита "пропустить рабочее дерево".:
git update-index --skip-worktree <file>
Этот бит не влияет на написание, безопасность контента по-прежнему является первоочередной задачей. Вы никогда не потеряете свои драгоценные проигнорированные изменения; с другой стороны, этот бит конфликтует с сохранением: чтобы удалить этот бит, используйте
git update-index --no-skip-worktree <file>
Иногда ошибочно рекомендуется лгать Git и заставлять его предполагать, что файл не изменился, не изучая его. На первый взгляд это выглядит как игнорирование любых дальнейших изменений в файле, без удаления его из индекса:
git update-index --assume-unchanged <file>
Это заставит git игнорировать любые изменения, внесенные в файл (имейте в виду, что если вы внесете какие-либо изменения в этот файл или спрячете его, ваши проигнорированные изменения будут потеряны)
Если вы хотите, чтобы git снова "позаботился" об этом файле, выполните следующую команду:
git update-index --no-assume-unchanged <file>
Раздел 5.6: Игнорировать файлы локально без фиксации правил игнорирования
.gitignore игнорирует файлы локально, но он предназначен для фиксации в репозитории и совместного использования с другими участниками и пользователями. Вы можете установить глобальный .gitignore, но тогда все ваши репозитории будут совместно использовать эти настройки.
Если вы хотите игнорировать определенные файлы в репозитории локально и не делать файл частью какого-либо репозитория, отредактируйте файл .git/info/exclude внутри своего репозитория.
Например:
# эти файлы игнорируются только в этом отчете
# эти правила никому не сообщаются
# поскольку они являются личными
gtk_tests.py
gui/gtk/tests/*
localhost
pushReports.py
server/
Раздел 5.7: Игнорирование последующих изменений в файле (без его удаления)
Иногда вы хотите, чтобы файл хранился в Git, но игнорировали последующие изменения.
Попросите Git игнорировать изменения в файле или каталоге с помощью update-index:
git update-index --assume-unchanged my-file.txt
Приведенная выше команда предписывает Git предположить my-file.txt не было изменено, и не для того, чтобы проверять или сообщать об изменениях. Файл все еще присутствует в репозитории.
Это может быть полезно для предоставления значений по умолчанию и разрешения переопределений локальной среды, например:
# создайте файл с некоторыми значениями в
cat <<EOF
MYSQL_USER=app
MYSQL_PASSWORD=FIXME_SECRET_PASSWORD
EOF > .env
# обязательство перед Git
git add .env
git commit -m "Добавление шаблона .env"
# игнорировать будущие изменения в .environmental
git update-index --assume-unchanged .env
# обновите свой пароль
vi .env
# никаких изменений!
git status
Раздел 5.8: Игнорирование файла в любом каталоге
Чтобы игнорировать файл foo.txt в любом каталоге вы должны просто написать его название:
foo.txt # соответствует всем файлам 'foo.txt ' в любом справочнике
Если вы хотите игнорировать файл только в части дерева, вы можете указать подкаталоги определенного каталога с шаблоном **:
bar/**/foo.txt # соответствует всем файлам 'foo.txt "в "баре" и во всех подкаталогах
Или вы можете создать файл .gitignore в каталоге bar/. Эквивалентом предыдущего примера было бы создание файла bar/.gitignore с этим содержимым:
foo.txt # соответствует всем файлам 'foo.txt ' в любом каталоге под var/
Раздел 5.9: Предварительно заполненные шаблоны .gitignore
Если вы не уверены, какие правила следует перечислить в вашем файле .gitignore, или вы просто хотите добавить общепринятые исключения в свой проект, вы можете выбрать или создать файл .gitignore:
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.
Многие сервисы хостинга, такие как GitHub и BitBucket, предлагают возможность создавать файлы .gitignore на основе языков программирования и IDE, которые вы можете использовать:
Раздел 5.10: Игнорирование файлов во вложенных папках (несколько файлов gitignore)
Предположим, у вас есть такая структура репозитория:
выход.вход в каталог примеров допустим и необходим для того, чтобы проект получил представление, в то время как каталог под src/ создается во время отладки и не должен находиться в истории или части репозитория.
Есть два способа игнорировать этот файл. Вы можете поместить абсолютный путь в файл .gitignore в корне рабочего каталога:
# /.gitignore
src/output.log
В качестве альтернативы вы можете создать файл .gitignore в каталоге src/ и игнорировать файл, относящийся к этому .gitignore:
# /src/.gitignore
output.log
Раздел 5.11: Создайте пустую папку
Невозможно добавить и зафиксировать пустую папку в Git из-за того, что Git управляет файлами и прикрепляет к ним их каталог, что уменьшает количество фиксаций и повышает скорость. Чтобы обойти это, есть два способа:
Способ первый: .gitkeep
Один из способов обойти это - использовать файл .gitkeep для регистрации папки для Git. Для этого просто создайте необходимый каталог и добавьте в него файл .gitkeep. Этот файл пустой и не служит никакой другой цели, кроме как просто зарегистрировать папку. Чтобы сделать это в Windows (которая имеет неудобные соглашения об именовании файлов), просто откройте git bash в директории и выполните команду:
$ touch .gitkeep
Эта команда просто создает пустой файл .gitkeep в текущем каталоге
Способ второй: dummy.txt
Другой хак для этого очень похож на описанный выше, и можно выполнить те же шаги, но вместо .gitkeep просто используйте dummy.txt вместо этого. Это дает дополнительный бонус в виде возможности легко создавать его в Windows с помощью контекстного меню. И вы тоже можете оставлять в них забавные сообщения.Вы также можете использовать файл .gitkeep для отслеживания пустого каталога. .gitkeep обычно представляет собой пустой файл, который добавляется для отслеживания пустого каталога.
Раздел 5.12: Поиск файлов, игнорируемых .gitignore
Вы можете перечислить все файлы, игнорируемые git, в текущем каталоге с помощью команды:
git status --ignored
Итак, если у нас есть такая структура репозитория:
.git
.gitignore
./example_1
./dir/example_2
./example_2
...и .gitignore файл, содержащий:
example_2
...чем результат выполнения команды будет:
$ git status --ignored
Если вы хотите перечислить рекурсивно игнорируемые файлы в каталогах, вам необходимо использовать дополнительный параметр - --untrackedfiles=all
Результат будет выглядеть так:
Раздел 5.13: Игнорирование только части файла [stub]
Иногда вам может потребоваться внести локальные изменения в файл, который вы не хотите фиксировать или публиковать. В идеале локальные настройки должны быть сосредоточены в отдельном файле, который можно поместить в файл .gitignore, но иногда в качестве краткосрочного решения может быть полезно иметь что-то локальное в зарегистрированном файле.
Вы можете заставить Git "не видеть" эти строки, используя чистый фильтр. Они даже не появятся в диффах.
Предположим, что здесь приведен фрагмент из файла file1.c:
Вы не хотите нигде публиковать строки NOCOMMIT.
Создайте фильтр "без фиксации", добавив его в файл конфигурации Git, например .git/config:
[filter "nocommit"]
clean=grep -v NOCOMMIT
Добавьте (или создайте) это в .git/info/атрибуты или .gitмодули:
file1.c filter=nocommit
И ваши строки NOCOMMIT скрыты от Git.
Предостережения:
Использование чистого фильтра замедляет обработку файлов, особенно в Windows.
Игнорируемая строка может исчезнуть из файла, когда Git обновит ее. Этому можно противостоять с помощью фильтра размазывания, но это сложнее.
Не тестировался в Windows
Раздел 5.14: Игнорирование изменений в отслеживаемых файлах. [stub]
Пожалуйста, авторизуйтесь для просмотра ссылки.
и .git/info/exclude работают только для неотслеживаемых файлов.Чтобы установить флаг игнорирования для отслеживаемого файла, используйте команду
Пожалуйста, авторизуйтесь для просмотра ссылки.
git update-index --skip-worktree myfile.c
Чтобы отменить это, используйте:
git update-index --no-skip-worktree myfile.c
Вы можете добавить этот фрагмент в свою глобальную
Пожалуйста, авторизуйтесь для просмотра ссылки.
, чтобы иметь более удобные команды git head, git unhide и git hidden:[alias]
hide = update-index --skip-worktree
unhide = update-index --no-skip-worktree
hidden = "!git ls-files -v | grep ^[hsS] | cut -c 3-"
Вы также можете использовать опцию --предположить-без изменений с помощью функции update-index
git update-index --assume-unchanged <file>
Если вы хотите еще раз просмотреть этот файл на предмет изменений, используйте
git update-index --no-assume-unchanged <file>
Когда указан флаг --assume-unchanged , пользователь обещает не изменять файл и позволяет Git предполагать, что файл рабочего дерева соответствует тому, что записано в индексе.Git потерпит неудачу в случае, если ему потребуется изменить этот файл в индексе, например, при слиянии в фиксации; таким образом, в случае, если предполагаемый неотслеживаемый файл будет изменен вверх по течению, вам нужно будет справиться с ситуацией вручную. В данном случае основное внимание уделяется производительности.
В то время как флаг --skip-worktree полезен, когда вы даете указание git никогда не прикасаться к определенному файлу, потому что файл будет изменен локально, и вы не хотите случайно зафиксировать изменения (т. е. файл конфигурации/свойств, настроенный для определенной среды). Пропустить-рабочее дерево имеет приоритет над предполагать неизменным, когда оба заданы.
Раздел 5.15: Очистить уже зафиксированные файлы, но включенные в .gitignore
Иногда случается, что файл отслеживался git, но в более поздний момент времени был добавлен в .gitignore, чтобы прекратить его отслеживание. Это очень распространенный сценарий, когда забывают очистить такие файлы перед их добавлением в .gitignore.
В этом случае старый файл все еще будет висеть в хранилище.
Чтобы устранить эту проблему, можно было бы выполнить "пробное" удаление всего, что находится в репозитории, с последующим повторным добавлением всех файлов обратно. Пока у вас нет ожидающих изменений и передан параметр -cached, эта команда достаточно безопасна для выполнения:
# Удалить все из индекса (файлы останутся в файловой системе)
$ git rm -r --cached .
# Повторно добавьте все (они будут добавлены в текущем состоянии, включая изменения)
$ git add .
# Зафиксировать, если что-то изменилось. Вы должны видеть только удаления
$ git commit -m "Удалите все файлы, которые находятся в .gitignore"
# Обновите пульт дистанционного управления
$ git push origin master
Глава 6: Разница в Git
| Параметр | Подробности |
| -p, -u, --patch | Создать патч |
| -s, --no-patch | Подавление вывода различий. Полезно для таких команд, как git show, которые показывают патч по умолчанию, или для отмены эффекта --patch |
| --raw | Создайте разницу в формате raw |
| --diff-algorithm= | Выберите алгоритм различия. Варианты следующие: myers, minimal, patience, histogram |
| --summary | Выведите сжатую сводку расширенной информации заголовка, такой как создание, переименование и изменение режима |
| --name-only | Показывать только имена измененных файлов |
| --name-status | Показывать имена и статусы измененных файлов Наиболее распространенными статусами являются M (Изменено), A (Добавлено) и D (Удалено) |
| --check | Предупреждайте, если изменения вносят маркеры конфликтов или ошибки пробелов. То, что считается ошибками пробелов, контролируется конфигурацией core.whitespace. По умолчанию завершающие пробелы (включая строки, состоящие исключительно из пробелов) и символ пробела, за которым сразу следует символ табуляции внутри начального отступа строки, считаются ошибками пробела. Завершает работу с ненулевым статусом при обнаружении проблем. Не совместим с --exit-code |
| --full-index | Вместо первой горстки символов при создании выходных данных в формате патча покажите полные имена объектов blob-объектов до и после изображения в строке "индекс". |
| --binary | В дополнение к --full-index выведите двоичное различие, которое можно применить с помощью git apply |
| -a, --text | Обрабатывайте все файлы как текст. |
| --color | Установите цветовой режим; т. Е. используйте --color=always, если вы хотите передать различие, чтобы благословить и сохранить его окраску |
Раздел 6.1: Показать различия в рабочей ветви
git diff
Это покажет нестационарные изменения в текущей ветке с момента фиксации до нее. Он будет показывать только изменения относительно индекса, то есть он показывает, что вы могли бы добавить в следующую фиксацию, но не сделали этого. Чтобы добавить (поэтапно) эти изменения, вы можете использовать git add.
Если файл является промежуточным, но был изменен после его подготовки, git diff покажет различия между текущим файлом и промежуточной версией.
Раздел 6.2: Показать изменения между двумя фиксациями
git diff 1234abc..6789def
Например: Показать изменения, внесенные в последние 3 коммита:
git diff @~3..@
Примечание: две точки (..) необязательны, но добавляют ясности.
Это покажет текстовую разницу между фиксациями, независимо от того, где они находятся в дереве.
Раздел 6.3: Показать различия для поэтапных файлов
git diff --staged
Это покажет изменения между предыдущей фиксацией и текущими промежуточными файлами.
ПРИМЕЧАНИЕ: Вы также можете использовать следующие команды для выполнения того же самого:
git diff --cached
Что является просто синонимом --staged или git status -v
Который вызовет подробные настройки команды statusd.
Раздел 6.4: Сравнение филиалов
Показать изменения между наконечником нового и наконечником оригинального:
git diff original new #эквивалент оригиналу..новый
Показать все изменения на новом, так как он разветвился от оригинала:
git diff original...new #эквивалентно $(git merge - исходная новая база)..новый
Использование только одного параметра, такого как
git diff original,
эквивалентно
git diff original..HEAD
Раздел 6.5: Показать как поэтапные, так и нестационарные изменения
Чтобы отобразить все поэтапные и нестационарные изменения, используйте:
git diff HEAD
ПРИМЕЧАНИЕ: Вы также можете использовать следующую команду:
git status -vv
Разница в том, что вывод последнего фактически сообщит вам, какие изменения подготовлены для фиксации, а какие нет.
Последнее редактирование: