Cloning a repository
In this article
When you create a repository on GitHub.com, it exists as a remote repository. You can clone your repository to create a local copy on your computer and sync between the two locations.
About cloning a repository
You can clone a repository from GitHub.com to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine.
Cloning a repository pulls down a full copy of all the repository data that GitHub.com has at that point in time, including all versions of every file and folder for the project. You can push your changes to the remote repository on GitHub.com, or pull other people’s changes from GitHub.com. For more information, see «Using Git».
You can clone your existing repository or clone another person’s existing repository to contribute to a project.
Cloning a repository
On GitHub.com, navigate to the main page of the repository.
Above the list of files, click
To clone the repository using HTTPS, under «Clone with HTTPS», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click Use SSH, then click
. To clone a repository using GitHub CLI, click Use GitHub CLI, then click
. 
Change the current working directory to the location where you want the cloned directory.
Press Enter to create your local clone.
To learn more about GitHub CLI, see «About GitHub CLI.»
You can also use the GitHub URL to clone a repository.
Cloning an empty repository
An empty repository contains no files. It’s often made if you don’t initialize the repository with a README when creating it.
On GitHub.com, navigate to the main page of the repository.
To clone your repository using the command line using HTTPS, under «Quick setup», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click SSH, then click
Alternatively, to clone your repository in Desktop, click
Change the current working directory to the location where you want the cloned directory.
Press Enter to create your local clone.
Troubleshooting cloning errors
When cloning a repository it’s possible that you might encounter some errors.
If you’re unable to clone a repository, check that:
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
Использование проверки подлинности с ключом SSH
Настройте SSH с помощью командной строки. bash является общей оболочкой в Linux и macOS, а git для Windows установки добавляет ярлык для git Bash в меню. Другие среды оболочки будут работать, но не будут рассмотрены в этой статье.
Шаг 1. Создание ключей SSH
Если вы уже создали ключи SSH в системе, пропустите этот шаг и перейдите к разделу Настройка ключей SSH.
Команды здесь позволяют создавать новые ключи SSH по умолчанию, перезаписывая существующие ключи по умолчанию. Прежде чем продолжить, проверьте
/.ssh папку (например,/Хоме/Жамал/.СШ или к:\усерс\жамал\.СШ) и найдите следующие файлы:
Если эти файлы существуют, вы уже создали ключи SSH. Вы можете перезаписать ключи с помощью следующих команд или пропустить этот шаг и перейти к разделу Настройка ключей SSH для повторного использования этих ключей.
Создайте ключи SSH с помощью ssh-keygen команды из bash командной строки. Эта команда создаст 3072-разрядный ключ RSA для использования с SSH. При появлении запроса можно предоставить парольную фразу для закрытого ключа — Эта парольная фраза обеспечивает еще один уровень безопасности для закрытого ключа. Если вы выдаете парольную фразу, обязательно Настройте агент SSH для кэширования парольной фразы, чтобы не вводить его каждый раз при подключении.
Эта команда создает два ключа, необходимых для проверки подлинности SSH: ваш закрытый ключ ( id_rsa ) и открытый ключ ( id_rsa. pub ). Важно никогда не предоставлять общий доступ к содержимому закрытого ключа. Если закрытый ключ скомпрометирован, злоумышленники могут использовать его, чтобы заставить серверы подумать о том, что подключение поступает от вас.
шаг 2. добавление открытого ключа в Azure DevOps Services/тфс
Свяжите открытый ключ, созданный на предыдущем шаге, с ИДЕНТИФИКАТОРом пользователя.
Выберите + новый ключ.
Шаг 2. Добавление открытого ключа в Azure DevOps
Свяжите открытый ключ, созданный на предыдущем шаге, с ИДЕНТИФИКАТОРом пользователя.
Выберите + новый ключ.
Шаг 3. Клонирование репозитория Git с помощью SSH
Сведения о подключении по протоколу SSH из существующего клонированного репозитория см. в разделе обновление удаленных служб до SSH.
Project url-адреса были изменены в выпуске Azure DevOps Services и теперь имеют формат dev.azure.com/
Выполните git clone в командной строке.
SSH отображает этот отпечаток при подключении к неизвестному узлу и защищает вас от атак типа «злоумышленник в середине». Приняв отпечаток узла, SSH не выводит запрос повторно, пока отпечаток не изменится.
Вопросы и устранение неполадок
Вопрос. После выполнения git clone я получаю следующую ошибку. Что следует делать?
Ответ . Вручную запишите ключ SSH, выполнив команду:
Вопрос. как с помощью Git запоминать парольную фразу для моего ключа на Windows?
Ответ . выполните следующую команду, входящую в Git, чтобы Windows запустить процесс в PowerShell или в Windows командной строке. ssh-agent кэширует вашу парольную фразу, чтобы не указывать ее при каждом подключении к репозиторию.
Если вы используете оболочку Bash (включая Git bash), запустите ssh-agent с:
Вопрос. я использую в качестве моего клиента SSH ввод и создал ключи с помощью PuTTYgen. Можно ли использовать эти ключи с Azure DevOps Services?
Ответ. Да. Загрузите закрытый ключ с помощью PuTTYgen, перейдите в меню преобразования и выберите Экспорт ключа OpenSSH. Сохраните файл закрытого ключа и выполните действия по настройке ключей, не относящихся к по умолчанию. Скопируйте открытый ключ непосредственно из окна PuTTYgen и вставьте в поле Data ( Ключевые данные ) в параметры безопасности.
Вопрос. Как убедиться, что открытый ключ, который я отправил, имеет тот же ключ, что и локальный?
Ответ . Отпечаток открытого ключа, который отображается в профиле, можно проверить с помощью следующей команды, выполняемой для открытого ключа в bash командной строке. Если значения по умолчанию не используются, необходимо будет изменить путь и имя файла открытого ключа.
Затем можно сравнить сигнатуру MD5 с той, которая есть в вашем профиле. Эта проверка полезна при возникновении проблем с подключением или при неправильном вводе открытого ключа в поле данных ключа при добавлении ключа в Azure DevOps Services.
Вопрос. как начать использовать SSH в репозитории, где сейчас используется протокол HTTPS?
Ответ . Вам потребуется обновить Удаленный в Git, чтобы изменить URL-адрес HTTPS на SSH. Получив URL-адрес клона SSH, выполните следующую команду:
вопрос. я использую Git LFS с Azure DevOps Services и получаю сообщения об ошибках при получении файлов, отслеживаниющих с помощью Git LFS.
ответ . Azure DevOps Services сейчас не поддерживает LFS через SSH. Используйте HTTPS для подключения к репозиториев с отслеживанием файлов LFS Git.
Вопрос. как использовать расположение ключа не по умолчанию, т. е. not/.СШ/id_rsa и
Ответ . Чтобы использовать ключи, созданные в, в другом месте, отличном от используемого по умолчанию, выполните следующие две задачи:
в Windows перед запуском необходимо ssh-add выполнить следующую команду из команды, включенной в Git, для Windows:
Эта команда выполняется как в PowerShell, так и в командной строке. При использовании git Bash необходимо использовать следующие команды:
его можно найти ssh-add как часть Git для Windowsного распространения, а также запускать в любой среде оболочки на Windows.
Вопрос. у меня несколько ключей SSH. Разделы справки использовать разные ключи SSH для разных серверов SSH или репозиториев?
Ответ . Как правило, если вы настроили несколько ключей для клиента SSH и подключились к серверу SSH, клиент может попытаться использовать ключи по одному, пока сервер не примет его.
однако это не работает с Azure DevOps по техническим причинам, связанным с протоколом ssh, и о том, как структурированы url-адреса SSH Git. Azure DevOps будет отменять первый ключ, предоставляемый клиентом во время проверки подлинности. Если этот ключ недопустим для запрошенного репозитория, запрос завершится со следующей ошибкой:
для Azure DevOps необходимо настроить SSH для явного использования определенного файла ключа. Один из способов сделать это для изменения
/.ssh/config файла (например, /home/jamal/.ssh или C:\Users\jamal\.ssh ) следующим образом:
Вопрос. Разделы справки исправить ошибки с упоминанием «не найден соответствующий метод обмена ключами»?
Ответ . Git для Windows 2.25.1 поставляется с новой версией OpenSSH, которая по умолчанию удалила некоторые протоколы обмена ключами. в частности, определено diffie-hellman-group14-sha1 как проблематичное для некоторых Azure DevOps Server и клиентов TFS. Эту проблему можно обойти, добавив следующую команду в конфигурацию SSH (
Вопрос. какие уведомления могут получать сведения о ключах SSH?
Ответ . при регистрации нового ключа ssh с Azure DevOps Services вы получите уведомление по электронной почте о том, что в учетную запись добавлен новый ключ ssh.
Вопрос. что делать, если я полагаю, что кто-то, помимо меня, добавляет ключи SSH в мою учетную запись?
Ответ . Если вы получили уведомление о регистрации SSH-ключа и вы не перегрузили его в службу вручную, возможно, ваши учетные данные были скомпрометированы.
Следующий шаг — выяснить, не был ли ваш пароль скомпрометирован. Изменение пароля всегда является хорошим первым шагом для защиты от этого вектора атак. если вы являетесь Azure Active Directory пользователем, обратитесь к администратору, чтобы проверить, использовалась ли ваша учетная запись из неизвестного источника или расположения.
Ответ . некоторые дистрибутивы linux, например Fedora Linux, имеют политики шифрования, требующие более строгих алгоритмов подписи SSH, чем поддерживает Azure DevOps (по состоянию на январь 2021). Есть запрос на открытие функции для добавления этой поддержки.
Можно обойти эту ошибку, добавив следующий код в конфигурацию SSH (
Замените на ssh.dev.azure.com правильное имя узла при использовании Azure DevOps Server.
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015
URL-адреса SSH изменились, но старые URL-адреса SSH продолжат работать. Если вы уже настроили SSH, необходимо обновить удаленные URL-адреса в новом формате:
начиная с Visual Studio 2017 можно использовать SSH для подключения к Azure DevOps репозиториев Git.
Как работает проверка подлинности SSH-ключа
Проверка подлинности с помощью открытого ключа SSH работает с асимметричной парой созданных ключей шифрования. открытый ключ предоставляется Azure DevOps и используется для проверки первоначального ssh-подключения. Закрытый ключ обеспечивает безопасность и безопасность в системе.
Настройка проверки подлинности ключей SSH
Следующие шаги охватывают настройку проверки подлинности ключей SSH на следующих платформах:
Git Guides
The git clone command is used to create a copy of a specific repository or branch within a repository.
Git is a distributed version control system. Maximize the advantages of a full repository on your own machine by cloning.
What Does git clone Do?
Cloning a repository is typically only done once, at the beginning of your interaction with a project. Once a repository already exists on a remote, like on GitHub, then you would clone that repository so you could interact with it locally. Once you have cloned a repository, you won’t need to clone it again to do regular development.
The ability to work with the entire repository means that all developers can work more freely. Without being limited by which files you can work on, you can work on a feature branch to make changes safely. Then, you can:
How to Use git clone
Common usages and options for git clone
You can see all of the many options with git clone in git-scm’s documentation.
Examples of git clone
git clone A Branch
To clone one specific branch, use:
Cloning only one branch does not add any benefits unless the repository is very large and contains binary files that slow down the performance of the repository. The recommended solution is to optimize the performance of the repository before relying on single branch cloning strategies.
git clone With SSH
Depending on how you authenticate with the remote server, you may choose to clone using SSH.
Get started with git and GitHub
Review code, manage projects, and build software alongside 40 million developers.
About remote repositories
In this article
GitHub’s collaborative approach to development depends on publishing commits from your local repository to GitHub for other people to view, fetch, and update.
About remote repositories
A remote URL is Git’s fancy way of saying «the place where your code is stored.» That URL could be your repository on GitHub, or another user’s fork, or even on a completely different server.
You can only push to two types of URL addresses:
Creating remote repositories
You can use the git remote add command to match a remote URL with a name. For example, you’d type the following in the command line:
You can use the command git remote set-url to change a remote’s URL.
Choosing a URL for your remote repository
There are several ways to clone repositories available on GitHub.com.
When you view a repository while signed in to your account, the URLs you can use to clone the project onto your computer are available below the repository details.
For information on setting or changing your remote URL, see «Managing remote repositories.»
Cloning with HTTPS URLs
The https:// clone URLs are available on all repositories, regardless of visibility. https:// clone URLs work even if you are behind a firewall or proxy.
If you are accessing an organization that uses SAML SSO, you must also authorize your personal access token to access the organization before you authenticate. For more information, see «About authentication with SAML single sign-on» and «Authorizing a personal access token for use with SAML single sign-on.»
Tips:
If you’d rather use SSH but cannot connect over port 22, you might be able to use SSH over the HTTPS port. For more information, see «Using SSH over the HTTPS port.»
Cloning with SSH URLs
SSH URLs provide access to a Git repository via SSH, a secure protocol. To use these URLs, you must generate an SSH keypair on your computer and add the public key to your account on GitHub.com. For more information, see «Connecting to GitHub with SSH.»
If you are accessing an organization that uses SAML single sign-on (SSO), you must authorize your SSH key to access the organization before you authenticate. For more information, see «About authentication with SAML single sign-on» and «Authorizing an SSH key for use with SAML single sign-on.»
Tip: You can use an SSH URL to clone a repository to your computer, or as a secure way of deploying your code to production servers. You can also use SSH agent forwarding with your deploy script to avoid managing keys on the server. For more information, see «Using SSH Agent Forwarding.»
Cloning with GitHub CLI
You can also install GitHub CLI to use GitHub workflows in your terminal. For more information, see «About GitHub CLI.»
Cloning with Subversion
You can also use a Subversion client to access any repository on GitHub. Subversion offers a different feature set than Git. For more information, see «What are the differences between Subversion and Git?»
You can also access repositories on GitHub from Subversion clients. For more information, see «Support for Subversion clients.»
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
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-сервер
