Как сделать коммит гит
Работаем с Git, основные команды для начинающих
Кто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:
После инициализации каталога будет выведено соответствующее сообщение:
$ git add
Для этого понадобится выполнить команду:
$ git status
Чтобы зарегистрировать добавление вышеприведенных файлов необходимо выполнить следующую команду:
–a означает: добавить все изменения в индекс до передачи.
-m : сообщение.
Подтверждение с описанием выполненных действий.
Мы сделали «снимок кода». Теперь мы можем редактировать файлы и регистрировать наши изменения.
$ git stash
$ git stash list
Чтобы просмотреть все сохраненные, но не зарегистрированные изменения понадобится следующая команда:
На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.
$ git stash pop
Восстановить же изменения поможет следующая команда:
$ git merge
Ветвление
Ветка позволяет отделить работу, например, над каким-то компонентом от основного кода сайта.
$ git checkout –b
Чтобы создать новую ветку выполните команду:
git init (инициализируем git реп-й)
Чтобы проинициализировать Git репозиторий введите команду:
git status (Проверяем статус)
Комнада, выводяюща статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (добавляем файл)
Чтобы сообщить Git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью:
Сейчас git отслеживает наш файл test.txt. Давайте выполним
снова, чтобы понять, что изменилось!
git commit (фиксируем изменения)
Чтобы сохранить изменения на данном этапе мы выполним команду создания коммита и передадим ей в качестве аргумента сообщение, описывающие изменения, сделанные в этом коммите.
Используем маску
К счастью, у нас есть возможность добавить все файлы, используя шаблон. Не забывайте про кавычки!
git commit –a –m ”new comment here”
Коммитится только то, что проиндексировано. Индексирование происходит функцией add (она и добавляет файлы и индексирует их).
Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,
—amend
Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,
Второй коммит заменит результат первого и в итоге останется 1 коммит
Работаем с GitHub
Зарегистрируйтесь на GitHub. Создайте репозиторий.
Чтобы разместить наш локальный репозиторий на GitHub, мы должны добавить удаленный репозиторий.
Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git
Выполняем команду с указанными аргументами:
git remote add origin https://github.com/try-git/try_git.git
Плюсы и минусы bitbucket.org и GitHub
На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.
Процесс разработки:
Эта команда показывает имя удаленного репо, если такой имеется в наличии.
Ключ –v показывает путь к удаленному репо.
Подробно о любой команде можно узнать:
Коммитим и пушим на GitHub (global настройки matching и simple)
Если мы выполнима для настройки глобального конфига следующую команду:
То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.
В данном случае протолкнется лишь текущая ветка.
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп.)
Добавление удаленных репозиториев под короким именем:
git remote add [сокращенное имя] [url]
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master
Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku
git remote show (получаем инфо. об уд. реп.)
Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.
git fetch (извлечение данных из уд. реп.)
Извлечение данных из уд. реп. выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта
git push (проталкиваем изменения)
где origin – это куда отправляем (удаленный репозитарий), а
master это то, что отправляем (в нашем случае master ).
git pull (стягиваем изменения)
Давайте представим, что прошло какое-то время. Мы пригласили других людей в наш проект, они забрали наши изменения в свои локальные репозитории и внесли свои изменения, запушили их. Мы можем проверить изменения на GitHub и спуллить их с помощью команды:
git pull origin master
Забираем изменения из ветки ( master ) на удаленном сервере ( origin ) и проводим слияние с активной веткой.
git diff, git diff HEAD
Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.
Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды
git reset (Откатываем изменения/удаляем файлы из промежуточной области)
git reset octofamily/octodog.txt
git log (информация о последних коммитах)
Иногда просто хочется вернуться назад и забыть все изменения до определенного момента, потому что все они были неправильными. В таком случае Для просмотра изменений (истории коммитов) используется команда
покажет список последних коммитов и их хеши SHA1.
На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:
Например, мы можем выводить историю в более удобном формате:
Ограничиваем коммиты по времени:
—stat используется для получения краткой статистики по каждому коммиту.
—graph добавляет графику с историей ветвлений и слияний
git checkout (Отмена изменений)
Файла был удален из промежуточной области. Но сам файл все еще находится в проекте! Файлы могут быть возвращены в состояние последнего коммита с помощью команды:
Для указания коммита достаточно первых нескольких символов его хеша ( 82f5 ), но можете скопировать и весь хеш.
git checkout (получаем уд. ветку)
Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :
(?) или просто git checkout [имя_ветки] ; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.
git branch (создаем ветку)
Когда разработчики работают над новой фичей или багом, они обычно создают копию (или ветку) кода проекта, в которую они могут коммитить независимо. Когда разработка завершена, изменения из этой копии (ветки) нужно влить (вмержить) обратно в основную ветку проекта.
Давайте создадим новую ветку и назовем ее clean_up :
git branch clean_up
Данная команда не обращается к серверу, а а берет локальные данные из кэша.
Для получений актуальной информации как на удаленном так и на локальном серверах можно использовать команду:
git rm (удаляем файлы)
merge (смержим в текущую ветку другую)
git merge clean_up
git clone
$ mkdir epicgame & cd epicgame
$ git init
$ git remote add
$ git clone
rejected
Конфликты
Сообщение о конфликте:
В статусе ( git st ) появляется блок:
То есть в самом файле:
Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения ( // Fry comment ) или оставить строку пользователя Bender ( // Bender comment ).
Разные полезные команды:
Добавляем пользователя:
(задаем email глобально)
(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig )
Игнорирование файлов:
В самом файле указываем игнорирование, например:
$ git rm
СВОЙ РЕДАКТОР ДЛЯ КОММЕНТАРИЕВ
Без ключа –m откроется редактор vim ( 😡 – означает сохранить и выйти).
Поменяем редактрор по умолчанию (vim), он будет открываться в том случае, если мы не прописываем комментарий в командной строке.
Изменения можно проверить в C:\Users\name_user\.gitconfig
ВЕТКИ ($ git checkout –b new_branch)
Создаем ветку new_f и тут же переходим в нее.
С использованием –v показывает ветки с последними коммитами.
merge
Указываем какой утилитой будем разрешать конфликты
Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):
rdnvndr / MainGit.md
Основы работы с 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:
Клонирует репозиторий с той же машины в директорию myrepo:
Клонирует репозиторий, используя безопасный протокол ssh:
У git имеется и собственный протокол:
Импортирует svn репозиторий, используя протокол http:
git fetch и git pull — забираем изменения из центрального репозитория
Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.
git fetch — забирает изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.
Получает изменений из определенного репозитория:
Возможно также использовать синонимы для адресов, создаваемые командой git remote:
Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:
Команда git pull сразу забирает изменения и проводит слияние с активной веткой. Забирает из репозитория, для которого были созданы удаленные ветки по умолчанию:
Забирает изменения и метки из определенного репозитория:
Как правило, используется сразу команда git pull.
git push — вносим изменения в удаленный репозиторий
После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.
Отправляет свои изменения в удаленную ветку, созданную при клонировании по умолчанию:
Отправляет изменения из ветки master в ветку experimental удаленного репозитория:
В удаленном репозитории origin удаляет ветку experimental:
Отправляет в удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:
Отправляет метки в удаленную ветку master репозитория origin:
Изменяет указатель для удаленной ветке master репозитория origin (master будет такой же как и develop):
Добавляет ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:
Работа с локальным репозиторием
git init — создание репозитория
git add и git rm — индексация изменений
Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит.
Индексирует измененный файл, либо оповещение о создании нового:
Вносит в индекс все изменения, включая новые файлы:
Из индекса и дерева проекта одновременно файл можно удалить командой git rm.
Удаляет из индекса и дерева проекта отдельные файлы:
Хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:
Вносит в индекс все удаленные файлы:
Сбросить весь индекс или удалить из него изменения определенного файла можно командой git reset:
Удаляет из индекса конкретный файл:
Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.
git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы
Команду git status, пожалуй, можно считать самой часто используемой наряду с командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто:
Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.
git commit — совершение коммита
Коммит — базовое понятие во всех системах контроля версий, поэтому совершаться он должен легко и по возможности быстро. В простейшем случае достаточно после индексации набрать:
Если индекс не пустой, то на его основе будет совершен коммит, после чего пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов. Есть несколько ключей, упрощающих работу с git commit.
Совершает коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено:
Комментирует коммит прямо из командной строки вместо текстового редактора:
Вносит в индекс и создаёт коммит на основе изменений единственного файла:
Пример написания хорошего сообщения коммита:
git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).
Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.
Естественно, можно вернуться и на большую глубину коммитов,
Если команда достигнет точки ветвления, удаления коммита не произойдет.
Для команд слияния или выкачивания последних изменений с удаленного репозитория примеры резета будут приведены в соответствующих разделах.
git revert — отмена изменений, произведенных в прошлом отдельным коммитом
Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.
Отменяет коммит, помеченный тегом:
Отменяет коммит, используя его хэш:
Для отмены коммита слияния (коммита у которого несколько родителей), необходимо указать хэш и номер одного из родителей коммита:
Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.
git log — разнообразная информация о коммитах в целом
Иногда требуется получить информацию об истории коммитов; коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log.
Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):
Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает, обязательно добавлять » — » перед «README»):
или, если версия git не совсем свежая:
Далее приводится только более современный вариант синтаксиса. Возможно указывать время, начиная в определенного момента («weeks», «days», «hours», «s» и так далее):
изменения, касающиеся отдельной папки:
Можно отталкиваться от тегов.
Все коммиты, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:
Выводит на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше):
Лаконичная информация о коммитах, приводятся только автор и комментарий:
Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:
В принципе, формат вывода можно определить самостоятельно:
git diff — отличия между деревьями проекта, коммитами и т.д.
Показывает изменения, не внесенные в индекс:
Изменения, внесенные в индекс:
Изменения в проекте по сравнению с последним коммитом:
Можно сравнивать «головы» веток:
или активную ветку с какой-либо:
git show — показать изменения, внесенные отдельным коммитом
Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:
git blame и git annotate — команды, помогающие отслеживать изменения файлов
При работе в команде часто требуется выяснить, кто именно написал конкретный код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита:
Можно указать и конкретные строки для отображения:
Аналогично работает команда git annotate, выводящая и строки, и информацию о коммитах, их коснувшихся:
git grep — поиск слов по проекту, состоянию проекта в прошлом
git grep, в целом, просто дублирует функционал знаменитой юниксовой команды. Однако он позволяет слова и их сочетания искать в прошлом проекта, что бывает очень полезно.
Ищет слова tst в проекте:
Подсчитывает число упоминаний tst в проекте:
Ищет в старой версии проекта:
Команда позволяет использовать логическое И и ИЛИ.
Ищет строки, где упоминаются и первое слово, и второе:
Ищет строки, где встречается хотя бы одно из слов:
git branch — создание, перечисление и удаление веток
Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде.
Просто перечисляет существующие ветки, отметив активную:
Создаёт новую ветку new-branch:
Удаляет ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:
Удаляет ветку в любом случае:
Показывывает те ветки, среди предков которых есть определенный коммит:
Показывает коммит ответвления ветки new-name-branch от ветки master:
git checkout — переключение между ветками, извлечение файлов
Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:
Создаёт ветку, в которую и произойдет переключение:
Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:
Возвращает somefile к состоянию последнего коммита:
Возвращает somefile к состоянию на два коммита назад по ветке:
git merge — слияние веток, разрешение возможных конфликтов
Слияние веток, в отличие от обычной практики централизованных систем, в git происходит практически каждый день. Естественно, что имеется удобный интерфейс к популярной операции.
Пытается объединить текующую ветку и ветку new-feature:
В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.
Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.
Произошла неудачная попытка слияния:
Смотрим на проблемные места:
Индексируем наши изменения, тем самым снимая метки:
Совершаем коммит слияния:
Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):
Если же коммит слияния был совершен, используем команду:
git rebase — построение ровной линии коммитов
Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера, либо сам разработчик совершал в ней коммиты.
В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков.
Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.
Вариант, в котором явно указывается, что и куда накладывается:
на master накладывается активная в настоящий момент ветка:
После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования, разрешения конфликтов, файлы следует внести в индекс командой:
и продолжить наложение следующих коммитов командой:
Альтернативными выходами будут команды пропустить наложение коммита и перейти к следующему:
и отмена работы команды и всех внесенных изменений:
git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом
Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).
Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:
Git позволяет работать одновременно с несколькими ветками одного репозитория. Для добавления ветки в отдельную директорию необходимо выполнить команду:
Для просмотра всех директориев с ветками можно воспользоваться командой:
Директорию с веткой можно перести в другое место с помощью команды:
После окончания работы с веткой в директории, её можно удалить командой:
Клонирование репозитория с подмодулями
При клонировании репозитория вам необходимо инициализировать и обновить подмодули:
Запуск данной команды эквивалентен запуску команды:
после обычного клонирования репозитория
Подмодуль ссылается на конкретную коммит в другом репозитории. Чтобы получить точное состояние всех подмодулей необходимо запустить:
Для получения состояния последнего коммита всех подмодулей необходимо выполнить следующую команду:
или использовать аргументы по умолчанию команды git pull:
Эта команда просто обновляет локальную рабочую копию. При запуске команды git status каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо зафиксировать изменения:
Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:
В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:
Для перемещение подмодуля из одного места репозитория в другое место репозитория необходимо выполнить команду:
Для удаления подмодуля из репозитория необходимо удалить описание подмодуля и каталог с файлами подмодуля:
Прочие команды и необходимые возможности
Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации.
Ищет разницу текущего состояния проекта и коммита за номером… сами видите, каким:
То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:
Иногда хватает и четырех символов:
Читает лог с коммита по коммит:
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.
git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.
Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:
Помечает определенный коммит:
Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:
После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее:
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:
Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:
Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки.
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться.
Что привнес «дедушка» нынешнего коммита:
Обозначения можно объединять, чтобы добраться до нужного коммита:
Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.
Пример содержимого такого файла:
Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore.
Серверные команды репозитория
Проверяет сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория:
Переупаковывает локальный репозиторий:
Создание пустого репозитория на сервере
Импорт svn репозитория на Git-сервер
Связка локальной и удаленной ветки
Отправление ветки local в удаленный репозиторий и установка локальной ветки local отслеживаемой с origin/local:
Пометка локальной ветки как отслеживаемой с origin/local:
Создание новой пустой ветки
Создание пустой ветки с именем newbranch:
Использование Git для получения версии
Установка начала новой версии на текущий коммит:
Получение номера версии для последующие коммитов: