Как подключиться к удаленному репозиторию 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
В системе SVN используется единый централизованный репозиторий, служащий центром связи для разработчиков. Совместная работа ведется путем передачи наборов изменений между рабочими копиями разработчиков и центральным репозиторием. Однако модель распределенной совместной работы в Git предполагает, что каждый разработчик использует собственную копию репозитория со своей локальной историей и структурой веток. Обычно пользователи делятся не отдельными наборами изменений, а сериями коммитов. Вместо того чтобы выполнять коммит одного набора изменений из рабочей копии в центральный репозиторий, Git позволяет передавать между репозиториями целые ветки.
git remote
Команда git remote позволяет создавать, просматривать и удалять подключения к другим репозиториям. Удаленные подключения скорее похожи на закладки, чем на прямые ссылки на другие репозитории. Они служат удобными именами, с помощью которых можно сослаться на не очень удобный URL-адрес, а не предоставляют доступ к другому репозиторию в режиме реального времени.
Например, на следующем рисунке изображены два удаленных подключения из вашего репозитория к центральному репозиторию и репозиторию другого разработчика. Вместо того, чтобы ссылаться на них по их полным URL-адресам, вы можете передавать командам Git только ярлыки origin и john.
Обзор использования git remote
По сути, команда git remote — это интерфейс для управления списком записей об удаленных подключениях, которые хранятся в файле /.git/config репозитория. Для просмотра текущего состояния списка удаленных подключений используются следующие команды.
Просмотр конфигураций удаленных репозиториев Git
Список ваших удаленных подключений к другим репозиториям.
Аналогично команде выше, но включает URL-адрес каждого подключения.
Создание и изменение конфигураций удаленных репозиториев Git
Команда git remote также предоставляет удобный способ изменения файла /.git/config репозитория. Перечисленные ниже команды позволяют управлять подключениями к другим репозиториям и изменять файл /.git/config репозитория. Такого же результата можно достичь, напрямую отредактировав файл /.git/config с помощью текстового редактора.
Создание нового подключения к удаленному репозиторию. После добавления удаленного репозитория имя ＜name＞ можно использовать в качестве удобного ярлыка для адреса ＜url＞ в других командах Git.
Обсуждение git remote
Git предоставляет каждому разработчику полностью изолированную среду разработки. Информация не передается между репозиториями автоматически. Вместо этого разработчикам нужно вручную загружать вышестоящие коммиты в локальный репозиторий или вручную отправлять локальные коммиты обратно в центральный репозиторий. Команда git remote представляет собой простой способ передачи URL-адресов в эти команды обмена.
Удаленное подключение к origin
В процессе клонирования с помощью команды git clone автоматически создается удаленное подключение к исходному репозиторию (такое соединение называется origin). Это позволяет разработчикам, создающим локальную копию центрального репозитория, легко загружать вышестоящие изменения или публиковать локальные коммиты. Именно поэтому большинство проектов на основе Git называют свой центральный репозиторий origin.
URL-адреса репозиториев
Git поддерживает различные способы ссылки на удаленный репозиторий. Два наиболее простых способа доступа к удаленному репозиторию: протоколы HTTP и SSH. Протокол HTTP — простой способ разрешить к репозиторию анонимный доступ только для чтения. Пример ниже.
Однако HTTP-адрес, как правило, не позволяет отправлять коммиты (в любом случае вы не захотите разрешать анонимную отправку изменений с помощью команды push). Чтобы использовать доступ для чтения и записи следует использовать протокол SSH:
Вам понадобится лишь действующий аккаунт SSH на хост-машине, а в остальном Git поддерживает аутентифицированный доступ через SSH по умолчанию. Необходимые URL-адреса предоставляются современными безопасными решениями для хостинга от сторонних провайдеров, например Bitbucket.com.
Команды git remote
Вывод URL-адресов для записи об удаленном репозитории.
Удаляет из репозитория ＜NAME＞ все локальные ветки, которые отсутствуют в удаленном репозитории.
Примеры git remote
Доступа к индивидуальным репозиториям разработчиков позволяет вести совместную работу за пределами центрального репозитория. Это может быть очень полезно для небольших команд, работающих над большим проектом.
Просмотр удаленных репозиториев
По умолчанию команда git remote отображает ранее сохраненные удаленные подключения к другим репозиториям. Создается однострочный список закладок с именами удаленных репозиториев.
Добавление удаленных репозиториев
Проверка удаленного репозитория
Для получения подробного вывода о конфигурации удаленного репозитория к команде git remote можно добавить подкоманду show. Вывод будет содержать список веток, связанных с удаленным репозиторием, а также конечных точек, подключенных для извлечения (fetch) и отправки (push).
Получение и извлечение данных из удаленных репозиториев Git
Отправка данных в удаленные репозитории Git
Переименование и удаление удаленных репозиториев
Pro Git
Страницы
понедельник, 16 февраля 2015 г.
Чтобы иметь возможность совместной работы над каким-либо Git-проектом, необходимо знать, как управлять удалёнными репозиториями. Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push) и получение (pull) данных в и из них тогда, когда нужно обменяться результатами работы. Управление удалёнными репозиториями включает умение добавлять удалённые репозитории, удалять те из них, которые больше не действуют, умение управлять различными удалёнными ветками и определять их как отслеживаемые (tracked) или нет и прочее. Данный раздел охватывает все перечисленные навыки по управлению удалёнными репозиториями.
Чтобы разобрать примеры этой главы я создал удаленный репозитарий TestRemote на GitHub, а затем склонировал его себе.
Отображение удалённых репозиториев
Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить команду git remote. Она перечисляет список имён-сокращений для всех уже указанных удалённых дескрипторов. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали:
Чтобы посмотреть, какому URL соответствует сокращённое имя в Git, можно указать команде опцию -v:
Добавление удалённых репозиториев
Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url]:
Теперь вы можете использовать в командной строке имя tr вместо полного URL.
Например, я сделал некоторые изменения файла README.md и теперь загрузим их себе в локальный репозиторий командой git fetch:
Теперь ветка изменений с сервера доступна локально как tr/mater. Вы можете слить (merge) её в одну из своих веток или перейти на эту ветку, если хотите её проверить.
Тут надо отметить, что между командами git pull и git fetch есть разница, но об этом чуть позже.
На данный момент, если мы посмотрим содержимое файла README.md в рабочем каталоге, то оно будет точно такое же, как было до команды git fetch. Это потому, что мы в данный момент находимся в ветке master локального репозитария, которая не была изменена.
Чтобы посмотреть все существующие ветки можно дать команду git branch с ключом –a, который покажет все ветки репозитория.
Здесь активная ветка обозначена звёздочкой. А так же мы видим ветку которую мы притянули командой git fetch – это ветка remotes/tr/master. Собственно об этом нам команда git fetch и сообщила после выполнения.
Переключится на ветку можно командой git checkout
И так мы переключились на ветку которую стянули командой git fetch, о чем нам выдалось сообщение и рассказали какие файлы были обновлены. Это файл README.md. Теперь в рабочем каталоге мы можем посмотреть измененное содержимое этого файла (мы его меняли непосредственно на GitHub).
Мы так же можем переключится обратно на нашу ветку master
Теперь будем разбираться с разницей между fetch и pull.
Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
$ git fetch [имя удал. сервера]
Push
Когда вы хотите поделиться своими наработками, вам необходимо отправить (push) их в главный репозиторий. Команда для этого действия простая: git push [удал. сервер] [ветка]. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование, как правило, настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки наработок на сервер:
$ git push origin master
Я выполнил команды pull и объединил изменения для файла README.md и затем залил их на сервер GitHub. Скрин привожу просто для информации чтобы было видно как это делается.
Более подробно как отправлять (push) данные на удалённый сервер мы рассмотрим чуть позже.
Инспекция удалённого репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show [удал. сервер]. Если вы выполните эту команду с некоторым именем, например, origin, вы получите что-то подобное:
Удаление и переименование удалённых репозиториев
Для переименования ссылок в новых версиях Git’а можно вылолнить git remote rename, это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать tr в tstrmt, вы можете сделать это следующим образом:
Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как tr/master, стало tstrmt/master.
Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm:
Использование проверки подлинности с ключом 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 на следующих платформах: