Файл: Система управления версиями git и российский сервис хранения исходного кода gitflic.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 06.12.2023

Просмотров: 212

Скачиваний: 7

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

88
Проект – это внешняя копия локального репозитория. Процедура, позволя- ющая установить соответствие между локальным репозиторием и проектом, называется подключением внешнего репозитория.
Перед тем, как подключать внешний репозиторий (проект), его необ- ходимо создать. Сейчас нас интересует адрес проекта, который будет его однозначно идентифицировать.
Рисунок 2.20 – Создание проекта GitFlic
На рисунке 2.20 показана часть экранной формы GitFlic, предназна- ченной для создания проекта. Адрес проекта находится в поле URL про-
екта. Адресом является весь текст, находящийся в этом поле, в конце строки необходимо указать расширение .git. В итоге получится: https://gitflic.ru/project/baa-test/project-1.git
Это и есть адрес внешнего репозитория.
Для подключения внешнего репозитория к локальному используется команда git remote add.
Формат команды git remote add:
git remote add <название внешнего репозитория> <адрес внешнего ре- позитория>
Название внешнего репозитория – произвольная строка, которую в

89 дальнейшем можно будет использовать для ссылки на него.
В процессе выполнения команды git remote add потребуется указать логин и пароль учётной записи, содержащей проект, к которому происходит подключение.
Внешний репозиторий является полноценным репозиторием, у кото- рого есть ветки с их указателями, история коммитов, блобы и так далее. Хра- нятся объекты, принадлежащие внешнему репозиторию, в локальной дирек- тории .git/refs/remote/<имя внешнего репозитория>. Ветки удалённого репо- зитория могут отличаться от веток локального репозитория до момента, пока не произведена синхронизация локального и внешнего репозиториев.
Чтобы было ясно, какой объект имеется в виду, в документации к имени ветки внешнего репозитория добавляется имя репозитория. Например, ветка
Branch_1 репозитория ex_rep будет обозначаться так: ex_rep/Branch1.
После подключения с внешним репозиторием можно выполнить сле- дующие действия:
1. Отключить. Для этого используется команда:
git remote remove <название удалённого репозитория>.
Внимание! Команда git remote remove не удаляет внешний репо-
зиторий, а только отключает его.
2. Переименовать. Для этого используется команда:
git remote rename <старое название> <новое название>
К одному локальному репозиторию могут быть подключены не- сколько внешних репозиториев. Их список можно сформировать командой:
git remote show
Если в этой команде указать имя внешнего репозитория, то будут вы- ведены сведения о репозитории.
2.25.2. Отправка изменений в удалённый репозиторий, команда git
push
После того, как было выполнено подключение к внешнему репозито- рию, в него можно скопировать локальный репозиторий. Для выполнения этой операции используется команда git push.
Формат команды git push:
git push <ключи> <имя внешнего репозитория> <имя ветки>


90
Возможные значения ключей:
--all – копировать во внешний репозиторий все ветки. Если этот ключ отсутствует, то обязательно должна быть указана ветка, которая будет ко- пироваться;
--force – перезаписывает ветку во внешнем репозитории, не проверяя наличие конфликтов. Ветка во внешнем репозитории будет точно такой, как в локальном репозитории. Все изменения, внесённые в ветку внешнего ре- позитория до выполнения команды push, будут потеряны;
--force-with-lease – удаляет из внешнего репозитория все коммиты, кото- рых нет в локальном репозитории. Если коммит во внешний репозиторий был добавлен другим пользователем, то выполнение команды будет прервано.
При выполнении команды push выполняется проверка, есть ли в ветке внешнего репозитория коммиты, добавленные другими пользователями по- сле последнего копирования ветки локального репозитория. Если таких коммитов нет, то команда push будет выполнена успешно. Если такие ком- миты есть, что означает невозможность добавления новых коммитов в ре- жиме fast-forward, то выполнение команды push будет прервано и завер- шится с ошибкой.
Когда разработчик выполняет индивидуальный проект, никаких про- блем с копированием локального репозитория не возникает. При командной работе разрабатывается регламент обновления внешнего репозитория. Од- ной из составляющих регламента являются merge-запросы (запросы на сли- яние). Хранилища репозиториев, такие как GitFlic, предоставляют инстру- ментальные средства для работы с запросами на слияние. Технология ра- боты с запросами на слияние заключается в ограничении права разработ- чика напрямую вносить изменения во внешний репозиторий. Вместо пря- мого изменения разработчик должен отправить запрос на слияние руково- дителю проекта (или члену команды, ответственному за обновление репо- зитория). После проверки коммиты, включённые в запрос на слияние, будут добавлены во внешний репозиторий или будет выполнено устранение кон- фликтов.
2.25.3. Клонирование удалённого репозитория, команда git clone
Под клонированием репозитория понимается создание на локальном компьютере копии удалённого репозитория. Необходимость клонирования

91 возникает, когда разработчик хочет подключиться к новому проекту или продолжить работу после смены компьютера.
Формат команды git clone:
git clone <адрес внешнего репозитория> <директория>
Директория – это полный путь к директории, в которой будет разме- щена копия репозитория. Если параметр «директория» не указан, то в ди- ректории, из которой вызвана команда git clone, будет создана поддиректо- рия, и в неё будет скопирован внешний репозиторий. Имя вновь созданной поддиректории совпадает с именем проекта GitFlic.
Рассмотрим пример клонирования внешнего репозитория (имя про- екта git-book) в корневой каталог диска С: локального компьютера. В про- екте git-book имеются две ветки: Main_branch и Working_branch. Содержи- мое рабочей директории ветки Main_branch показано на рисунке 2.21.
Рисунок 2.21 – Рабочая директория ветки Main_branch
Выполним команду git clone:
$ cd c:/
$ git clone https://gitflic.ru/project/GitUser/git-book.git
Cloning into 'git-book'... remote: Counting objects: 29, done remote: Finding sources: 100% (29/29) remote: Getting sizes: 100% (12/12) remote: Total 29 (delta 10), reused 29 (delta 10)
Receiving objects: 100% (29/29), done.
Resolving deltas: 100% (10/10), done. warning: remote HEAD refers to nonexistent ref, unable to checkout.


92
Была создана директория git-book, и в неё скопирован внешний репо- зиторий. Копирование прошло успешно, но в последней строчке отчёта ко- манды git clone имеется предупреждение: remote HEAD refers to nonexistent ref, unable to checkout, которое говорит о том, что невозможно переклю- читься на главную ветку репозитория.
Перейдём в директорию git-book и посмотрим, какие в ней находятся файлы.
$ cd git-book
/c/git-book
(master)
$ dir
Директория git-book является репозиторием, о чём говорит имя ветки в скобках, после имени директории. Имя ветки master. Git создал ветку mas- ter в процессе копирования. Но такой ветки в репозитории нет, поэтому ко- манда dir показывает, что рабочая директория пуста. Переключимся на ветку Main_branch:
$ git checkout Main_branch
Switched to a new branch 'Main_branch' branch 'Main_branch' set up to track 'origin/Main_branch'.
Git сообщил, что произошло переключение на ветку Main_branch, и что эта ветка соответствует ветке Main_branch репозитория (origin/
Main_branch). Теперь дерево каталога git-book выглядит следующим образом:
¦ File1.txt
¦ File2.txt
| File3.txt
¦ Learn_diff.txt
¦ Test_Merge.txt
¦ Изменения.txt
¦
+---.git
¦ ¦ config
¦ ¦ description
¦ ¦ HEAD
¦ ¦ index
¦ ¦ packed-refs
¦ ¦
¦ +---hooks
¦ ¦
¦ +---info
¦ ¦
¦ +---logs
¦ ¦
¦ +---objects
¦ ¦ +---info
¦ ¦ L---pack
¦ ¦ pack-f06005ad11ffcd12f3e780ec62357cdadf02d2a1.idx
¦ ¦ pack-f06005ad11ffcd12f3e780ec62357cdadf02d2a1.pack
¦ ¦
¦ L---refs
¦ +---heads
¦ ¦ Main_branch
¦ ¦
¦ L---tags

93
L---Dir1
В рабочей директории присутствуют те же файлы, что и во внешнем репозитории. Вместе с тем, папка objects выглядит непривычно. В ней от- сутствуют объекты и присутствует папка pack, содержащая два файла. Пер- вый файл имеет расширение idx, второй имеет расширение pack. Эти два файла хранят объекты репозитория в упакованном виде. Файл с расшире- нием idx хранит ссылки на объекты, размещённые в файле с расширением pack. Файл с расширением pack хранит разности для объектов репозитория.
Такая форма хранения объектов сама является объектом Git и называется pack-файл. Pack-файлы гораздо компактнее, чем независимые объекты, они создаются при пересылке репозиториев между компьютерами. Кроме того, pack-файлы могут создаваться, если репозиторий на локальном компьютере стал слишком большим.
Рассмотрим ещё одну особенность клонированного репозитория. Она заключается в том, что в клонированном репозитории находятся не только локальные ветки, но и ветки внешнего репозитория. Список веток внешнего репозитория можно посмотреть с помощью команды git branch с ключом -r:
$ git branch -r origin/Main_branch origin/Working_branch
На ветку внешнего репозитория возможно переключиться:
$ git checkout origin/Main_branch
Note: switching to 'Git-book/Main_branch'.
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c
Or undo this operation with: git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 15870e5 Check clone comand
Видим, что ветка внешнего репозитория доступна в режиме “detached
HEAD”. Её можно только просматривать.


94
2.25.4. Просмотр внешнего репозитория, команда git fetch
Команда git fetch позволяет загрузить обновлённые файлы из внеш- него репозитория на локальный компьютер. При выполнении команды git fetch состояние рабочей директории не изменяется. Загружаемые обновлён- ные файлы сохраняются в ветках внешнего репозитория и не оказывают влияния на локальный репозиторий. Такой режим обновления позволяет проанализировать изменения, полученные из внешнего репозитория. Если изменения не конфликтуют с кодом, находящимся в локальном репозито- рии, то они могут быть добавлены в него командой git merge.
Формат команды git fetch:
git fetch <ключи> <имя удалённого репозитория>
Возможные значения ключей:
--all – получить изменения из всех подключённых репозиториев;
--depth=n – получить не более n коммитов из каждой ветки;
--shallow-since = date – получить только коммиты, созданные после даты date.
Рассмотрим работу команды fetch на примере. Во внешнем репозито- рии, в ветке Main_branch рабочая директория выглядит так, как показано на рисунке 2.22.
Рисунок 2.22 – Внешний репозиторий для демонстрации команды fetch
Из директории Git-book выполним команду git fetch Git-book и выве- дем список файлов, находящихся в рабочей директории:
/c/git-book
(Main_branch)
$ git fetch Git-book remote: Counting objects: 8, done remote: Finding sources: 100% (6/6)

95 remote: Getting sizes: 100% (4/4) remote: Total 6 (delta 2), reused 6 (delta 2)
Unpacking objects: 100% (6/6), 574 bytes | 95.00 KiB/s, done.
From https://gitflic.ru/project/abulychev/git-book
15870e5..e7ade33 Main_branch -> Git-book/Main_branch
* [new branch] Working_branch -> Git-book/Working_branch
$ dir
Dir1 File2.txt Learn_diff.txt Изменения.txt
File1.txt File3.txt Test_Merge.txt
В отчёте команды git fetch сказано, что изменения в коммитах ветки
Main_branch загружены в ветку Git-book/Main_branch, а изменения в ветке
Working_branch загружены в ветку Git_book/Working_branch. В списке фай- лов, находящихся в рабочей директории, отсутствует файл Fetch_main.txt, который есть во внешнем репозитории. Этого следовало ожидать, так как команда git fetch не обновляет рабочую директорию. Выполним смену ветки
Main_branch на ветку Git-book/Main_branch и снова выведем список файлов, находящихся в рабочей директории:
− $ git checkout Git-book/Main_branch
− Note: switching to 'Git-book/Main_branch'.

− You are in 'detached HEAD' state. You can look around, make experi- mental
− changes and commit them, and you can discard any commits you make in this
− state without impacting any branches by switching back to a branch.

− If you want to create a new branch to retain commits you create, you may
− do so (now or later) by using -c with the switch command. Example:

− git switch -c

− Or undo this operation with:

− git switch -

− Turn off this advice by setting config variable advice.detachedHead to false

− HEAD is now at e7ade33 Fetch commit


/c/git-book
((e7ade33...))
− $ dir
− Dir1 File1.txt File3.txt Test_Merge.txt
− Fetch_main.txt File2.txt Learn_diff.txt Изменения.txt

Файл Fetch_main.txt появился в рабочей директории, но это рабочая директория ветки внешнего репозитория, которая находится в режиме
“detached HEAD”. В этой рабочей директории файлы можно только про- смотреть с целью принятия решения о добавлении изменений в локальную


96 рабочую директорию. Допустим, принято решение добавить файл
Fetrch_main.txt в локальную рабочую директорию. Для этого:
− сменим ветку на Main_branch;
− выполним команду git merge Git-book/Main_branch.
$ git checkout Main_branch
Previous HEAD position was e7ade33 Fetch commit
Switched to branch 'Main_branch'
Your branch is ahead of 'origin/Main_branch' by 2 commits.
(use "git push" to publish your local commits)
$ git merge Git-book/Main_branch
Updating 15870e5..e7ade33
Fast-forward
Fetch_main.txt | 1
+
1 file changed, 1 insertion(+) create mode 100644 Fetch_main.txt
/c/git-book
(Main_branch)
$ dir
Dir1 File1.txt File3.txt Test_Merge.txt
Fetch_main.txt File2.txt Learn_diff.txt Изменения.txt
Теперь файл Fetch_main.txt находится в рабочей директории локаль- ного репозитория. Для фиксации этого изменения необходимо добавить этот файл в индекс и сделать коммит.
2.25.5. Получение изменений из локального репозитория, команда
1   ...   4   5   6   7   8   9   10   11   12