2.5 Основы Git — Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:
Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add <shortname> <url> :
Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :
Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config —global pull.rebase «false»
Если хотите использовать перебазирование при получении изменений: git config —global pull.rebase «true»
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push <remote-name> <branch-name> . Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.
Просмотр удаленного репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show <remote> . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:
Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .
Удаление и переименование удалённых репозиториев
Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :
Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Как скопировать ссылку на репозиторий git
Open banking has made financial transactions easier and more secure for those with multiple banking accounts; however, .
REST may be a somewhat non-negotiable standard in web API development, but has it fostered overreliance? Learn why other design .
Developers can use Microsoft Azure Logic Apps to build, deploy and connect scalable cloud-based workflows. Learn how it measures .
A new CLI extension and other features due to ship this month lay the groundwork to help developers make better use of software .
GitHub has added SMS support and fresh account lockout prevention features to its phased rollout plans as it prepares to .
The new API is faster and cheaper than the previous ChatGPT interface, and users can opt out of submitting their data to it, .
AWS Compute Optimizer and Cost Explorer monitor, analyze and optimize your cloud costs. Compare the two tools to choose which is .
Azure management groups, subscriptions, resource groups and resources are not mutually exclusive. Businesses can — and often do .
Amazon CodeGuru reviews code and suggests improvements to users looking to make their code more efficient as well as optimize .
While some 2022 ransomware statistics indicate a possible ‘decline’ in activity, threat researchers warn there’s more to the .
IceFire ransomware actors have shifted their attention to Linux servers and are actively exploiting a known vulnerability in .
Adopting extended detection and response and employing managed detection and response services may be the missing pieces of the .
Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates .
There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service .
AWS users face a choice when deploying Kubernetes: run it themselves on EC2 or let Amazon do the heavy lifting with EKS. See .
About remote repositories
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:
- An HTTPS URL like https://github.com/user/repo.git
- An SSH URL, like git@github.com:user/repo.git
Git associates a remote URL with a name, and your default remote is usually called origin .
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:
This associates the name origin with the REMOTE_URL .
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.
When you git clone , git fetch , git pull , or git push to a remote repository using HTTPS URLs on the command line, Git will ask for your GitHub username and password. When Git prompts you for your password, enter your personal access token. Alternatively, you can use a credential helper like Git Credential Manager. Password-based authentication for Git has been removed in favor of more secure authentication methods. For more information, see «Creating a personal access token.»
If you are accessing an organization that uses SAML SSO and you are using a personal access token (classic), 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:
- You can use a credential helper so Git will remember your GitHub credentials every time it talks to GitHub. For more information, see «Caching your GitHub credentials in Git.»
- To clone a repository without authenticating to GitHub on the command line, you can use GitHub Desktop to clone instead. For more information, see «Cloning a repository from GitHub to GitHub Desktop.»
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.»
When you git clone , git fetch , git pull , or git push to a remote repository using SSH URLs, you’ll be prompted for a password and must provide your SSH key passphrase. For more information, see «Working with SSH key passphrases.»
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» in the GitHub Enterprise Cloud documentation.
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
Note: Subversion support will be removed from GitHub on January 8, 2024. A future release of GitHub Enterprise Server after January 8, 2024 will also remove Subversion support. To read more about this, see the GitHub blog.
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.
Создание pull-запроса на GitHub
Распределённая система контроля версий Git обеспечивает простоту поддержки и разработки открытого программного обеспечения, в создании которого участвует команда специалистов. Сама система Git является ярким примером проекта с открытым исходным кодом. Множество проектов хранят файлы в репозиториях Git, а такие сайты как GitHub позволяют быстро внести свой вклад в развитие того или иного проекта.
Проекты с открытым исходным кодом, размещённые в публичных репозиториях, развиваются за счет вклада широкого сообщества разработчиков с помощью. Проект принимает внесённые в код изменения с помощью pull-запросов.
Данное руководство научит вас делать pull-запросы в репозитории Git с помощью командной строки.
Требования
- Предварительно установленная система контроля версий Git. Подробные инструкции по установке можно найти здесь.
- Аккаунт GitHub. Регистрация бесплатная. Чтобы зарегистрироваться, укажите имя пользователя и адрес электронной почты.
- Проект, в разработке которого вы хотите участвовать. Больше информации об открытых проектах можно найти здесь.
Создание копии репозитория
Репозиторий – это главная папка проекта. Репозиторий содержит все файлы проекта, включая документацию и хронологию изменений для каждого файла. Репозитории на GitHub могут иметь несколько соавторов, также они могут быть публичными и приватными.
Чтобы начать работу над открытым проектом, нужно сначала создать собственную копию репозитория. Чтобы получить локальную рабочую копию кода, создайте форк проекта (ветвление, fork) и клонируйте его.
Форк проекта
Чтобы создать форк репозитория GitHub, откройте сайт GitHub и найдите открытый проект, в разработке которого вы хотите участвовать. Ссылки GitHub содержат имя владельца проекта и название самого проекта.
К примеру, репозиторий проекта node-chakracore принадлежит nodejs, значит, ссылка GitHub будет выглядеть так:
где nodejs – имя пользователя, node-chakracore – имя репозитория.
Выберите проект, в котором вы хотите принять участие, и откройте его репозиторий на GitHub.
На главной странице проекта вы увидите кнопку Fork под вашим значком пользователя.
Чтобы начать форк репозитория, нажмите кнопку Fork. В окне браузера появится следующее сообщение:
Forking nodejs/node-chakracore
It should only take a few seconds.
Когда процесс будет выполнен, в браузере вы увидите такой же репозиторий, как и раньше, но в ссылке уже будет указано ваше имя.
Теперь можно клонировать репозиторий и получить локальную копию кода.
Клонирование репозитория
Чтобы создать локальную копию кода проекта, откройте терминальное окно. Используйте команду git clone и укажите ссылку на форк репозитория.
Эта ссылка почти такая же, как и предыдущая, и отличается только тем, что заканчивается расширением .git, например:
Скопировать эту ссылку можно с помощью зелёной кнопки Clone or download на странице репозитория. Справа от ссылки появится кнопка, с помощью которой можно скопировать ссылку.
Теперь можно добавить скопированный URL в команду git clone:
git clone https://github.com/your-username/repository.git
Создание новой ветки
Работая над открытым проектом, разработчики предлагают внедрить в основной код различные новые функции и исправления. Некоторые идеи можно реализовать в короткие сроки, в то же время на реализацию других идей может уйти много времени и ресурсов. Поэтому разработчики создают ветку репозитория: это позволяет управлять рабочим процессом, изолировать изменения друг от друга и выбирать функции, которые нужно добавить в основную ветку репозитория проекта.
По умолчанию главная ветка репозитория называется master. Код, который находится в главной ветке, может развернуть любой пользователь.
Создавая новую ветку из ветки master, важно выбрать описательное имя: например, вместо my-branch лучше использовать frontend-hook-migration или fix-documentation-typos.
Чтобы создать ветку, откройте окно терминала и перейдите в репозиторий:
Примечание: Замените repository названием своего репозитория.
Затем используйте команду git branch:
git branch new-branch
Примечание: Вместо new-branch укажите описательное имя ветки.
Чтобы перейти на новую ветку, используйте команду:
git checkout new-branch
Switched to branch ‘new-branch’
С помощью флага -b можно объединить две предыдущие команды в одну, которая создаст новую ветку и переключится на неё:
git checkout -b new-branch
Чтобы вернуться на ветку master, используйте команду checkout и укажите имя ветки:
git checkout master
С помощью этой команды можно переключаться между различными ветками.
Теперь можно приступать к созданию новых и редактированию существующих файлов.
Локальные изменения кода
Внеся изменения в код, вы можете добавить их в локальный реопзиторий с помощью команды git add. Чтобы добавить все изменения в репозиторий, используйте флаг –A.
Чтобы записать изменения, добавленные в репозиторий, используйте команду git commit.
Создание сообщения коммита – очень важный этап работы над открытым проектом. Это сообщение позволяет другим разработчикам понять, что именно вы изменили в коде и почему это изменение важно. Кроме того, сообщения коммитов предоставляют хронологическую запись изменений проекта в целом, помогая новым разработчикам понять, как развивался проект.
Короткое сообщение коммита можно отправить с помощью флага –m, например:
git commit -m «Fixed documentation typos»
Но если вы внесли существенные изменения в код проекта, вы должны написать более подробное сообщение. Для этого введите:
Команда откроет текстовый редактор. Если вы хотите выбрать текстовый редактор для создания коммита, добавьте название редактора в команду:
git config —global core.editor «nano»
или
git config —global core.editor «vim»
После запуска команды git commit на экране появится документ в текстовом редакторе, который выглядит примерно так:
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
# On branch new-branch
# Your branch is up-to-date with ‘origin/new-branch’.
#
# Changes to be committed:
# modified: new-feature.py
#
Под комментариями вы можете добавить сообщение коммита.
Чтобы сообщение коммита было полезным для других разработчиков, поместите в начале сообщения краткое описание изменений длиной около 50 символов. Далее добавьте несколько разделов:
- раскройте причину, по которой вы внесли это изменение в код;
- опишите, как работает код;
- предоставьте дополнительную информацию, которая может пригодиться другим разработчикам.
Постарайтесь предоставить в сообщении максимум полезной информации.
Сохраните и закройте текстовый файл с коммитом. После этого можно проверить его состояние:
Команда должна вернуть примерно такой вывод:
On branch new-branch
Your branch is ahead of ‘origin/new-branch’ by 1 commit.
(use «git push» to publish your local commits)
nothing to commit, working directory clean
Теперь можно использовать команду git push, чтобы выгрузить изменения в текущую ветку форка репозитория:
git push —set-upstream origin new-branch
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/your-username /respository .git
a1f29a6..79c0e80 new-branch -> new-branch
Branch new-branch set up to track remote branch new-branch from origin.
Теперь можно открыть форк репозитория на странице GitHub, переключиться на ветку, в которую вы внесли изменения, и просмотреть её.
На данном этапе вы уже можете сделать pull-запрос к оригинальному репозиторию. Но сначала рекомендуется обновить локальный репозиторий.
Обновление локального репозитория
Работая над открытым проектом вместе с другими разработчиками, важно постоянно следить за обновлениями и своевременно обновлять свой локальный репозиторий. В противном случае при создании pull-запроса может возникнуть конфликт.
Настройте удалённый репозиторий и синхронизируйте его с оригинальным репозиторием.
Настройка удалённого репозитория
Удалённый репозиторий – это размещённая в интернете версия проекта, к которой у вас есть доступ. Каждый удаленный репозиторий должен предоставлять вам право на чтение (или чтение и запись).
Чтобы синхронизировать изменения, внесенные в форк, с оригинальным репозиторием, вам нужно настроить удалённый репозиторий, который будет ссылаться на оригинальный репозиторий.
Сначала проверьте, какие удалённые серверы у вас настроены. Команда git remote с флагом –v отобразит URL-адреса, которые Git хранит вместе с соответствующими краткими именами удалённых серверов. Сейчас у вас есть только один репозиторий, origin.
Поскольку вы клонировали репозиторий, вывод будет примерно таким:
origin https://github.com/your-username/forked-repository.git (fetch)
origin https://github.com/your-username/forked-repository.git (push)
Если же ранее вы создали более одного удалённого репозитория, команда git remote –v выведет на экран полный список этих репозиториев.
Теперь нужно создать репозиторий upstream, который указывает на оригинальный репозиторий.
git remote add upstream https://github.com/original-owner-username/original-repository.git
В данном примере upstream – это короткое имя удаленного хранилища, так как с точки зрения Git «upstream» ссылается на репозиторий, из которого вы клонировали свой репозиторий. Чтобы добавить удалённый репозторий со ссылкой на репозиторий соавтора, можно указать имя соавтора или его ник.
Чтобы убедиться, что удалённый репозиторий upstream был успешно добавлен, в каталоге репозитория запустите команду:
git remote -v
origin https://github.com/your-username/forked-repository.git (fetch)
origin https://github.com/your-username/forked-repository.git (push)
upstream https://github.com/original-owner-username/original-repository.git (fetch)
upstream https://github.com/original-owner-username/original-repository.git (push)
Теперь вы можете синхронизировать форк с исходным репозиторием.
Синхронизация форка
В терминале перейдите в каталог локального репозитория и используйте команду git fetch, чтобы извлечь все ветки и их коммиты из оригинального репозитория.
git fetch upstream
Вывод команды зависит от того, сколько изменений появилось в исходном репозитории. В конце вывода содержатся примерно такие строки (они варьируются в зависимости от того, сколько веток входит в проект):
From https://github.com/original-owner-username/original-repository
* [new branch] master -> upstream/master
Теперь коммиты ветки master будут храниться в локальной ветке upstream/master.
Перейдите на локальную ветку master:
git checkout master
Switched to branch ‘master’
Теперь можно объединить все изменения, которые были сделаны в ветке master исходного репозитория, с локальной веткой.
git merge upstream/master
Вывод начинается с Updating, если в ветке появились новые данные. Если никаких изменений не произошло, команда вернёт Already up-to-date.
Ветка master вашего форка теперь синхронизирована с репозиторием upstream.
В зависимости от вашего рабочего процесса и количества времени, которое вы тратите на внесение изменений, вы можете синхронизировать ваш форк с кодом исходного репозитория столько раз, сколько вам нужно. Но вы обязательно должны синхронизировать форк, прежде чем сделать pull-запрос, чтобы ваш код не конфликтовал с остальным кодом проекта.
Создание pull-запроса
Теперь вы можете сделать pull-запрос к исходному репозиторию.
Перейдите в форк репозитория в браузере и нажмите кнопку New pull request слева.
На следующем экране вы можете отредактировать ветку и выбрать репозиторий в выпадающем меню.
После этого на экране появится форма, в которой вы можете добавить заголовок, оставить комментарий и т.п.
GitHub сообщит вам, если вы можете объединить две ветки. Добавьте заголовок, комментарий и нажмите Create pull request.
Пользователи, поддерживающие исходный репозиторий, рассмотрят ваш запрос. Возможно, они предложат вам внести в него некоторые изменения.
Заключение
Теперь вы умеете отправлять pull-запросы, работая над открытыми проектами.
Разработка проекта с открытым исходным кодом может стать полезным опытом.