Git Guides

git push uploads all local branch commits to the corresponding remote branch.

What Does git push Do?

git push updates the remote branch with local commits. It is one of the four commands in Git that prompts interaction with the remote repository. You can also think of git push as update or publish.

By default, git push only updates the corresponding branch on the remote. So, if you are checked out to the master branch when you execute git push , then only the master branch will be updated. It’s always a good idea to use git status to see what branch you are on before pushing to the remote.

How to Use git push

After you make and commit changes locally, you can share them with the remote repository using git push . Pushing changes to the remote makes your commits accessible to others who you may be collaborating with. This will also update any open pull requests with the branch that you’re working on.

As best practice, it’s important to run the git pull command before you push any new changes to the remote branch. This will update your local branch with any new changes that may have been pushed to the remote from other contributors. Pulling before you push can reduce the amount of merge conflicts you create on GitHub — allowing you to resolve them locally before pushing your changes to the remote branch.

Common usages and options for git push

• git push -f : Force a push that would otherwise be blocked, usually because it will delete or overwrite existing commits (Use with caution!)
• git push -u origin [branch] : Useful when pushing a new branch, this creates an upstream tracking branch with a lasting relationship to your local branch
• git push —all : Push all branches
• git push —tags : Publish tags that aren’t yet in the remote repository

You can see all of the options with git push in git-scm’s documentation.

Why can’t I push?

If you are trying to git push but are running into problems, there are a few common solutions.

Check your branch

Check what branch you are currently on with git status . If you are working on a protected branch, like master , you may be unable to push commits directly to the remote. If this happens to you, it’s OK! You can fix this a few ways.

Work was not yet on any branch

1. Create and checkout to a new branch from your current commit: git checkout -b [branchname]
2. Then, push the new branch up to the remote: git push -u origin [branchname]

Accidentally committed to the wrong branch

1. Checkout to the branch that you intended to commit to: git checkout [branchname]
2. Merge the commits from the branch that you did accidentally commit to: git merge [master]
3. Push your changes to the remote: git push
4. Fix the other branch by checking out to that branch, finding what commit it should be pointed to, and using git reset —hard to correct the branch pointer

• git commit -m «descriptive message» : Records file snapshots permanently in version history.
• git clone [url] : Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits.
• git status : Always a good idea, this command shows you what branch you’re on, what files are in the working or staging directory, and any other important information.
• git pull : Updates your current local working branch with all new commits from the corresponding remote branch on GitHub. git pull is a combination of git fetch and git merge .

Get started with git and GitHub

Review code, manage projects, and build software alongside 40 million developers.

Pushing changes to GitHub

As you commit changes to your project locally, you can push those changes to GitHub so that others may access them from the remote repository.

People with write permissions can push changes to a repository.

In this article

About pushing changes to GitHub

When you push changes, you send the committed changes in your local repository to the remote repository on GitHub. If you change your project locally and want other people to have access to the changes, you must push the changes to GitHub.

Before pushing changes, you should update your local branch to include any commits that have been added to the remote repository. If someone has made commits on the remote that are not on your local branch, GitHub Desktop will prompt you to fetch the new commits before pushing your changes to avoid merge conflicts. For more information, see «Syncing your branch.»

Repository administrators can enable protections on a branch. If you’re working on a branch that’s protected, you won’t be able to delete or force push to the branch. Repository administrators can enable other protected branch settings to enforce specific workflows before a branch can be merged. For more information, see «About protected branches.»

Pushing changes to GitHub

Note: GitHub Desktop will reject a push if it exceeds certain limits.

• A push contains a large file over 100 MB in size.
• A push is over 2 GB in total size.

If you configure Git Large File Storage to track your large files, you can push large files that would normally be rejected. For more information, see «About Git Large File Storage and GitHub Desktop.»

Git push

Команда git push используется для выгрузки содержимого локального репозитория в удаленный репозиторий. Она позволяет передать коммиты из локального репозитория в удаленный. Эта команда симметрична команде git fetch : при извлечении с помощью fetch коммиты импортируются в локальные ветки, а при публикации с помощью push коммиты экспортируются в удаленные ветки. Настроить удаленные ветки можно с помощью команды git remote . Команда push может перезаписать изменения, поэтому при ее использовании следует соблюдать осторожность. Эти проблемы обсуждаются ниже.

Использование git push

Публикация указанной ветки в удаленном репозитории вместе со всеми необходимыми коммитами и внутренними объектами. Эта команда создает локальную ветку в репозитории назначения. Чтобы предотвратить перезапись коммитов, Git не позволит опубликовать данные, если в репозитории назначения нельзя выполнить ускоренное слияние.

Аналогично приведенной выше команде, однако данные будут опубликованы принудительно, даже если нельзя выполнить ускоренное слияние. Не используйте флаг —force , если вы не уверены в своих действиях.

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

При публикации ветки или использовании опции —all теги не публикуются автоматически. Флаг —tags отправляет все локальные теги в удаленный репозиторий.

Обсуждение git push

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

На рисунке выше показано, что происходит, когда ваша локальная ветка master изменяет предыдущие коммиты ветки master центрального репозитория и вы публикуете изменения с помощью команды git push origin master . Обратите внимание, что команда git push по сути аналогична команде git merge master , запущенной из удаленного репозитория.

Git push и синхронизация

Команда git push — это один из многих компонентов, которые используются в общем процессе синхронизации в Git. Команды синхронизации работают с удаленными ветками, которые настраиваются с помощью команды git remote . Команду git push можно рассматривать как команду «выгрузки», а команды git fetch и git pull — как команды «загрузки». После того как наборы изменений перемещены посредством «загрузки» или «выгрузки», в месте назначения можно интегрировать изменения, выполнив их слияние командой git merge .

Публикация в чистые репозитории

В настоящее время в качестве центрального исходного репозитория Git часто используют удаленно размещенный чистый ( —bare ) репозиторий. Этот исходный репозиторий размещается за пределами рабочего места у доверенной третьей стороны, например в Bitbucket. Поскольку при публикации нарушается структура удаленных веток, наиболее безопасный и распространенный вариант публикации — это публикация в репозиторий, созданный с флагом —bare . Чистые репозитории не имеют рабочего каталога, поэтому при публикации содержимое рабочего каталога не изменяется. Дополнительную информацию о создании чистых репозиториев см. в документации по команде git init .

Принудительная публикация

Git предотвращает перезапись истории центрального репозитория, отклоняя push-запросы, если нельзя выполнить их ускоренное слияние. Так, если история удаленного репозитория отличается от вашей истории, необходимо загрузить удаленную ветку командой pull и выполнить ее слияние с локальной веткой командой merge, а затем попробовать выполнить команду push еще раз. Это похоже на то, как в SVN необходимо синхронизироваться с центральным репозиторием с помощью команды svn update перед тем, как сделать коммит набора изменений.

Флаг —force отменяет это поведение и подгоняет ветку удаленного репозитория под вашу локальную ветку, удаляя любые вышестоящие изменения, которые могли быть внесены с момента последнего выполнения вами команды pull. Принудительное использование команды push оправдано лишь в том случае, когда вы понимаете, что только что опубликованные вами коммиты были не совсем правильными и вы исправили их с помощью команды git commit —amend или интерактивного перебазирования. При этом прежде, чем использовать опцию —force , вы должны быть абсолютно уверены в том, что никто из участников вашей команды не забирал эти коммиты с помощью команды pull.

Примеры

Команда git push по умолчанию

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

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

Принудительная команда push при исправлении коммитов

Команда git commit имеет опцию —amend , которая позволяет обновить предыдущий коммит. В коммиты часто вносятся исправления, чтобы обновить сообщение коммита или добавить новые изменения. Если коммит был исправлен, то при выполнении команды git push произойдет сбой, так как Git воспримет исправленный и удаленный коммиты как разнородное содержимое. Опция —force позволит выполнить команду push и опубликовать измененный коммит.

В приведенном выше примере предполагается, что он выполняется в существующем репозитории с историей коммитов. Команда git commit —amend используется для обновления предыдущего коммита. Затем исправленный коммит принудительно публикуется с помощью команды push с опцией —force .

Стирание удаленной ветки или тега

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

Первая команда сотрет локальную ветку с именем branch_name. Если в команде git push перед именем ветки поставить двоеточие, будет стерта удаленная ветка.

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:

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

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 init создает в директории пустой репозиторий в виде директории .git, где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Своего рода подмножеством команды git log можно считать команду 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 позволяет переключаться между последними коммитами (если упрощенно) веток:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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