Push git что это
Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push
. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Просмотр удаленного репозитория
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Удаление и переименование удалённых репозиториев
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Git Push – вносим изменения на GitHub
Команда git push при выполнении перемещает изменения, внесенные пользователем на локальном компьютере, в удаленный репозиторий. После того как пользователи клонировали удаленный репозиторий и внесли необходимые изменения в свое локальное устройство, эти изменения должны быть перенесены в удаленный репозиторий. Причина в том, что они являются общими и используются другими пользователями. Команда git push делает это. Эти изменения представляют собой обязательства, выполненные в репозитории, а не незафиксированные изменения (если таковые имеются).
Кроме того, изменения, которые пользователь вносит в локальную систему, не имеют никакой ценности для участников и зрителей, если облако GitHub не отражает их.
Чтобы иметь возможность перейти в удаленный репозиторий, вы должны убедиться, что все ваши изменения в локальном репозитории зафиксированы.
Рассмотрим git push как часть процесса синхронизации в Git. Синхронизация происходит между локальным и удаленным хранилищем, где источник и приемник могут отличаться. Есть много других частей для синхронизации, и git push-это одна из частей, потому что она загружает изменения, сделанные в локальном репозитории, чтобы поддерживать удаленный репозиторий в актуальном состоянии. В этом нет ничего сложного, и концепция проста, как и ее синтаксис.
Приведенного выше изображения достаточно для понимания концепции в двух словах.
Пользователь клонирует репозиторий в качестве первого шага, чтобы внести некоторые изменения в репозиторий.
После этого он приступает к внесению изменений в локальную систему и добавляет эти изменения в промежуточную область.
После завершения всех изменений пользователь затем фиксирует все изменения в локальном репозитории.
А затем передает эти изменения на удаленный сервер. Наконец, он синхронизирует локальный и удаленный репозитории.
Синтаксис команды git Push в Git
Выполнение команды git push происходит путем ввода следующей команды:
git push
remote_repo: это имя (или псевдоним) удаленного репозитория, в который мы переносим изменения.
branch_name: это ветвь, которую пользователь толкает в удаленный репозиторий.
Представьте себе, что ветвь (branch) в Git подобна ветвям в дереве. Каждая ветвь представляет собой новую функцию или модификацию, находящуюся в стадии разработки. Кроме того, основная ветвь — это стабильный код, подобный стволу дерева, также называемый master branch (главной ветвью). Что, в свою очередь, помогает нестабильному коду ветвей держаться подальше от стабильного основного кода.
Как перенести изменения из локального репозитория в удаленный репозиторий в Git
Чтобы протолкнуть некоторые изменения в удаленный репозиторий, этот репозиторий должен, прежде всего, содержать некоторые коммиты в локальной системе. Поэтому в этом разделе мы сначала создадим некоторые изменения в репозитории. Во-вторых, мы зафиксируем эти изменения и, наконец, отразим их в удаленном репозитории.
Перед созданием изменений в репозитории убедитесь, что вы выполнили следующие операции:
Примечание: в этом уроке мы будем использовать репозиторий ToolsQA, который уже был разветвлен и клонирован в предыдущих уроках. Пользователь может свободно использовать любой публичный репозиторий. Однако рекомендуется использовать один и тот же репозиторий для этого урока.
В качестве хорошей практики сначала проверьте, что у вас есть чистый репозиторий с помощью команды git status (никаких ожидающих изменений для фиксации).
После выполнения команды git status появятся следующие строки:
On branch master: означает, что в данный момент мы находимся в главной ветви. Поскольку других ветвей пока нет, мы по умолчанию находимся в главной ветви.
Your branch is up to date with origin/master: Origin — это имя удаленного репозитория, которое мы дали при подключении локального репозитория к удаленному репозиторию.
Последовательность действий
Так как существует только один файл (README.md это всего лишь инструкция), давайте внесем некоторые изменения в его содержание.
Примечание: GitHub и Git распознают любые изменения только через коммиты (commits). Если пользователь не зафиксировал изменения и пытается протолкнуть их на GitHub, он отобразит сообщение “Everything is up-to-date”
git push origin master
Примечание: последние две строки выглядят следующим образом:
https://github.com/harishrajora805/ToolsQA.git: URL-адрес репозитория, который отражает изменения.
1в4522а..285f559: показывает хэш-значение обеих ветвей. Таким образом, хэш-значение конечного коммита, отраженного на GitHub, равно 285f559.
Строка Writing Objects: 100% имеет важное значение. В Git можно сказать, была ли команда push выполнена успешно или нет, только взглянув на эту строку. Если она показывает 100%, то все изменения успешно перенесены в облако.
Наряду с простой и понятной командой, которую мы обсуждали выше, как и любую другую команду в Git, мы можем использовать параметры при выполнении команды для достижения конкретной задачи. Например, если вы хотите протолкнуть все ветви, вы будете использовать опцию all и так далее. Давайте рассмотрим некоторые из вариантов в Git.
Варианты Git Push
В git push command доступно множество опций, которые помогают нам достичь определенных конкретных задач всего за одно выполнение. В этом разделе мы рассмотрим основные и наиболее часто используемые параметры команды git push.
Prune Option
— опция prune в команде git push удалит ветвь XYZ из удаленного репозитория, если в локальном репозитории не существует ветви с таким же именем.
Использование: git push –prune remote XYZ
Dry Run Option
Эта опция будет выполнять и показывать выполнение команды git push, но не будет отправлять никаких обновлений в удаленный репозиторий.
Использование: git push –dry-run
Atomic Option
Эта опция в git Push обеспечивает атомарную операцию на удаленном репозитории, т. е. либо каждую ссылку обновляет, либо вообще ничего.
All Option
Все опции будут выталкивать все ветви и их зафиксированные изменения в удаленный репозиторий.
Использование: git push-all
В последнем уроке мы познакомились с командой Git fetch и Read more
В одной из последних статей мы узнали о команде Git Read more
Мы уже знаем, как вносить изменения в локальное хранилище и Read more
«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more
Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more
Все данные, доступные в локальном репозитории, могут быть загружены в Read more
Git push, git pull, git fetch — в чем разница? Шпаргалка по git-командам
Git — это распределенная система контроля версий. Она позволяет хранить данные обо всех изменениях кода в конкретных папках на жестком диске и обеспечивает удобную командную работу.
Git push
Команда git push в ходе выполнения переносит все изменения, внесенные юзером, в удаленный репозиторий (например, такой как GitHub):
Вынужденная команда push при корректировке коммитов:
Git pull
Команда git pull отвечает за скачивание данных с сервера. Процесс очень похож на клонирование репозитория, но здесь скачиваются не все коммиты, а только новые.
По сути, git pull — это сочетание команд git fetch (загружает коммиты, ссылки, файлы из удаленного репозитория в локальный) и git merge (объединяет несколько коммитов в один общий).
Git pull для удаленной ветки
Git fetch
Синхронизация с командой git fetch origin
Это отобразит ветки, которые уже были загружены:
Git merge
Команда git merge связывает ряд коммитов в одно целое. В свою очередь git создает коммит слияния, где и объединяются изменения обеих последовательностей.
Конфликт в слиянии
По завершению слияния, выполните команду git add : таким образом вы проинформируете, что причина конфликта разрешена. Важно запомнить, что конфликты допустимы только в трехслойном слиянии и никогда не возникают при ускоренном.
Разница между командами git
Условно говоря, git pull – это последовательность двух команд: git fetch (прием изменений от сервера) и git merge (слияние).
В свою очередь, git push переносит ветвь разработки в удаленную исходную точку, а git merge — объединяет изменения из разработки в локальную ветку.
Шпаргалка по git-командам
git init — создание новых репозиториев;
git clone — клонирование удаленного репозитория;
git rm — удаление файла;
git log — просмотр истории коммитов;
git branch
— создание новой ветки;
git branch –d
— удаление ветки;
git merge
— слияние веток;
git push
— отправка ветки на удаленный сервер;
git push :
— удаление ветки на удаленном сервере;
git tag — просмотр меток;
git push — обмен метками;
git remote — отображение удаленных репозиториев;
git pull
— получение данных из удаленного репозитория и слияние с локальным;
git push
— отправка локальных изменений на удаленный сервер.
2. Основы работы с Git¶
Введение¶
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе 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:
-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 fetch username-project — забрать изменения по адресу, определяемому синонимом.
Команда 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 rm :
хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:
внести в индекс все удаленные файлы:
Сбросить весь индекс или удалить из него изменения определенного файла можно
командой git reset :
сбросить весь индекс:
удалить из индекса конкретный файл:
Команда git reset используется не только для сбрасывания индекса, поэтому дальше
ей будет уделено гораздо больше внимания.
git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы
Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и
файлы, игнорируемые git.
git commit — совершение коммита
Коммит — базовое понятие во всех системах контроля версий, поэтому совершаться
он должен легко и по возможности быстро. В простейшем случае достаточно
после индексации набрать:
Есть несколько ключей, упрощающих работу с git commit :
совершит коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено.
комментируем коммит прямо из командной строки вместо текстового редактора.
внесет в индекс и создаст коммит на основе изменений единственного файла.
git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).
Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.
Естественно, можно вернуться и на большую глубину коммитов,
Если команда достигнет точки ветвления, удаления коммита не произойдет.
Для команд слияния или выкачивания последних изменений с удаленного репозитория
примеры резета будут приведены в соответствующих разделах.
git revert — отмена изменений, произведенных в прошлом отдельным коммитом
Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.
Отменяем коммит, помеченный тегом:
Отменяем коммит, используя его хэш:
Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.
git log — разнообразная информация о коммитах в целом
Простейший пример использования, в котором приводится короткая справка по всем
коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
подробно узнать можно ниже, в разделе «Ветвления и слияния»):
За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
—summary :
Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):
или, если версия git не совсем свежая:
Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):
изменения, касающиеся отдельной папки:
Можно отталкиваться от тегов.
Все коммиты, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:
Вывести на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше):
Лаконичная информация о коммитах, приводятся только автор и комментарий:
Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:
В принципе, формат вывода можно определить самостоятельно:
git diff — отличия между деревьями проекта, коммитами и т.д.
Показать изменения, не внесенные в индекс:
Изменения, внесенные в индекс:
Изменения в проекте по сравнению с последним коммитом:
Можно сравнивать «головы» веток:
или активную ветку с какой-либо:
git show — показать изменения, внесенные отдельным коммитом
Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show :
git blame и git annotate — команды, помогающие отслеживать изменения файлов
Можно указать и конкретные строки для отображения:
git grep — поиск слов по проекту, состоянию проекта в прошлом
Поиск слова tst в проекте:
Подсчитать число упоминаний tst в проекте:
Поиск в старой версии проекта:
Команда позволяет использовать логическое И и ИЛИ.
Найти строки, где упоминаются и первое слово, и второе:
Найти строки, где встречается хотя бы одно из слов:
Ветвление¶
git branch — создание, перечисление и удаление веток
Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде:
Просто перечислить существующие ветки, отметив активную:
Создать новую ветку new-branch:
Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:
Удалить ветку в любом случае:
Показать те ветки, среди предков которых есть определенный коммит:
git checkout — переключение между ветками, извлечение файлов
Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:
Создаст ветку, в которую и произойдет переключение
Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:
Вернуть somefile к состоянию последнего коммита:
Вернуть somefile к состоянию на два коммита назад по ветке:
git merge — слияние веток (разрешение возможных конфликтов)
Слияние веток, в отличие от обычной практики централизованных систем, в git происходит практически каждый день. Естественно, что имеется удобный интерфейс к популярной операции.
Попробовать объединить текующую ветку и ветку new-feature:
В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.
Произошла неудачная попытка слияния:
Смотрим на проблемные места:
Индексируем наши изменения, тем самым снимая метки:
Совершаем коммит слияния:
Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):
Если же коммит слияния был совершен, используем команду:
git rebase — построение ровной линии коммитов
Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера, либо сам разработчик совершал в ней коммиты.
Предположим, имеется две ветки, master и topic, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.
Вариант, в котором явно указывается, что и куда накладывается:
на master накладывается активная в настоящий момент ветка:
git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом
Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).
Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:
Прочие команды и необходимые возможности¶
Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации:
найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:
То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:
Иногда хватает и четырех символов:
Читаем лог с коммита по коммит:
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.
git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.
Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:
Пометить определенный коммит:
Создать тэг для последнего коммита, заменить существующий, если таковой уже был:
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
Создать обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:
Создать обычный тэг, сразу указав в качестве аргумента комментарий:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.
Относительная адресация
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:
найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться:
что привнес «дедушка» нынешнего коммита:
Обозначения можно объединять, чтобы добраться до нужного коммита:
Пример содержимого такого файла:
Серверные команды репозитория¶
; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
; git gc : Переупаковка локального репозитория.
Рецепты¶
Создание пустого репозитория на сервере
Импорт svn репозитория на Git-сервер