Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями.
Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети.
У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи.
Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них.
Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее.
В данном разделе мы рассмотрим некоторые из этих навыков.
|
Примечание |
Удалённый репозиторий может находиться на вашем локальном компьютере. Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. |
Просмотр удалённых репозиториев
Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote.
Она выведет названия доступных удалённых репозиториев.
Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:
$ git clone https://github.com/schacon/ticgit
Cloning into 'ticgit'...
remote: Reusing existing pack: 1857, done.
remote: Total 1857 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.
Resolving deltas: 100% (772/772), done.
Checking connectivity... done.
$ cd ticgit
$ git remote
originВы можете также указать ключ -v, чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)Если у вас больше одного удалённого репозитория, команда выведет их все.
Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
$ cd grit
$ git remote -v
bakkdoor https://github.com/bakkdoor/grit (fetch)
bakkdoor https://github.com/bakkdoor/grit (push)
cho45 https://github.com/cho45/grit (fetch)
cho45 https://github.com/cho45/grit (push)
defunkt https://github.com/defunkt/grit (fetch)
defunkt https://github.com/defunkt/grit (push)
koke git://github.com/koke/grit.git (fetch)
koke git://github.com/koke/grit.git (push)
origin git@github.com:mojombo/grit.git (fetch)
origin git@github.com:mojombo/grit.git (push)Это означает, что мы можем легко получить изменения от любого из этих пользователей.
Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее.
Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add <shortname> <url>:
$ git remote
origin
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)Теперь вместо указания полного пути вы можете использовать pb.
Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb:
$ git fetch pb
remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
From https://github.com/paulboone/ticgit
* [new branch] master -> pb/master
* [new branch] ticgit -> pb/ticgitВетка master из репозитория Пола сейчас доступна вам под именем pb/master.
Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола.
Более подробно работа с ветками рассмотрена в главе Ветвление в Git.
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
$ git fetch [remote-name]Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет.
После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin».
Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch).
Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.
Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей.
Этот способ может для вас оказаться более простым или более удобным.
К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий.
Название веток может быть другим и зависит от ветки по умолчанию на сервере.
Выполнение git pull, как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
|
Примечание |
Начиная с версии 2.27, команда Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): Если хотите использовать перебазирование при получении изменений: |
Отправка изменений в удалённый репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий.
Команда для этого действия простая: git push <remote-name> <branch-name>.
Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push.
Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён.
Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push.
Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.
Просмотр удалённого репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show <remote>.
Выполнив эту команду с некоторым именем, например, origin, вы получите следующий результат:
$ git remote show origin
* remote origin
Fetch URL: https://github.com/schacon/ticgit
Push URL: https://github.com/schacon/ticgit
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках.
Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull, ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных.
Она также выдаёт список всех полученных ею ссылок.
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным.
Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show:
$ git remote show origin
* remote origin
URL: https://github.com/my-org/complex-project
Fetch URL: https://github.com/my-org/complex-project
Push URL: https://github.com/my-org/complex-project
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
markdown-strip tracked
issue-43 new (next fetch will store in remotes/origin)
issue-45 new (next fetch will store in remotes/origin)
refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
dev-branch merges with remote dev-branch
master merges with remote master
Local refs configured for 'git push':
dev-branch pushes to dev-branch (up to date)
markdown-strip pushes to markdown-strip (up to date)
master pushes to master (up to date)Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push.
Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull.
Удаление и переименование удалённых репозиториев
Для переименования удалённого репозитория можно выполнить git remote rename.
Например, если вы хотите переименовать pb в paul, вы можете это сделать при помощи git remote rename:
$ git remote rename pb paul
$ git remote
origin
paulСтоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории.
То, к чему вы обращались как pb/master, теперь стало paul/master.
Если по какой-то причине вы хотите удалить удалённый репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm:
$ git remote remove paul
$ git remote
originПри удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Узнайте, как работать с локальными репозиториями на компьютере и удаленными репозиториями, размещенными в GitHub.
Добавление удаленного репозитория
Чтобы добавить новый удаленный репозиторий, выполните команду git remote add в терминале в каталоге, в котором хранится репозиторий.
Команда git remote add принимает два аргумента:
- имя удаленного репозитория, например,
origin; - URL-адрес удаленного репозитория, например,
https://github.com/OWNER/REPOSITORY.git.
Пример:
$ git remote add origin https://github.com/OWNER/REPOSITORY.git
# Set a new remote
$ git remote -v
# Verify new remote
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)Дополнительные сведения о том, какой URL-адрес следует использовать, см. в разделе Сведения об удаленных репозиториях.
Устранение неполадок: удаленный источник уже существует
Эта ошибка означает, что вы попытались добавить удаленный репозиторий с именем, которое уже существует в локальном репозитории.
$ git remote add origin https://github.com/octocat/Spoon-Knife.git
> fatal: remote origin already exists.Возможные пути устранения проблемы указаны ниже.
- Используйте другое имя для нового удаленного репозитория.
- Переименуйте существующий удаленный репозиторий перед добавлением нового удаленного репозитория. Дополнительные сведения см. в разделе Переименование удаленного репозитория ниже.
- Удалите существующий удаленный репозиторий перед добавлением нового удаленного репозитория. Дополнительные сведения см. в разделе Удаление удаленного репозитория ниже.
Изменение URL-адреса удаленного репозитория
Команда git remote set-url изменяет существующий URL-адрес удаленного репозитория.
Команда git remote set-url принимает два аргумента:
-
Имя существующего удаленного репозитория. Например, к распространенным вариантам относятся
originиupstream. -
Новый URL-адрес удаленного репозитория. Пример:
- Если вы переходите на протокол HTTPS, URL-адрес может выглядеть так:
https://github.com/OWNER/REPOSITORY.git- Если вы переходите на SSH, URL-адрес может выглядеть так:
git@github.com:OWNER/REPOSITORY.git
Переключение удаленных URL-адресов с SSH на HTTPS
-
Откройте ТерминалТерминалGIT Bash.
-
Измените текущий рабочий каталог на локальный проект.
-
Выведите список существующих удаленных объектов, чтобы получить имя удаленного репозитория, которое требуется изменить.
$ git remote -v > origin git@github.com:OWNER/REPOSITORY.git (fetch) > origin git@github.com:OWNER/REPOSITORY.git (push) -
Переключите URL-адрес удаленного репозитория с SSH на HTTPS, выполнив команду
git remote set-url.git remote set-url origin https://github.com/OWNER/REPOSITORY.git -
Убедитесь, что URL-адрес удаленного репозитория изменен.
$ git remote -v # Verify new remote URL > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push)
При следующем выполнении команд git fetch, git pull и git push для удаленного репозитория вам будет предложено указать имя пользователя и пароль GitHub. Когда Git предложит ввести пароль, введите personal access token. Кроме того, можно использовать вспомогательное средство учетных данных, например диспетчер учетных данных Git. Проверка подлинности на основе пароля для Git была удалена в пользу более безопасных методов проверки подлинности. Дополнительные сведения см. в разделе Управление личными маркерами доступа.
Вы можете использовать вспомогатель учетных данных , чтобы Git запоминал ваше имя пользователя GitHub и personal access token при каждом разговоре с GitHub.
Переключение удаленных URL-адресов с HTTPS на SSH
-
Откройте ТерминалТерминалGIT Bash.
-
Измените текущий рабочий каталог на локальный проект.
-
Выведите список существующих удаленных объектов, чтобы получить имя удаленного репозитория, которое требуется изменить.
$ git remote -v > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push) -
Переключите URL-адрес удаленного репозитория с HTTPS на SSH, выполнив команду
git remote set-url.git remote set-url origin git@github.com:OWNER/REPOSITORY.git -
Убедитесь, что URL-адрес удаленного репозитория изменен.
$ git remote -v # Verify new remote URL > origin git@github.com: OWNER/REPOSITORY.git (fetch) > origin git@github.com: OWNER/REPOSITORY.git (push)
Устранение неполадок: удаленный репозиторий «[имя]» отсутствует
Эта ошибка означает, что удаленного репозитория, который вы пытались изменить, не существует:
$ git remote set-url sofake https://github.com/octocat/Spoon-Knife
> fatal: No such remote 'sofake'Убедитесь, что вы правильно указали имя удаленного репозитория.
Переименование удаленного репозитория
Используйте команду git remote rename для переименования существующего удаленного репозитория.
Команда git remote rename принимает два аргумента:
- имя существующего удаленного репозитория, например,
origin; - новое имя удаленного репозитория, например,
destination.
Пример переименования удаленного репозитория
В этих примерах предполагается, что клонирование выполняется с помощью HTTPS (это рекомендуемый вариант).
$ git remote -v
# View existing remotes
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)
$ git remote rename origin destination
# Change remote name from 'origin' to 'destination'
$ git remote -v
# Verify remote's new name
> destination https://github.com/OWNER/REPOSITORY.git (fetch)
> destination https://github.com/OWNER/REPOSITORY.git (push)Устранение неполадок: не удалось переименовать раздел конфигурации «remote.[старое имя]» в «remote.[новое имя]»
Эта ошибка означает, что удаленного репозитория с указанным старым именем не существует.
Вы можете проверить существующие удаленные репозитории, выполнив команду git remote -v:
$ git remote -v
# View existing remotes
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)Устранение неполадок: удаленный репозиторий [новое имя] уже существует
Эта ошибка означает, что удаленный репозиторий с именем, которое вы хотите использовать, уже существует. Чтобы решить эту проблему, используйте другое имя удаленного репозитория или переименуйте имеющийся удаленный репозиторий.
Удаление удаленного репозитория
Чтобы удалить удаленный URL-адрес из репозитория, используйте команду git remote rm.
Команда git remote rm принимает один аргумент:
- имя удаленного репозитория, например,
destination.
При удалении удаленного URL-адреса из репозитория выполняется только отмена привязки для локальных и удаленных репозиториев. Сам удаленный репозиторий не удаляется.
Пример удаления удаленного репозитория
В этих примерах предполагается, что клонирование выполняется с помощью HTTPS (это рекомендуемый вариант).
$ git remote -v
# View current remotes
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)
> destination https://github.com/FORKER/REPOSITORY.git (fetch)
> destination https://github.com/FORKER/REPOSITORY.git (push)
$ git remote rm destination
# Remove remote
$ git remote -v
# Verify it's gone
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)Примечание. Команда git remote rm не удаляет удаленный репозиторий с сервера. Она просто удаляет удаленный репозиторий и его ссылки из локального репозитория.
Устранение неполадок. Не удалось удалить раздел конфигурации «remote.[имя]»
Эта ошибка означает, что удаленного репозитория, который вы пытались удалить, не существует:
$ git remote rm sofake
> error: Could not remove config section 'remote.sofake'Убедитесь, что вы правильно указали имя удаленного репозитория.
Дополнительные материалы
- «Работа с удаленными репозиториями» из книги Pro Git
Из этой статьи вы узнаете
-
Зачем нужны системы контроля версий
-
Откуда взялся Git
-
Как создать свой репозиторий на GitHub и внести в него изменения
-
Что такое fork, branch и другие интересные слова из мира Git
-
Как создать свой Pull Request
Вступление
Бывает, что начинающие разработчики проблематично осваивают Git и не с первого захода понимают логику работы сервиса. Но стоит создать пару репозиториев или, ещё лучше, погрузиться в реальную историю по установке стартапа на рельсы DevOps, как работа с ветками станет дружелюбной, а PR и MR больше не вызовут путаницы. Ошибки в любом случае появятся, но вы будете к ним готовы!
Начало
Когда вы пишете первую программу, всё кажется таким лаконичным, простым и понятным. Но по мере развития ваша программа обрастает новой функциональностью, становится сложнее и больше. Потом и вовсе появляются первые баги. И было бы здорово помнить или иметь возможность смотреть историю изменений, что добавили или убрали в коде, по какой причине мог появиться баг.
Первое и самое просто решение — «А давайте перед каждым изменением сохранять копию программы (просто копировать папку с кодом)?»
На самом деле это будет работать, но до поры до времени. Проект продолжит расти и станет полезным не только вам, но и вашим друзьям, которые захотят добавить в код что-то своё. В рядах программистов прибывает, и надо как-то договариваться, кто какой кусочек кода трогает, а потом ещё синхронизировать изменения, чтобы все фичи добрались до прода.
Настал звёздный час для систем контроля версий, которые запоминают, какое изменение и в каком файле было сделано, а также могут показать историю этих изменений.
Про Git
Существует несколько систем контроля версий: Git, Subversion, Team Foundation Server, Mercurial. Сегодня познакомимся с Git — самой популярной из них, по скромному признанию более 90% разработчиков.
Git появился 7 апреля 2005 года и был создан для управления разработкой ядра Linux. Кстати, создал его тот самый Линус Торвальдс, а сегодня его развитием и поддержкой занимается Дзюн Хамано.
Git — это распределённая система управления версиями: есть один сервер, через который разработчики обмениваются кодом. Разработчик копирует (клонирует) проект к себе на локальную машину, делает изменения и сохраняет их на удалённый сервер. При необходимости другие разработчики могут скопировать эти изменения к себе.
История и копия проекта хранятся локально и чаще всего не нужна дополнительная информация с других клиентов. Вы можете работать с репозиторием и при отсутствии интернета (например, в самолёте), а когда он появится, просто загрузить изменения в удалённый репозиторий на выделенном сервере.
Если у разработчика сломается компьютер, то проект не потеряется, а будет лежать на выделенном сервере. Такой выделенный сервер можно поднять и настроить самостоятельно либо использовать готовые решения.
GitHub — крупнейший веб-сервис, который позволяет заниматься совместной разработкой с использованием Git и сохранять изменения на своих серверах. На самом деле функциональность GitHub намного больше, но сейчас нас интересует только совместная разработка и история изменений. Ещё есть Gitlab, Bitbucket и другие, но мы будем использовать GitHub как самый популярный в настоящее время.
Предварительная настройка
Займёмся предполётной подготовкой.
Для начала зарегистрируйтесь на GitHub: задайте логин, почту и придумайте пароль. После «Создать аккаунт» не забудьте проверить почту и подтвердить её (опрос от Github после подтверждения почты можно пропустить).
В GitHub есть разграничение прав на работу с репозиториями. Можно задавать различные политики: сделать репозиторий публичным и приватным, ограничить права кругу пользователей или кому-то одному, например, разрешить просматривать репозиторий, но не изменять в нём данные.
Для того чтобы сервис определил, кто вы и имеете ли право работать с тем или иным репозиторием, нужно представиться — пройти процесс аутентификации.
GitHub поддерживает безопасность за счёт двух сетевых протоколов, HTTPS и SSH, и вся работа с сервисом происходит через один из них.
Работать с GitHub будем через терминал по SSH. Для этого один раз сгенерируем специальные ключи и добавим один из них в наш аккаунт на GitHub.
Можно работать и через HTTPS, но нужно будет каждый раз вводить пароль и специальный token.
Пара слов про SSH и как он работает. SSH — это сетевой протокол для зашифрованного соединения между клиентом и сервером, через который можно безопасно передавать данные.
При подключении используется пара ключей — открытый (публичный, public) и закрытый (приватный, private). Пользователь создаёт пару ключей при помощи специальной команды и сохраняет закрытый ключ у себя, а открытый кладёт на сервер (в нашем случае на GitHub). А работает это всё благодаря асимметричному шифрованию.
Алгоритм следующий: отправитель (GitHub) шифрует сообщение публичным ключом и передаёт сообщение клиенту (нам), а мы его расшифровываем при помощи приватного ключа, который предусмотрительно сохранили у себя. То, что зашифровано публичным ключом, расшифровать сможет только приватный ключ.
Давайте создадим пару ключей и добавим открытый ключ на GitHub.
Чтобы создать пару ключей, в терминале нужно ввести команду, задать путь для хранения ключей и указать пароль к ключу (необязательно).
Далее будем опираться на то, что путь для ключей дефолтный и пароль на ключи не установлен.
Пароль для ключей нужен как дополнительная мера безопасности, если вдруг ваш приватный ключ попадёт не в те руки.
$ ssh-keygen
Generating public/private rsa key pair.
# путь до ключей, в скобках путь по умолчанию
Enter file in which to save the key (/Users/ifireice/.ssh/id_rsa):
# пароль для ключей, при задании пароля в консоли не отображается ничего, даже звёздочки
# если нажать Enter, ничего не вводя, пароль будет пустым
Enter passphrase (empty for no passphrase):
# повторите пароль
Enter same passphrase again:
# после появится сообщение такого вида
Your identification has been saved in /Users/ifireice/.ssh/id_rsa
Your public key has been saved in /Users/ifireice/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Zu+HkZPC4ZP0veRmVjuKgylVvljHBNO8mHs+ieFFPvs ifireice@ifireice-osx
The key's randomart image is:
+---[RSA 3072]----+
| o |
| o o |
| = . |
| o + + |
| +S* X |
| oB.@ X . |
| . O.# * . |
| . +.*.% o |
| . o*.+E. |
+----[SHA256]-----+Бинго, ключи сгенерированы: в заданной директории появятся два файла, id_rsa и id_rsa.pub.
Теперь надо добавить публичный ключ в аккаунт на GitHub:
# выведите содержимое публичного ключа в консоль
$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDJfHIi73sKd6cqm3RwKuY1zl46aAaE6X9Gp
/6zJiY3BiJj95oJjPdpfpPhVFWLIbmT8zFAtOLbX9N4C3b0enHUzgMacP/Kl4AbrAkhLqaua9iD
VNxxiTVxADG1M5525oc/eAvx7y0pXIb9ouWdYJSKa8/TUYFhWlCzV2quY9SA0FaMs7eY41+KWYpG.....
tA0oGxv+7WmXQmQzleLIRG13KQ+VAbL2vabdPcRoGuZavh0smOr/GtVSnLdspZ5RgONMSPWlF2I1YHMR
Q7CIKPs= ifireice@ifireice-osx
$Скопируйте ключ от символов ssh-rsa и до конца файла и вставьте его в ваш аккаунт на GitHub.
Ну что, с настройкой GitHub пока закончили, осталось установить Git на компьютер. Сделать это можно по официальной инструкции (выберите пункт для вашей ОС).
Терминология
Самое время пополнить ваш Git-словарик, прежде чем создадим первый Pull Request.
Репозиторий (repository) — директория проекта, который отслеживается Git. В директории хранится проект, история изменений и мета-информация проекта (в скрытой директории .git).
Индекс — хранилка, где лежат имена файлов и их изменения, которые должны быть в следующем коммите. По факту индекс — просто файл. В индекс файлы сами не попадают, их нужно явно добавлять при помощи git add.
Коммит (commit) — это фиксация изменений в истории проекта (изменения, которые внесены в индекс). Коммит хранит изменённые файлы, имя автора коммита и время, в которое был сделан коммит. Кроме того, каждый коммит имеет уникальный идентификатор, который позволяет в любое время к нему откатиться. Можете считать коммит этакой точкой сохранения.
Ветка (branch) — последовательность коммитов. По сути — ссылка на последний коммит в этой ветке. Ветки не зависят друг от друга — можно вносить изменения в одну, и они не повлияют на другую (если вы явно этого не попросите). Работать вы начинаете в одной ветке — main, увидите чуть позже.
Форк (Fork) — собственное ответвление (fork) какого-то проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем пространстве имён, и вы сможете легко делать изменения путём отправки (push) изменений.
Пул-реквест — pull request PR (пиар, он же merge request MR(мр)) — предложение изменения кода в чужом репозитории. Допустим, вы забрали к себе чужой репозиторий, поработали с ним и теперь хотите, чтобы ваши изменения попали в оригинальный репозиторий — тогда вы создаёте создаёте PR с просьбой добавить ваши изменения в репозиторий.
Начало работы
Начнём с простого — создадим свой репозиторий и сделаем наш первый коммит.
Зададим параметры:
-
(1) Repository name: имя репозитория.
-
(2) Description: описание репозитория.
-
(3) Тип репозитория: Public (публичный) или Private (приватный). Сейчас выберем публичный — кто угодно может видеть содержимое репозитория.
-
(4) Ставим галку на «Создать README файл». В этом файле в формате MarkDown описывают проект или прочую документацию. Именно содержимое этого файла можно увидеть, когда заходим на главную страницу репозитория. Примеры 1, 2, 3.
-
(5) Если известно, на каком языке будет проект, можем добавить шаблон
.gitignoreдля этого языка. Сейчас у нас нет какого-то языка, поэтому не будем создавать.gitignore. -
(6) Выбираем тип лицензии для нашего кода. В лицензии оговариваются права на проект. Стоит обратить внимание на BSD 3 или MIT, так как они предоставляют хороший баланс прав и ответственности.
(7) По умолчанию имя основной ветки в GitHub носит имя main, но до недавнего времени было master.
И нажимаем кнопку «Create repository». Успех, у нас есть первый репозиторий!
А что будет, если не добавим README и .gitignore?
На самом деле ничего страшного не произойдёт, но придётся выполнить ещё ряд шагов, чтобы проинициализировать git-репозиторий, прежде чем начать с ним работать.
Итак, мы создали репозиторий на удалённом сервере, теперь пора «забрать» его к себе на локальную машину и внести какие-то изменения.
Чтобы забрать репозиторий, его надо склонировать к себе при помощи команды git clone и пути до репозитория.
Для начала получим путь до репозитория.
Теперь идём в консоль, переходим в директорию, где хотим хранить проекты, и выполним (git@github.com:ifireiceya/MyFirstRepo.git — путь, который мы скопировали ранее):
$ git clone git@github.com:ifireiceya/MyFirstRepo.git
Cloning into 'MyFirstRepo'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (4/4), done.Переходим в новый каталог, где теперь лежит копия нашего проекта с GitHub:
$ cd MyFirstRepoМожем посмотреть, что уже есть в этой директории:
$ ls -a
.git LICENSE README.mdВидим два знакомых файла,LICENSE и README.md, а также одну скрытую директорию .git.
В .git хранится метаинформация и вся история для проекта. На каждый проект есть только одна директория .git, и лежит она в корне проекта.
$ ls .git
HEAD # указатель на вашу активную ветку
config # персональные настройки для проекта
description # описание проекта
hooks # pre/post action hooks
index # индексный файл
logs # история веток проекта (где они располагались)
objects # ваши объекты (коммиты, теги и тд)
packed-refs refs # указатели на ваши ветки разработкиДавайте немного настроим Git под себя. Делать это нужно только один раз, потом настройки сохранятся, но при необходимости их можно изменить.
При установке Git была добавлена утилита git config, которая позволяет просматривать и изменять большинство параметров работы Git’а. Если речь о данных пользователя или способе работы репозитория — git config будет самым удобным способом настройки.
Настроим имя пользователя и адрес электронной почты. Эта информация важна, потому что включается в каждый коммит.
Поэтому в терминале переходим в Git-репозиторий, для которого задаём настройки, и выполняем:
$ git config user.name "Дарья Меленцова"
$ git config user.email ifireice@example.com
# Если добавить опцию --global, то эти настройки запишутся в настройки пользователя и будут действовать для всех проектов.
# Мы выполняем эту команду без параметра --global, чтобы настройки касались только вашего проекта.Чтобы настраивать ещё больше параметров с помощью
git config, прочитайте эту документацию.
Вносим изменения
Теперь нужно внести изменения в проект. Но перед этим посмотрим две полезных команды:
-
git status— показывает текущее состояние файлов в репозитории (какие файлы изменились, удалились, добавились); -
git log— показывает историю изменений (это про зафиксированные изменения, то есть коммиты).
Выполним эти команды и посмотрим, что они выведут для нашего репозитория.
Вбиваем git status:
$ git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree cleanИ видим, что у нас нет изменений. Говорят, «нет коммитов в репозитории». Конечно, мы успели только клонировать репозиторий и ещё ничего не делали.
Идём дальше и пробуем git log, который покажет, что в проекте был только один Initial commit — когда мы создавали репозиторий с README.md:
$ git log
commit 9ae1cbcc77f3b64d604612d4a599bdbb8b1cf204 (HEAD -> main, origin/main, origin/HEAD)
Author: ifireiceya <117034707+ifireiceya@users.noreply.github.com>
Date: Mon Oct 31 00:01:05 2022 +0300
Initial commit
(END)Убедились, что у нас нет неучтённых изменений. Пора бы уже что-то сделать!
Открываем любимый текстовый редактор и создаём новый файл с именем hw.py.
Это будет небольшая программа на Python, которая при запуске печатает «Hello World!» (внезапно):
$ vi hw.py
print("Hello World!")Отлично, код написан и даже хранится локально в нашем репозитории (мы же в директории проекта всё делали).
Теперь наша задача — сохранить изменения в «оригинальный» (удалённый) репозиторий. Для этого нужно:
-
Познакомить Git с новым файлом, то есть добавить файл в индекс —
git add. -
Зафиксировать (закоммитить) изменения —
git commit. -
Синхронизировать изменения с сервером —
git push. -
Посмотреть в репозиторий и убедиться, что всё сработало.
Делаем!
Появился файл hw.py, но он красный. Паника! Всё сломалось?!
Нет, всё идёт по плану, но прежде чем продолжить, стоит обсудить состояние файлов с точки зрения Git’а.
По мнению Git’а, файл может пребывать в одном из четырёх состояний:
-
Неотслеживаемый (untracked).
-
Изменённый (modified) — файл, в котором есть изменения, но он ещё не добавлен в коммит (не зафиксирован).
-
Отслеживаемый (staged) — файл, который добавили в индекс.
-
Зафиксированный (committed) — файл уже сохранён в локальной базе, и в нём не было изменений с последнего коммита.
В связке с состоянием файлов используют три основных секции проекта:
-
Рабочая директория (working directory) — это директория, которая содержит в себе то, с чем вы работаете, или то, что вы извлекли из истории проекта в данный момент. Рабочая директория — это временное место, где вы можете модифицировать файлы, а затем выполнить коммит.
-
Область индексирования (staging area) — индекс-файл в каталоге Git, который содержит информацию о том, что попадёт в следующий коммит.
-
Каталог Git — место, где Git хранит метаданные и базу объектов вашего проекта. Помните ещё про
.git?
Что происходит на практике
Мы добавили новый файл hw.py и видим, что у него состояние untracked, то есть неважно, что мы делаем с файлом, Git проигнорирует любые изменения в нём.
Чтобы Git начал следить за изменениями в файле, его нужно добавить в индекс.
Для этого используем команду git add <имя файла>.
Кстати, вы заметили, что Git довольно дружелюбный и часто подсказывает команды, которые нужно выполнить?
$ git add hw.py
# если нужно добавить много файлов и не хочется описывать, можно использовать команду
# git add .
# но стоит точно понимать, что добавляем, иначе придётся потом удалять файлы из индекса
# кстати, для удаления используется команда git rm, но стоит почитать доку перед использованиемИ ещё не забывайте о файле .gitignore, где перечислены папки и файлы репозитория, которые Git не должен отслеживать и синхронизировать их состояние (не добавлять их в индекс). Обычно в него добавляют файлы логов, результаты сборки и другое. Поддерживает шаблоны. Кстати, .gitignore — тоже файл, который надо добавить в индекс.
-
Если файл попадает в правила
.gitignore, то он не появится вgit status. -
Если файл был добавлен в индекс, а потом добавлено правило для файла в
.gitignore— файл всё равно будет отслеживаться и его надо явно удалить из индекса.
Посмотрим, как изменилось состояние нашего файла:
Давайте зафиксируем изменения, так как наша задача сейчас решена: мы написали программу на Python и хотим сказать Git, что вот теперь мы закончили работать с файлом и надо запомнить текущее состояние.
Для этого нужно закоммитить файл с помощью команды git commit.
При создании обычно лаконично описывают коммит, используя ключ -m:
$ git commit -m "add python hello world"
[main 6d8a5c3] add python hello world
1 file changed, 1 insertion(+)
create mode 100644 hw.pyПара слов о том, как писать сообщения для коммитов:
-
максимум 50 символов;
-
осознанно и понятно, как будто пишете для человека, который должен понять, что происходит внутри коммита;
-
сообщение стоит начинать с заглавной буквы;
-
если меняли код, пишите исходный код в сообщении.
$ git log
$ git push
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 341 bytes | 341.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:ifireiceya/MyFirstRepo.git
9ae1cbc..6d8a5c3 main -> mainПредлагаем проверить, что наши изменения есть на GitHub. Идём в репозиторий и смотрим на него.
Задача немного посложнее
Всё здорово, но мы не всегда создаём репозитории, и часто нам нужно добавлять новые фичи или исправления в уже существующий репозиторий, да ещё и в чужой.
Например, есть у нас любимый опенсорсный проект, в который мы хотим принести добро и закрыть им какой-нибудь Issue.
В учебных целях используем репозиторий из этой статьи на GitHub. Там нужно исправить опечатку, которую нашли в статье. Например, вот эту очепятку.
Но будем делать это с позиции внешних пользователей в чужом репозитории.
Репозиторий хранится в ifireice/git, а изменения делает пользователь ifireiceya.
Пользователь ifireiceya не имеет доступа в ifireice/git, и ему придётся работать через Fork, то есть нужно сперва сделать копию этого репозитория к себе и вести разработку у себя, а потом отправить в основной репозиторий запрос на изменения — Pull Request.
Но обо всём по порядку. Сначала делаем Fork.
Откроется окно для создания нового форка (fork).
Изменится владелец репозитория (1), и опционально можно изменить описание проекта.
Вы можете делать любые изменения в собственной копии, и они никак не отразятся в оригинальном репозитории.
Теперь клонируем форк-репозиторий к себе на машинку и ведём разработку.
Только мы будем работать чуть-чуть по-другому, не как с нашим репозиторием.
В нашем репозитории мы работали в ветке main и все изменения сохраняли в ней.
А теперь у нас большой проект, и над ним одновременно могут трудиться несколько разработчиков. Чтобы разные изменения не смешивались в кучу и чтобы один разработчик не мешал другому, разработка ведётся в разных независимых версиях продукта — ветках (branch). Когда работа закончена, все изменения сливаются в одну главную ветку.
Клонируем репозиторий и создаём отдельную ветку, в которой будем устранять опечатку:
$ git clone git@github.com:ifireiceya/git.git
$ cd git
# создадим новую ветку и сразу же переключимся на неё, чтобы работать там
$ git checkout -b fix-misprint
Switched to a new branch 'fix-misprint'Чтобы посмотреть, какие ветки есть в проекте и какая сейчас активна, используется команда git branch:
$ git branch
* fix-misprint
main
# * помечена текущая активная веткаНа самом деле практика работать с ветками распространена не только при разработке в чужих репозиториях (collaborators), куда у вас нет доступа, но и в своих. Есть несколько стратегий выделения веток, но об этом не сейчас. Просто знайте, что есть ветки и с их помощью удобно вести разработку.
Можем посмотреть, что изменилось с последнего коммита, при помощи команды git diff (красным с “-” то, что было, зелёным с “+” — то, что стало):
$ git diff
$ git status
On branch fix-misprint
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -am "Поправили опечатку"
[fix-misprint 188caa7] Поправили опечатку
1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
fatal: The current branch fix-misprint has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin fix-misprintУпс, fatal. Читаем подсказку от Git и выполняем:
$ git push --set-upstream origin fix-misprint
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 402 bytes | 402.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'fix-misprint' on GitHub by visiting:
remote: https://github.com/ifireiceya/git/pull/new/fix-misprint
remote:
To github.com:ifireiceya/git.git
* [new branch] fix-misprint -> fix-misprint
Branch 'fix-misprint' set up to track remote branch 'fix-misprint' from 'origin'.Успех!
Почему произошёл fatal: простой git push предполагает, что ветка, которую отслеживает текущая локальная ветвь, уже существует на удалённом сервере. У нас ветка новая и была создана только локально, поэтому нам нужно её создать, указав --set-upstream.
Проверим, что ветка появилась на GitHub.
Форк сделали, ветку отвели, ошибку поправили, осталось отправить изменения в оригинальный репозиторий.
Для этого создаём Pull request.
И увидим такую картину.
(1) репозиторий, в который хотим добавить изменения. — ifireice/git
(2) ветка, в которую хотим добавить изменения — main
(3) репозиторий, из которого хотим добавить изменения — ifireiceya/git
(4) ветка, из которой хотим добавить изменения — main
На этом сейчас наша работа завершена. Ответственные за репозиторий посмотрят ваши изменения, примут их, или попросят что-то дописать, или отклонят изменения.
Будем считать, что у нас всё хорошо и наши изменения приняли без вопросов.
Как это выглядит на стороне ревьюверов:
На этом пока всё. Увидимся в следующих выпусках про Git и не только.
Что изучили
-
Поговорили про системы контроля версий
-
Настроили себе GitHub
-
Создали первый репозиторий и внесли в него изменения
-
Узнали про ветки, форки и остальное
-
Сделали первый ПР
Что НЕ изучили
-
Конфликты
-
Откат изменений (reset, revert)
-
Как забрать файл из другой ветки (Cherry-pick)
-
rebase
Что ещё почитать
-
Отличная книга Pro Git (есть на русском и английском)
-
Курс «DevOps для эксплуатации и разработки»
-
Trunk-Based Development — стратегия отведения веток
-
GitFlow — другая стратегия отведения веток
В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.
Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!
Основы
Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). Изначально Git был создан Линусом Торвальдсом при разработке ядра Linux. Однако инструмент так понравился разработчикам, что в последствии, он получил широкое распространение и его стали использовать в других проектах. С его помощью вы можете сравнивать, анализировать, редактировать, сливать изменения и возвращаться назад к последнему сохранению. Этот процесс называется контролем версий.
Для чего он нужен? Ну во-первых, чтобы отследить изменения, произошедшие с проектом, со временем. Проще говоря, мы можем посмотреть как менялись файлы программы, на всех этапах разработки и при необходимости вернуться назад и что-то отредактировать. Часто бывают ситуации, когда, во вполне себе работающий код, вам нужно внести определенные правки или улучшить какой-то функционал, по желанию заказчика. Однако после внедрения нововведений, вы с ужасом понимаете, что все сломалось. У вас начинается судорожно дергаться глаз, а в воздухе повисает немой вопрос: “Что делать?” Без системы контроля версий, вам надо было бы долго напряженно просматривать код, чтобы понять как было до того, как все перестало работать. С Гитом же, все что нужно сделать — это откатиться на коммит назад.
Во-вторых он чрезвычайно полезен при одновременной работе нескольких специалистов, над одним проектом. Без Гита случится коллапс, когда разработчики, скопировав весь код из главной папки и сделав с ним задуманное, попытаются одновременно вернуть весь код обратно.
Git является распределенным, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в директориях на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн, это сильно облегчает работу над одним проектом для нескольких людей. Для этого используются сайты вроде github и bitbucket.
Установка
Установить git на свою машину очень просто:
- Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
sudo apt-get install git
- Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
- OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:
brew install git
Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.
Настройка
Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:
git config --global user.name "My Name" git config --global user.email myEmail@example.com
Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Git хранит весь пакет конфигураций в файле .gitconfig, находящемся в вашем локальном каталоге. Чтобы сделать эти настройки глобальными, то есть применимыми ко всем проектам, необходимо добавить флаг –global. Если вы этого не сделаете, они будут распространяться только на текущий репозиторий.
Для того, чтобы посмотреть все настройки системы, используйте команду:
git config --list
Для удобства и легкости зрительного восприятия, некоторые группы команд в Гит можно выделить цветом, для этого нужно прописать в консоли:
git config --global color.ui true git config --global color.status auto git config --global color.branch auto
Если вы не до конца настроили систему для работы, в начале своего пути — не беда. Git всегда подскажет разработчику, если тот запутался, например:
- Команда git —help — выводит общую документацию по git
- Если введем git log —help — он предоставит нам документацию по какой-то определенной команде (в данном случае это — log)
- Если вы вдруг сделали опечатку — система подскажет вам нужную команду
- После выполнения любой команды — отчитается о том, что вы натворили
- Также Гит прогнозирует дальнейшие варианты развития событий и всегда направит разработчика, не знающего, куда двигаться дальше
Тут стоит отметить, что подсказывать система будет на английском, но не волнуйтесь, со временем вы изучите несложный алгоритм ее работы и будете разговаривать с ней на одном языке.
Создание нового репозитория
Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:
$ mkdir Desktop/git_exercise/ $ cd Desktop/git_exercise/ $ git init
Командная строка должна вернуть что-то вроде:
Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/
Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.
Определение состояния
status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:
$ git status On branch master Initial commit Untracked files: (use "git add ..." to include in what will be committed) hello.txt
Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.
Подготовка файлов
В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:
$ git add hello.txt
Если нам нужно добавить все, что находится в директории, мы можем использовать
$ git add -A
Проверим статус снова, на этот раз мы должны получить другой ответ:
$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached ..." to unstage) new file: hello.txt
Файл готов к коммиту. Сообщение о состоянии также говорит нам о том, какие изменения относительно файла были проведены в области подготовки — в данном случае это новый файл, но файлы могут быть модифицированы или удалены.
Фиксация изменений
Как сделать коммит
Представим, что нам нужно добавить пару новых блоков в html-разметку (index.html) и стилизовать их в файле style.css. Для сохранения изменений, их необходимо закоммитить. Но сначала, мы должны обозначить эти файлы для Гита, при помощи команды git add, добавляющей (или подготавливающей) их к коммиту. Добавлять их можно по отдельности:
git add index.html
git add css/style.css
или вместе — всё сразу:
git add .
Конечно добавлять всё сразу удобнее, чем прописывать каждую позицию отдельно. Однако, тут надо быть внимательным, чтобы не добавить по ошибке ненужные элементы. Если же такое произошло изъять оттуда ошибочный файл можно при помощи команды
git reset:
git reset css/style.css
Теперь создадим непосредственно сам коммит
git commit -m 'Add some code'
Флажок -m задаст commit message — комментарий разработчика. Он необходим для описания закоммиченных изменений. И здесь работает золотое правило всех комментариев в коде: «Максимально ясно, просто и содержательно обозначь написанное!»
Как посмотреть коммиты
Для просмотра все выполненных фиксаций можно воспользоваться историей коммитов. Она содержит сведения о каждом проведенном коммите проекта. Запросить ее можно при помощи команды:
git log
В ней содержится вся информация о каждом отдельном коммите, с указанием его хэша, автора, списка изменений и даты, когда они были сделаны. Отследить интересующие вас операции в списке изменений, можно по хэшу коммита, при помощи команды git show :
git show hash_commit
Ну а если вдруг нам нужно переделать commit message и внести туда новый комментарий, можно написать следующую конструкцию:
git commit --amend -m 'Новый комментарий'
В данном случае сообщение последнего коммита перезапишется. Но злоупотреблять этим не стоит, поскольку эта операция опасная и лучше ее делать до отправки коммита на сервер.
Удаленные репозитории
Сейчас наш коммит является локальным — существует только в директории .git на нашей файловой системе. Несмотря на то, что сам по себе локальный репозиторий полезен, в большинстве случаев мы хотим поделиться нашей работой или доставить код на сервер, где он будет выполняться.
1. Что такое удаленный репозиторий
Репозиторий, хранящийся в облаке, на стороннем сервисе, специально созданном для работы с git имеет ряд преимуществ. Во-первых — это своего рода резервная копия вашего проекта, предоставляющая возможность безболезненной работы в команде. А еще в таком репозитории можно пользоваться дополнительными возможностями хостинга. К примеру -визуализацией истории или возможностью разрабатывать вашу программу непосредственно в веб-интерфейсе.
Клонирование
Клонирование — это когда вы копируете удаленный репозиторий к себе на локальный ПК. Это то, с чего обычно начинается любой проект. При этом вы переносите себе все файлы и папки проекта, а также всю его историю с момента его создания. Чтобы склонировать проект, сперва, необходимо узнать где он расположен и скопировать ссылку на него. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем, попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе:
git clone https://github.com/tutorialzine/awesome-project
При клонировании в текущий каталог, там будет создана папка, в которую поместятся все проектные файлы и скрытая директория .git, с самим репозиторием, или с необходимой информацией о нем. В такой ситуации, для клонируемого репозитория, по умолчанию, будет создана папка с одноименным названием, но его можно залить и в другую директорию, например:
git clone https://github.com/tutorialzine/awesome-project new-folder
2. Подключение к удаленному репозиторию
Чтобы загрузить что-нибудь в удаленный репозиторий, сначала нужно к нему подключиться. Регистрация и установка может занять время, но все подобные сервисы предоставляют хорошую документацию.
Чтобы связать наш локальный репозиторий с репозиторием на GitHub, выполним следующую команду в терминале. Обратите внимание, что нужно обязательно изменить URI репозитория на свой.
# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git
Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать, мы дадим им разные имена. Обычно главный репозиторий называется origin.
3. Отправка изменений на сервер
Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).
$ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/tutorialzine/awesome-project.git * [new branch] master -> master
Эта команда немного похожа на git fetch, с той лишь разницей, что при помощи fetch мы импортируем коммиты в локальную ветку, а применив push, мы экспортируем их из локальной в удаленную. Если вам необходимо настроить удаленную ветку используйте git remote. Однако пушить надо осторожно, ведь рассматриваемая команда перезаписывает безвозвратно все изменения. В большинстве случаев, ее используют, чтобы опубликовать выгружаемые локальные изменения в центральный репозиторий. А еще ее применяют для того, чтобы поделиться, внесенными в локальный репозиторий, нововведениями, с коллегами или другими удаленными участниками разработки проекта. Подытожив сказанное, можно назвать git push — командой выгрузки, а git pull и git fetch — командами загрузки или скачивания. После того как вы успешно запушили измененные данные, их необходимо внедрить или интегрировать, при помощи команды слияния git merge.
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt
4. Запрос изменений с сервера
Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.
$ git pull origin master From https://github.com/tutorialzine/awesome-project * branch master -> FETCH_HEAD Already up-to-date.
Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.
Как удалить локальный репозиторий
Вам не понравился один из ваших локальных Git-репозиториев и вы хотите стереть его со своей машины. Для этого вам всего лишь надо удалить скрытую папку «.git» в корневом каталоге репозитория. Сделать это можно 3 способами:
- Проще всего вручную удалить эту папку «.git» в корневом каталоге «Git Local Warehouse».
- Также удалить, не устраивающий вас, репозиторий можно на github. Открываете нужный вам объект и переходите в пункт меню Настройки. Там, прокрутив ползунок вниз, вы попадете в зону опасности, где один из пунктов будет называться «удаление этого хранилища».
- Последний метод удаления локального хранилища через командную строку, для этого в терминале необходимо ввести следующую команду:
cd repository-path/ rm -r .git
Ветвление
Во время разработки новой функциональности считается хорошей практикой работать с копией оригинального проекта, которую называют веткой. Ветви имеют свою собственную историю и изолированные друг от друга изменения до тех пор, пока вы не решаете слить изменения вместе. Это происходит по набору причин:
- Уже рабочая, стабильная версия кода сохраняется.
- Различные новые функции могут разрабатываться параллельно разными программистами.
- Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.
- В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.
1. Создание новой ветки
Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>
$ git branch amazing_new_feature
Это создаст новую ветку, пока что точную копию ветки master.
2. Переключение между ветками
Сейчас, если мы запустим branch, мы увидим две доступные опции:
$ git branch amazing_new_feature * master
master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.
$ git checkout amazing_new_feature
В Git ветка — это отдельная линия разработки. Git checkout позволяет нам переключаться как между удаленными, так и меду локальными ветками. Это один из способов получить доступ к работе коллеги или соавтора, обеспечивающий более высокую продуктивность совместной работы. Однако тут надо помнить, что пока вы не закомитили изменения, вы не сможете переключиться на другую ветку. В такой ситуации нужно либо сделать коммит, либо отложить его, при помощи команды git stash, добавляющей текущие незакоммиченные изменения в стек изменений и сбрасывающей рабочую копию до HEAD’а репозитория.
3. Слияние веток
Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:
$ git add feature.txt $ git commit -m "New feature complete.”
Изменения завершены, теперь мы можем переключиться обратно на ветку master.
$ git checkout master
Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).
$ git merge amazing_new_feature
Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.
$ git branch -d awesome_new_feature
Если хотите создать копию удаленного репозитория — используйте git clone. Однако если вам нужна только определенная его ветка, а не все хранилище — после git clone выполните следующую команду в соответствующем репозитории:
git checkout -b <имя ветки> origin/<имя ветки>
После этого, новая ветка создается на машине автоматически.
Бывают ситуации, когда после слива каких-то изменений из рабочей ветки в исходную версию проекта, ее, по правилам хорошего тона, необходимо удалить, чтобы она более не мешалась в вашем коде. Но как это сделать?
Для локально расположенных веток существует команда:
git branch -d local_branch_name
где флажок -d являющийся опцией команды git branch — это сокращенная версия ключевого слова —delete, предназначенного для удаления ветки, а local_branch_name – название ненужной нам ветки.
Однако тут есть нюанс: удалить текущую ветку, в которую вы, в данный момент просматриваете — нельзя. Если же вы все-таки попытаетесь это сделать, система отругает вас и выдаст ошибку с таким содержанием:
Error: Cannot delete branch local_branch_name checked out at название_директории
Так что при удалении ветвей, обязательно переключитесь на другой branch.
Дополнительно
В последней части этого руководства мы расскажем о некоторых дополнительных трюках, которые могут вам помочь.
1. Отслеживание изменений, сделанных в коммитах
У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
$ git log commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7 Author: Tutorialzine Date: Mon May 30 17:15:28 2016 +0300 New feature complete commit b10cc1238e355c02a044ef9f9860811ff605c9b4 Author: Tutorialzine Date: Mon May 30 16:30:04 2016 +0300 Added content to hello.txt commit 09bd8cc171d7084e78e4d118a2346b7487dca059 Author: Tutorialzine Date: Sat May 28 17:52:14 2016 +0300 Initial commit
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
$ git show b10cc123 commit b10cc1238e355c02a044ef9f9860811ff605c9b4 Author: Tutorialzine Date: Mon May 30 16:30:04 2016 +0300 Added content to hello.txt diff --git a/hello.txt b/hello.txt index e69de29..b546a21 100644 --- a/hello.txt +++ b/hello.txt @@ -0,0 +1 @@ +Nice weather today, isn't it?
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
$ git diff 09bd8cc..ba25c0ff diff --git a/feature.txt b/feature.txt new file mode 100644 index 0000000..e69de29 diff --git a/hello.txt b/hello.txt index e69de29..b546a21 100644 --- a/hello.txt +++ b/hello.txt @@ -0,0 +1 @@ +Nice weather today, isn't it?
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.
2. Возвращение файла к предыдущему состоянию
Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита — использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:
$ git checkout 09bd8cc1 hello.txt
3. Исправление коммита
Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:
$ git revert HEAD
Для остальных будем использовать идентификаторы:
$ git revert b10cc123
При отмене старых коммитов нужно быть готовым к тому, что возникнут конфликты. Такое случается, если файл был изменен еще одним, более новым коммитом. И теперь git не может найти строчки, состояние которых нужно откатить, так как они больше не существуют.
4. Разрешение конфликтов при слиянии
Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:
// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
console.log(arr[i]);
}
Тим предпочитает forEach:
// Use forEach to console.log contents.
arr.forEach(function(item) {
console.log(item);
});
Они оба коммитят свой код в соответствующую ветку. Теперь, если они попытаются слить две ветки, они получат сообщение об ошибке:
$ git merge tim_branch Auto-merging print_array.js CONFLICT (content): Merge conflict in print_array.js Automatic merge failed; fix conflicts and then commit the result.
Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
<<<<<<< HEAD // Use a for loop to console.log contents. for(var i=0; i<arr.length; i++) { console.log(arr[i]); } ======= // Use forEach to console.log contents. arr.forEach(function(item) { console.log(item); }); >>>>>>> Tim's commit.
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним — конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.
// Not using for loop or forEach. // Use Array.toString() to console.log contents. console.log(arr.toString());
Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:
$ git add -A $ git commit -m "Array printing conflict resolved."
Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).
5. Настройка .gitignore
В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore
- Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
- Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
- Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.
Вот хорошие примеры файлов, которые нужно игнорировать:
- Логи
- Артефакты систем сборки
- Папки node_modules в проектах node.js
- Папки, созданные IDE, например, Netbeans или IntelliJ
- Разнообразные заметки разработчика.
Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:
*.log build/ node_modules/ .idea/ my_notes.txt
Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.
Git bash и git.io
Руководствуясь часто встречающимися, при изучении системы, вопросами новичков, разберем еще несколько непонятных словосочетаний.
- Git Bash(Bourne Again Shell) — это приложение, являющееся эмулятором командной строки и предоставляющее, операционной системе, некоторые распространенные утилиты bash и собственно саму систему Git. Это терминал, используемый для взаимодействия с персональным компьютером, посредством письменных команд.
- URL-адреса хранилищ на Гитхабе могут быть довольно длинными, из-за больших имен репозиториев и файлов. Работать с такими ссылками очень не удобно. Поэтому сайт github.io создал git.io — неплохой сервис по преобразованию этих длинных и беспорядочных URL-адресов в более короткие и понятные. Сайт был создан в 2011 году и вплоть до недавнего времени отлично справлялся со своими обязанностями. Однако в начале этого года компания Гитхаб, из-за участившихся попыток хакеров использовать сайт в злонамеренных целях, остановила работу сервиса, а чем известила пользователей в своем блоге. Разработчики популярного ресурса рекомендуют пользоваться другими URL-cutter’ами, пока работа сервиса не будет налажена.
Заключение.
Вот и все! Наше руководство окончено. Мы очень старались собрать всю самую важную информацию и изложить ее как можно более сжато и кратко.
Git довольно сложен, и в нем есть еще много функций и трюков. Если вы хотите с ними познакомиться, вот некоторые ресурсы, которые мы рекомендуем:
- Официальная документация, включающая книгу и видеоуроки – тут.
- “Getting git right” – Коллекция руководств и статей от Atlassian – тут.
- Список клиентов с графическим интерфейсом – тут.
- Онлайн утилита для генерации .gitignore файлов – тут.
Оригинал статьи доступен на сайте http://tutorialzine.com
Другие статьи по теме
10 полезных Git команд, которые облегчат работу
Шпаргалка по Git, в которой представлены основные команды
Введение
В этой инструкции мы научим вас создавать удаленный репозиторий, подключаться к нему различными методами и покажем, какие команды Git использовать.
Немного теории
Совместной разработка в Git предполагает, что у разработчиков, работающих над каким-то проектом, есть своя копия репозитория, соответственно и своя локальная история в зависимости от модели ветвления. Так как разработчикам обычно нужно поделиться серией коммитов, а не каким-то одним, в Git есть возможность делиться целыми ветками между репозиториями.
Удаленный репозиторий – это репозиторий, размещенный в локальной или интернет сети. Удаленный репозиторий используется для того, чтобы делиться и обмениваться кодом между разработчиками в рамках сети. Его также можно использовать, если вы разрабатываете проект на нескольких устройствах.
Ветки слежения – это ссылки на определенное положение веток удаленного репозитория. Перемещение веток слежения происходит автоматически при выполнении команд, которые будут показаны дальше.
Имена веток слежения имеют вид <remote>/<branch>. Если один из разработчиков произвел отправку на удаленный сервер ветки develop, когда у второго разработчика есть своя локальная ветка develop, то удаленная ветка будет называться origin/develop и соответственно быть веткой слежения. При разработке orgin по умолчанию называется удаленный сервер.
Создание удаленного репозитория
Создадим новый репозиторий на GitHub. Для этого на сайте GitHub кликните на значок плюса справа сверху или перейдите по ссылке.
Перед нами откроется следующая форма:
- Owner (владелец) – выбрать персональный аккаунт, который будет иметь полный доступ к данному репозиторию.
- Repository name (название репозитория) – при названии репозитория принято использовать PascalCase (составные слова с заглавной буквы) и kebab-case (составные слова через дефис).
- Description (описание) – описание проекта.
- Public – кто угодно может просматривать репозиторий, но коммитить смогут только те аккаунты, которым вы предоставите доступ.
- Private – никто, кроме вас, не сможет коммитить или просматривать данный репозиторий без права доступа.
- Add a README file – создает readme.md файл, который нужен для добавления длинного описания.
После нажатия Create repository нас перекинет на страницу нашего нового репозитория.
Сейчас в созданном github repo нет никаких файлов. Чтобы их выгрузить из локального репозитория, нужно подключиться к удаленному. Чтобы добавить удаленный репозиторий и присвоить ему название, которое используется для удобства как сокращение адреса, просто выполните команду По умолчанию удаленный репозиторий называется origin, о чем было сказано ранее, но можно присваивать любое название. Ссылочные объекты у подключаемого удаленного репозитория будут скопированы. С помощью https будет проще работать на нескольких устройствах нежели с перемещением ssh ключей между ними. А порт 443, который используется данным протоколом, обычно открыт. Но для работы с этим способом подключения может понадобиться введения логина и пароля, например, при клонировании приватного репозитория. Чтобы подключить репозиторий по ssh, нужно произвести генерацию пары SSH-ключей: SSH является более безопасным протоколом, чем HTTPS, но и к тому же позволяет не прописывать каждый раз пароль, вместо этого сравнивается публичный ключ с хранящимся у вас. Для изменения адреса подключенного удаленного репозитория используется: Первое значение (<remote_name>) — название удаленного репозитория, второе значение (<remote_url>) — новый url. Для того чтобы просмотреть список названий удаленных репозиториев, которые были добавлены, используйте команду: Указав ключ -v, можно просмотреть, какие адреса в добавленных удаленных репозиториях используются для чтения и записи. Полный список удаленных ссылок можно получить с помощью команды: Либо для получения удаленных веток и дополнительной информации используйте команду: <remote> — название удаленного репозитория, которое ему дали после подключения. Можно использовать и url интересующего удаленного репозитория.
Настройка подключения к удаленному репозиторию
Добавление удаленного репозитория. Команда git remote add origin
git remote add origin <URL>Подключение по HTTPS
git remote add origin https://github.com/ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.gitПодключение по SSH
git remote add origin git@github.com:ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.git
ssh-keygen -t ed25519 -C "ПОЧТА_GitHub_АККАУНТА"
ssh-keygen -t rsa -b 4096 -C "ПОЧТА_GitHub_АККАУНТА"
git remote set-url <remote_name> <remote_url>Основы работы с удаленным репозиторием Git
Просмотр удаленного репозитория
git remotegit ls-remote <remote> git remote show <remote> 
Изменение удаленного репозитория
Чтобы отправить изменения (имя ветки) <branch-name> на сервер <remote-name>, задействуйте команду:
git push <remote-name> <branch-name>Если ветка, которую вы хотите отправить, не отслеживается, то добавьте флаг —set-upstream. На примере ветки develop это будет выглядеть вот так:
git push --set-upstream origin developВ GitHub же есть кнопка (Add file) для загрузки или создания файлов прямо в удаленном репозитории.
Так же возможно переименование удаленного репозитория с прежнего имени <old-name> на новое <new-name>.
git remote rename <old-name> <new-name>Получение изменений из удаленного репозитория
Для связи с указанным удаленным репозиторием используется следующая команда, которая подтянет новые изменения на локальный репозиторий:
git fetch [remote-name]
После выполнения команды появляются ссылки на все ветки из указанного удаленного репозитория. Данная команда забирает данные в наш локальный репозиторий, но не объединяет или перебазирует их с коммитами в локальном репозитории, связанного с удаленным. Поэтому используйте merge или rebase, когда закончите работать над изменениями.
Если ветка настроена на отслеживание удаленной ветки, то можно использовать более удобную команду:
git pull Данная команда заменяет прописывание двух команд:
git fetch; git mergeЕсть и универсальнее способ: клонирование репозитория. Клонирование копирует все файлы и коммиты удаленного репозитория, после чего уже можно использовать предыдущую команду — git fetch, если понадобятся новые изменения из удаленного репозитория.
git clone [url]Клонирование может быть по HTTPS, либо по SSH. Рассмотрим каждый вариант.
- По HTTPS
- Может быть использовано независимо от видимости репозитория.
- Понадобятся имя пользователя и пароль аккаунта GitHub. В качестве пароля используется персональный токен доступа. Сгенерировать персональный токен доступа можно в настройках профиля GitHub (Settings > Developer Settings > Personal access tokens).
- Команда будет иметь вид:
git clone https://github.com/ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.git- По SSH
- Доступ к гиту предоставляется по защищенному протоколу.
- Необходимо сгенерировать пару SSH-ключей и добавить публичный ключ в аккаунт GitHub.
- Команда будет иметь вид:
git clone git@github.com:ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.gitВ GitHub есть зеленая кнопка (Code), кликнув на которую можно будет скопировать url-адрес для выбранного способа клонирования или скачать архивом данный репозиторий.
Для клонирования определенной ветки репозитория, допишите флаг —single-branch:
git clone --single-branch [url]После работы git clone отслеживание удаленный ветки ставится автоматически.
Если же при клонировании вы хотите другое название (не origin) удаленному репозиторию, то выполните:
git clone -o ticgitТогда по умолчанию ветка слежения будет иметь вид ticgit/master (tcgit — пример названия удаленного репозитория).
Работа git clone пошагово выглядит так:
- Создается новая директория.
- В ней создается репозиторий посредством выполнения git init.
- Выполняется команда git remote add origin, которая добавляет по URL (назван origin) удаленный репозиторий.
- Подхватываются новые изменения данного удаленного репозитория через git fetch.
- С помощью git checkout извлекается последний коммит в рабочую директорию.
Удаление удаленного репозитория
Если интересует убрать подключение к удаленному репозиторию, то используйте команду
git remote rm <name>Где <name> — название репозитория. Вместе с тем удалятся настройки и отслеживаемые ветки.
Чтобы удалить сам удаленный репозиторий, это нужно сделать на сервере, на котором он размещен. На GitHub перейдите в раздел настроек (“Settings”), проскрольте до самого низа, где будет поле Danger Zone. Нажмите на Delete this repository, в открывшемся новом поле введите *Имя пользователя*/*Названия репозитория* для подтверждения удаления. В нашем случае это T.Rex/git-remote-add-origin.
Заключение
Мы создали удаленный репозиторий, узнали про подключение удаленного репозитория разными способами, рассмотрели команды clone, fetch, push, pull для взаимодействия с ним.