Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Основы работы с Git

Основы работы с Git

По материалам сайта Calculate Linux: https://www.calculate-linux.org/main/ru/git

Введение

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Основы работы с удаленным репозиторием

git clone — создание копии (удаленного) репозитория

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

Клонирует репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонирует репозиторий с той же машины в директорию myrepo:

git clone /home/username/project myrepo

Клонирует репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортирует svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

где -s – понимать стандартные папки SVN (trunk, branches, tags)

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забирает изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

Получает изменений из определенного репозитория:

git fetch /home/username/project

Возможно также использовать синонимы для адресов, создаваемые командой git remote:

git remote add username-project /home/username/project
git fetch username-project

Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:

git merge username-project/master

Команда git pull сразу забирает изменения и проводит слияние с активной веткой. Забирает из репозитория, для которого были созданы удаленные ветки по умолчанию:

git pull

Забирает изменения и метки из определенного репозитория:

git pull username-project --tags

Как правило, используется сразу команда git pull.

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

Отправляет свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправляет изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удаляет ветку experimental:

git push origin :experimental

Отправляет в удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправляет метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменяет указатель для удаленной ветке master репозитория origin (master будет такой же как и develop):

git push origin origin/develop:master

Добавляет ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Работа с локальным репозиторием

Базовые команды

git init — создание репозитория

Команда git init создает в директории пустой репозиторий в виде директории .git, где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

mkdir project-dir
cd project-dir
git init

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит.

Индексирует измененный файл, либо оповещение о создании нового:

git add EDITEDFILE

Вносит в индекс все изменения, включая новые файлы:

git add .

Из индекса и дерева проекта одновременно файл можно удалить командой git rm.

Удаляет из индекса и дерева проекта отдельные файлы:

git rm FILE1 FILE2

Хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

git rm Documentation/\*.txt

Вносит в индекс все удаленные файлы:

git rm -r --cached .

Сбросить весь индекс или удалить из него изменения определенного файла можно командой git reset:

git reset

Удаляет из индекса конкретный файл:

git reset — EDITEDFILE

Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

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

git status

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.

git commit — совершение коммита

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

git commit

Если индекс не пустой, то на его основе будет совершен коммит, после чего пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов. Есть несколько ключей, упрощающих работу с git commit.

Совершает коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено:

git commit -a

Комментирует коммит прямо из командной строки вместо текстового редактора:

git commit -m «commit comment»

Вносит в индекс и создаёт коммит на основе изменений единственного файла:

git commit FILENAME

Пример написания хорошего сообщения коммита:

Описывает изменение (до 50 символов)

Более детальное объяснение, если необходимо. Перенос на 72 символе
или около того. В некоторых контекстах первая строка рассматривается
как тема письма, а остальное как тело. Пустая строка, отделяющая сводку
от тела, важна (если вы не опустили тело целиком); если вы оставите их
вместе, инструменты, такие как rebase, могут воспринять это неправильно.

Дальнейшие параграфы идут после пустых строк

 - также можно применять маркеры списков

 - обычно в качестве маркера списка используется дефис или звёздочка
   с одним пробелом перед ним и пустыми строками между пунктами,
   хотя соглашения в этом аспекте могут разниться

Если вы используете систему отслеживания задач, поставьте ссылки на нее:

Resolves: #123
See also: #456, #789

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

«Мягкий» (с ключом --soft) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

  1. Некорректный коммит
    git commit
    
  2. Переход к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
    git reset --soft HEAD^
    
  3. Редактирование файла или файлов
  4. Добавление файлов в индекс
    git add .
    
  5. Возврат к последнему коммиту, будет предложено отредактировать его сообщение
    git commit -c ORIG_HEAD
    
    Если сообщение оставить прежним, то достаточно изменить регистр ключа -с
    git commit -C ORIG_HEAD
    

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

«Жесткий» резет (ключ --hard) — команда, которую следует использовать с осторожностью. git reset --hard вернет дерево проекта и индекс в состояние, соответствующее указанному коммиту, удалив изменения последующих коммитов:

git add .
git commit -m «destined to death»
git reset --hard HEAD~1 — больше никто и никогда не увидит этот позорный коммит...
git reset --hard HEAD~3 — ...вернее, три последних коммита. Никто. Никогда!

Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.

Отменяет коммит, помеченный тегом:

git revert config-modify-tag

Отменяет коммит, используя его хэш:

git revert cgsjd2h

Для отмены коммита слияния (коммита у которого несколько родителей), необходимо указать хэш и номер одного из родителей коммита:

git revert cgsjd2h -m 1

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

git log — разнообразная информация о коммитах в целом

Иногда требуется получить информацию об истории коммитов; коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log.

Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):

git log

Получает подробную информацию о каждом в виде патчей по файлам из коммитов можно, добавив ключ -p (или -u):

git log -p

Статистика изменения файлов, вроде числа измененных файлов, внесенных в них строк, удаленных файлов вызывается ключом --stat:

git log --stat

За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ --summary:

git log --summary

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает, обязательно добавлять " — " перед «README»):

git log README

или, если версия git не совсем свежая:

git log — README

Далее приводится только более современный вариант синтаксиса. Возможно указывать время, начиная в определенного момента («weeks», «days», «hours», «s» и так далее):

git log --since=«1 day 2 hours» README
git log --since=«2 hours» README

изменения, касающиеся отдельной папки:

git log --since=«2 hours» dir/

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

git log v1...

Все коммиты, включающие изменения файла README, начиная с тега v1:

git log v1... README

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

git log v1..v2 README

Интересные возможности по формату вывода команды предоставляет ключ --pretty.

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

git log --pretty=oneline

Лаконичная информация о коммитах, приводятся только автор и комментарий:

git log --pretty=short

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

git log --pretty=full/fuller

В принципе, формат вывода можно определить самостоятельно:

git log --pretty=format:'FORMAT'

Определение формата можно поискать в разделе по git log из Git Community Book или справке. Красивый ASCII-граф коммитов выводится с использованием ключа --graph.

git diff — отличия между деревьями проекта, коммитами и т.д.

Своего рода подмножеством команды git log можно считать команду git diff, определяющую изменения между объектами в проекте - деревьями (файлов и директорий).

Показывает изменения, не внесенные в индекс:

git diff

Изменения, внесенные в индекс:

git diff --cached

Изменения в проекте по сравнению с последним коммитом:

git diff HEAD

Предпоследним коммитом:

git diff HEAD^

Можно сравнивать «головы» веток:

git diff master..experimental

или активную ветку с какой-либо:

git diff experimental

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:

git show COMMIT_TAG

git blame и git annotate — команды, помогающие отслеживать изменения файлов

При работе в команде часто требуется выяснить, кто именно написал конкретный код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита:

git blame README

Можно указать и конкретные строки для отображения:

git blame -L 2,+3 README — выведет информацию по трем строкам, начиная со второй.

Аналогично работает команда git annotate, выводящая и строки, и информацию о коммитах, их коснувшихся:

git annotate README

git grep — поиск слов по проекту, состоянию проекта в прошлом

git grep, в целом, просто дублирует функционал знаменитой юниксовой команды. Однако он позволяет слова и их сочетания искать в прошлом проекта, что бывает очень полезно.

Ищет слова tst в проекте:

git grep tst

Подсчитывает число упоминаний tst в проекте:

git grep -с tst

Ищет в старой версии проекта:

git grep tst v1

Команда позволяет использовать логическое И и ИЛИ.

Ищет строки, где упоминаются и первое слово, и второе:

git grep -e 'first' --and -e 'another'

Ищет строки, где встречается хотя бы одно из слов:

git grep --all-match -e 'first' -e 'second'

Ветвление

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде.

Просто перечисляет существующие ветки, отметив активную:

git branch

Создаёт новую ветку new-branch:

git branch new-branch

Удаляет ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

git branch -d new-branch

Удаляет ветку в любом случае:

git branch -D new-branch

Переименовывает ветку:

git branch -m new-name-branch

Показывывает те ветки, среди предков которых есть определенный коммит:

git branch --contains v1.2

Показывает коммит ответвления ветки new-name-branch от ветки master:

git merge-base master new-name-branch

git checkout — переключение между ветками, извлечение файлов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

checkout some-other-branch

Создаёт ветку, в которую и произойдет переключение:

git checkout -b some-other-new-branch

Если в текущей ветке были какие-то изменения по сравнению с последним коммитом в ветке(HEAD), то команда откажется производить переключение, дабы не потерять произведенную работу. Проигнорировать этот факт позволяет ключ -f:

git checkout -f some-other-branch

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

git checkout -m some-other-branch

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

git checkout somefile

Возвращает somefile к состоянию последнего коммита:

git checkout somefile

Возвращает somefile к состоянию на два коммита назад по ветке:

git checkout HEAD~2 somefile

git merge — слияние веток, разрешение возможных конфликтов

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

Пытается объединить текующую ветку и ветку new-feature:

git merge new-feature

В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.

Произошла неудачная попытка слияния:

git merge experiment

Смотрим на проблемные места:

git status

Разрешаем проблемы:

edit TROUBLE

Индексируем наши изменения, тем самым снимая метки:

git add .

Совершаем коммит слияния:

git commit

Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):

git reset --hard HEAD

Если же коммит слияния был совершен, используем команду:

git reset --hard ORIG_HEAD

git rebase — построение ровной линии коммитов

Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера, либо сам разработчик совершал в ней коммиты.

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

Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

Вариант, в котором явно указывается, что и куда накладывается:

git-rebase master topic

на master накладывается активная в настоящий момент ветка:

git-rebase master

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

git add

и продолжить наложение следующих коммитов командой:

git rebase --continue

Альтернативными выходами будут команды пропустить наложение коммита и перейти к следующему:

git rebase --skip 

и отмена работы команды и всех внесенных изменений:

git rebase --abort 

С ключом -i (--interactive) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).

Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

git cherry-pick BUG_FIX_TAG

Ключ -n показывает, что изменения надо просто применить к дереву проекта без индексации и создания коммита:

git cherry-pick BUG_FIX_TAG -n

git worktree - одновременная работа с несколькими ветками

Git позволяет работать одновременно с несколькими ветками одного репозитория. Для добавления ветки в отдельную директорию необходимо выполнить команду:

git worktree add path/ remote/master

Для просмотра всех директориев с ветками можно воспользоваться командой:

git worktree list

Директорию с веткой можно перести в другое место с помощью команды:

git worktree move old-path/ new-path/

После окончания работы с веткой в директории, её можно удалить командой:

git worktree remove path/ 

Подмодули

Клонирование репозитория с подмодулями

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

$ git clone --recursive https://github.com/username/repo.git

Запуск данной команды эквивалентен запуску команды:

git submodule update --init --recursive

после обычного клонирования репозитория

Обновление подмодулей

Подмодуль ссылается на конкретную коммит в другом репозитории. Чтобы получить точное состояние всех подмодулей необходимо запустить:

git submodule update --recursive

Для получения состояния последнего коммита всех подмодулей необходимо выполнить следующую команду:

git submodule foreach git pull origin master

или использовать аргументы по умолчанию команды git pull:

git submodule foreach git pull

Эта команда просто обновляет локальную рабочую копию. При запуске команды git status каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо зафиксировать изменения:

git add submodule_directory
git commit

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

git submodule update --remote submodule_directory

Добавление подмодулей

В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:

git submodule add https://github.com/jquery/jquery.git

После этого необходимо добавить и зафиксировать новый файл .gitmodules. В нём описано какие подмодули следует клонировать при запуске команды git submodule update

Перемещение подмодулей

Для перемещение подмодуля из одного места репозитория в другое место репозитория необходимо выполнить команду:

git mv /path/to/module new/path/to/module

Удаление подмодулей

Для удаления подмодуля из репозитория необходимо удалить описание подмодуля и каталог с файлами подмодуля:

git submodule deinit the_submodule
git rm the_submodule

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

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

Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации.

Ищет разницу текущего состояния проекта и коммита за номером… сами видите, каким:

git diff f292ef5d2b2f6312bc45ae49c2dc14588eef8da2

То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:

git diff f292ef5

Иногда хватает и четырех символов:

git diff f292

Читает лог с коммита по коммит:

git log febc32...f292

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

git tag stable-1

Помечает определенный коммит:

git tag stable-2 f292ef5

Удаляет тег:

git tag -d stable-2

Перечисляет тэги:

git tag -l

Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:

git tag -f stable-1.1

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее:

git diff stable-1.1...stable-1

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:

git tag -a stable

Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:

git tag -a stable -m "production version"

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Относительная адресация

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:

git diff master^

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

git diff HEAD^2

Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки.

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

Что привнес «дедушка» нынешнего коммита:

git diff master^^

То же самое:

git diff master~2

Обозначения можно объединять, чтобы добраться до нужного коммита:

git diff master~3^~2
git diff master~6

Файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или глубже по дереву (если ограничения должны быть только в определенных директория) файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов определенного формата.

Пример содержимого такого файла:

#комментарий к файлу .gitignore
#игнорируем сам .gitignore
.gitignore
#все html-файлы...
*.html
#...кроме определенного
!special.html
#не нужны объектники и архивы
*.[ao]

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

Серверные команды репозитория

Команда создания вспомогательных файлов для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере:

git update-server-info

Проверяет сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория:

git count-objects

Переупаковывает локальный репозиторий:

git gc

Рецепты

Создание пустого репозитория на сервере

repo="repo.git" 
mkdir $repo
cd $repo
git init --bare
chown git. -R ./
cd ../

Импорт svn репозитория на Git-сервер

repo="repo.svn" 
svnserver="http://svn.calculate.ru" 
git svn clone -s $svnserver/$repo $repo
mv $repo/.git/refs/remotes/tags $repo/.git/refs/tags
rm -rf $repo/.git/refs/remotes
rm -rf $repo/.git/svn
mv $repo/.git $repo.git
rm -rf $repo
cd $repo.git
chown git. -R ./
cd ../

Связка локальной и удаленной ветки

Отправление ветки local в удаленный репозиторий и установка локальной ветки local отслеживаемой с origin/local:

git push -u origin local

Пометка локальной ветки как отслеживаемой с origin/local:

git branch --set-upstream-to=origin/local

Создание новой пустой ветки

Создание пустой ветки с именем newbranch:

git checkout --orphan newbranch

Удаление файлов:

git rm -rf .

Использование Git для получения версии

Установка начала новой версии на текущий коммит:

git tag v1.0-dev

Получение номера версии для последующие коммитов:

git describe --tags
v1.0-dev-3-g387f83f

где

  • v1.0-dev — имя тега
  • 3 — количество коммитов после этого тега (0 если тэг поставлен на текущий коммит)
  • 387f83f — короткий хэш текущего коммита.

Файл настройки .gitconfig

[core]
    quotepath = false
    pager = less -r
    abbrev = 8
    editor = nano -ixO -r72
[format]
     pretty = Commit: %h%d%nAuthor: %an <%ae> %nDate:   %ad%C(reset)%n%n%w(72,2,2)%s%n%n%w(0,2,2)%-b%n
[user]
    name = <Firstname> <Surname>
    email = <username@email.com>
    signingkey = <key>
[push]
    default = simple
[color "branch"]
    current = 207 bold
    local = 40 bold
    remote = 203 bold
[color "diff"]
    meta = 207 bold
    frag = 207 bold
    old = 203 bold
    new = 40 bold
    whitespace = 40 reverse
[color "status"]
    added = 40 bold
    changed = 207 bold
    untracked = 203 bold

Замена автора коммита

#!/bin/sh

git filter-branch --env-filter '

OLD_EMAIL="username@examole.com"
CORRECT_NAME="Andrey Rodionov"
CORRECT_EMAIL="roand@inbox.ru"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags
@BSDRock
Copy link

BSDRock commented Sep 1, 2020

Ухты, спасибо

@victorusachev
Copy link

victorusachev commented Dec 11, 2020

Статья хорошая, спасибо.
Однако всё же "репозитОрий", а не "репозитАрий". Последнее слово - не вариант написания первого, оно имеет совершенно иное значение.

@rdnvndr
Copy link
Author

rdnvndr commented Dec 11, 2020

Спасибо, исправил.

@Fantom2018
Copy link

Fantom2018 commented Jun 26, 2021

если клонировал репу А в новую репу В (оба на githab прямо на гитхабе) ТО!? ... как переключить проект туда, на новый, чтобы коммиты и пуши шли туда в В

@rdnvndr
Copy link
Author

rdnvndr commented Jun 26, 2021

git remote add A <url>
git remote add B <url>
git push A или git push B

@Project-coins
Copy link

Project-coins commented Jul 26, 2021

Как получать уведомления на електронную почту на русском или украинских языках раньше получал на русском ,пропало.....
Пишите на cryptozpard@gmail.com

@Project-coins
Copy link

Project-coins commented Jul 26, 2021

Всем привет где взять генератор токена для файлообменника

@fara0000
Copy link

fara0000 commented Jun 7, 2022

Блин я такую классную доку по гит никогда не видел! Спасибо!!!!

@Tony-Sol
Copy link

Tony-Sol commented Aug 27, 2022

Жаль нет про subtree и его сравнение с submodule

@putiniyama
Copy link

putiniyama commented Nov 20, 2022

Почему я это пост раньше не нашел? Красава!

@Boris-neo
Copy link

Boris-neo commented Nov 26, 2022

Как зайти в созданный репозиторий в Git Bash после перезагрузки ПК? В GitKraken всё сохранилось, в Git Bash ошибку выдает и ветки не сохранились...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment