Как перенести 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)
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду 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 :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Эта ситуация подходит, когда над проектом работают несколько человек .
Или же с проектом занимается один человек, но делает это дома и на работе. Рассмотрим такой случай. Для удобства пути к рабочему каталогу на обоих компьютерах совпадают .
Итак, есть каталог RU на домашнем ПК (с ним мы имели дело в прошлой статье, когда учились работать с системой контроля версий GIT и сервисом GITHub) и каталог RU на рабочем ноутбуке.
Репозиторий, созданный на домашнем компьютере хранится на сервере. Нужно его перенести с сервиса GITHub на рабочий ноутбук. Сделать это можно двумя способами.
1-ый способ переноса репозитория на другой компьютер
Находясь на сайте GITHub можно скачать ZIP-архив, разархивировать его и скопировать в нужный каталог на другом компьютере.
2-ой способ переноса репозитория - Команда git clone
Второй способ переноса репозитория на другой компьютер более правильный: предлагается работать через терминал . Что для этого нужно?
Скопировать путь к репозиторию на сервисе GITHub.
Зайти в рабочий каталог на другом ПК (ноутбуке. В нашем случае это снова папка RU , но путь может быть любым). И выполнить команду git clone, которая имеет следующий синтаксис.
Итак, в папку book на другом компьютере (ноутбуке) был клонирован репозиторий с сервиса GitHub.
Изменения в репозитории на 2-ом компьютере
Поработаем теперь с копией репозитория на другом (рабочем) компьютере. Внесем изменения в файл index.html : добавим заголовок h2.
Даже в редакторе VScode напротив файла index.html мы видим букву M . Это говорит о том, что файл index.html модифицирован/изменен. Убедимся в этом при помощи команды git status.
Здесь следует понимать, что если мы клонируем репозиторий, то он автоматически связан с удаленным . Поэтому достаточно ввести команду git push без ключа u , имени origin и ветки main , так как эта связь уже есть.
Теперь если перейти на удаленный репозиторий, то мы увидим новый коммит, созданный на другом компьютере .
Вроде бы ничего нового. Все это было проделано в предыдущей статье.
Но не будем забывать , что сейчас мы работаем на другом/рабочем компьютере (ноутбуке). И допустим, что продолжить работу мы сможем только дома. А на домашнем компьютере нет тех изменений, которые были сделаны на работе.
Получение изменений из удалённого репозитория - Команда git pull
Чтобы получить изменения из удалённого репозитория используется команда git pull.
И, действительно, мы видим, что синхронизация прошла успешно и в файле index.html на домашнем компьютере появился заголовок h2 .
Итак, работать с одним репозиторием и с сервисом GitHub с разных компьютеров не сложно. Здесь важно знать основные команды и порядок их выполнения. Именно так работают разные разработчики над одним проектом.
git pull - это обязательная команда, с которой следует начинать работать, если в проекте задействованы несколько человек.
Ошибка - ! [rejected] error: failed to push some refs - Слияние репозиториев
В удаленный репозиторий могут быть внесены изменения не только с локальных машин. На сервисе GitHub есть возможность редактировать, создавать и загружать новые файлы .
Допустим Вы забыли про команду git pull. При этом на удаленном репозитории произошли изменения, о которых Вы не знаете .
То есть мы работаем как обычно: вносим изменения в локальный проект, затем файл с изменениями добавляется в индекс, создается коммит. Но при попытке использовать команду git push возникает ошибка :
Обновления репозитория были отклонены. Сначала нужно интегрировать удаленные изменения . То есть использовать команду git pull.
C одной стороны на удаленном репозитории был создан файл README.md , который появился и в локальном проекте. Но на локальном репозитории тоже произошли изменения: добавлен новый параграф - тег p в файле index.html .
Теперь при использовании команды git push произойдет слияние двух репозиториев: локального и удаленного. На удаленном репозитории появились три новых коммита:
1-ый коммит - создание файла README.md на удаленном репозитории;
2-ой коммит - когда мы не знали об изменениях и внесли поправки в локальный репозиторий;
3-ий коммит - слияние двух репозиториев Merge branch 'main'. .
Но подобных ситуаций и ошибок не будет возникать, если следовать этому правилу.
Зачем нужен файл .gitignore?
Игнорирование файлов при работе с GIT или файл .gitignore.
В реальных проектах не обязательно push-ить все файлы на удаленный репозиторий. Часть файлов являются служебными и на GitHub они не нужны.
Кроме этого некоторые из них могут "весить" сотни МегаБайт и более. При этом отправка файлов на GitHub будет занимать много времени, либо терминал будет попросту зависать.
Для этого существует файл .gitignore - в нем указаны каталоги/файлы, которые не нужно выкладывать на удаленный репозиторий . Ниже приведен пример файла .gitignore.
npm-debug.log*
yarn-debug.log*
yarn-error.log*
GitKraken - графический клиент GIT
Просматривать репозиторий на GitHub не очень удобно.
В редакторе VScode есть плагин GitLens, который расширяет возможности GIT, встроенного в Visual Studio Code. И плагин Git History, который помогает просматривать истории изменений. Но и они не самое лучшее решение.
Существует специальный графический кросс-платформенный клиент для работы с репозиториями и сервисами GIT. Это GitKraken.
GitKraken имеет удобный интерфейс и множество функций. При входе в GitKraken через аккаунт GitHub мы увидим все созданные ранее коммиты.
Есть некоторый репозиторий с ветками master и develop :
Есть также пустой репозиторий
Как полностью перенести репозиторий a в b ?
Под полностью подразумевается, что должны сохраниться все ветки и все коммиты.
Updated: поправил с учётом комментариев
если на целевом сервере есть возможность выполнять команды оболочки от имени пользователя, которому принадлежит каталог с хранилищем (в вопросе для иллюстрации указан пользователь git), то можно обойтись без копирования хранилища с исходного сервера на локальный компьютер, а затем на целевой сервер.
сделайте текущим каталог с целевым хранилищем:
от имени пользователя, которому принадлежит этот каталог, подключите исходное хранилище под каким-нибудь именем, например, copy :
всё. при желании можно удалить ссылку на исходное-хранилище:
если у пользователя, которому принадлежит каталог с хранилищем, не разрешён запуск интерактивной оболочки, но у вас есть возможность выполнять команды от имени пользователя root, перечисленное выше можно сделать и от имени root-а, но по завершении, не меняя текущего каталога, надо установить всем файлам/каталогам такого же владельца и группу, как и у текущего каталога, с помощью, например, такой команды (естественно, от того же имени):
а если и исходный и целевой сервер — это одна и та же машина, то вместо всего вышеперечисленного можно просто скопировать файлы:
Клонирование в Git — это процесс создания идентичной копии удаленного репозитория Git на локальную машину.
Когда мы клонируем репозиторий, все файлы загружаются на локальную машину, но удаленный репозиторий git остается неизменным. Внесение изменений и фиксация их в локальном репозитории (клонированном репозитории) никак не повлияет на удаленный репозиторий, который вы клонировали. Эти изменения, внесенные на локальном компьютере, могут быть синхронизированы с удаленным хранилищем в любое время, когда пользователь захочет.
Как работает клонирование в Git?
Многие люди хотят создать общий репозиторий, чтобы позволить команде разработчиков публиковать свой код на GitHub / GitLab / BitBucket и т. д. Репозиторий, загружаемый в сеть для совместной работы, называется вышестоящим репозиторием или центральным репозиторием.
Центральный репозиторий указывает, что все изменения от всех участников помещаются только в этот репозиторий. Таким образом, это самый обновленный экземпляр репозитория самого себя. Иногда это часто называют исходным хранилищем. Изображение, приведенное ниже, довольно ясно говорит о концепции клонирования.
Что касается приведенного выше изображения, то процесс клонирования работает на следующих этапах:
Клонирование репозитория: пользователь начинает работу с вышестоящего репозитория на GitHub. Процесс начинается с клонирования репозитория на локальную машину. Теперь у пользователя есть точная копия файлов проекта в их системе, чтобы внести изменения.
Внесите необходимые изменения: после клонирования участники вносят свой вклад в хранилище. Вклад в виде редактирования исходных файлов, приводящего либо к исправлению ошибки, либо к добавлению функциональности, либо, возможно, к оптимизации кода. Но суть в том, что все происходит в их локальной системе.
Проталкивание изменений: как только изменения будут сделаны, они могут быть перемещены в вышестоящий репозиторий.
Примечание: владелец репозитория может разрешить / запретить прямые изменения в Центральном репозитории, установить различные уведомления о любом изменении, перенесенном в центральное хранилище и многое другое.
Как использовать команду git Clone
Клонирование в Git может быть сделано на собственном репозитории или в любом другом репозитории.
Как клонировать репозиторий или использовать команду git Clone?
Клонирование репозитория из GitHub — это простой процесс. Но, прежде чем клонировать, пожалуйста, убедитесь, что у вас есть репозиторий на вашем аккаунте GitHub.
Каковы основные различия между раздвоением и клонированием?
Чтобы очистить свой разум от воздуха, если он у вас есть, давайте посмотрим, чем отличаются эти два термина:
Разветвление делается на аккаунт github, а клонирование осуществляется с использованием git. При форке репозитория вы создаете копию исходного репозитория (вышестоящего репозитория), но этот репозиторий остается в вашей учетной записи GitHub. В то же время, когда вы клонируете репозиторий, он копируется на вашу локальную машину с помощью Git.
В последнем уроке мы познакомились с командой Git fetch и Read more
В одной из последних статей мы узнали о команде Git Read more
Мы уже знаем, как вносить изменения в локальное хранилище и Read more
Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more
Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more
Все данные, доступные в локальном репозитории, могут быть загружены в Read more
Читайте также: