Система управления версиями Git. Система управления версиями git и российский сервис хранения исходного кода gitflic
 Скачать 3.56 Mb.
|
|
Формат команды git cherry-pick: a) git cherry-pick <ключи> <хеш-значение коммита, подлежащего ко- пированию> b) git cherry-pick <ключи> <хеш-значение первого коммита> <хеш- значение последнего коммита> В случае а будет скопирован один коммит. В случае b будет скопиро- вана последовательность коммитов. Возможные значения ключей: --edit – позволяет отредактировать комментарий к коммиту; --no-commit – в рабочую директорию будут скопированы различия между её текущим содержимым и коммитом, указанным в команде, новый коммит создан не будет; --abort – используется только при устранении конфликтов для преры- вания выполнения команды; --continue – используется только при устранении конфликтов для про- должения выполнения команды после устранения конфликта. Команда git cherry-pick копирует указанный коммит в текущую дирек- торию. Работает она следующим образом. Вычисляется разница между те- кущим состоянием рабочей директории и рабочей директорией, зафиксиро- ванной в переносимом коммите. Разница добавляется в текущую рабочую директорию. Если возникает конфликт, выполнение команды останавлива- ется до устранения конфликта. После добавления разницы создаётся новый коммит в текущей ветке. 87 2.25. Работа с внешним репозиторием Git является распределённой системой контроля версий. Это значит, что каждый пользователь Git хранит свои репозитории отдельно и незави- симо от других пользователей. Хранить репозитории возможно или на ло- кальном компьютере, или в сетевом хранилище, называемом внешним ре- позиторием. Использование внешнего репозитория удобно при коллектив- ной работе, для обмена данными между участниками проекта или, когда ин- дивидуальный разработчик использует несколько компьютеров для выпол- нения работы. Для работы с Git не требуется постоянная связь с внешним репозиторием. Рабочая директория всегда находится на локальном компьютере. В процессе ра- боты коммиты тоже сохраняются на локальном компьютере. И только, когда разработчик готов поделиться с коллегами результатом, или когда индивиду- альному разработчику необходимо сменить рабочее место, коммиты копиру- ются во внешний репозиторий. Внешний репозиторий обычно защищён паро- лем, и им может пользоваться ограниченный круг разработчиков. Исключение составляют open-source проекты, для которых внешний репозиторий паролем не защищают, но ограничивают права на запись коммитов. В качестве внешнего репозитория возможно использовать любое фай- ловое хранилище. Если файловое хранилище не подготовлено для хранения репозиториев, не имеет специальных инструментов для создания репозито- риев, просмотра их содержимого и подобных операций, то пользоваться им неудобно. Разработчикам программного обеспечения повезло, для них со- здан ряд внешних репозиториев с удобным интерфейсом и набором инстру- ментов для коллективной работы. Изложение материала в настоящем учеб- ном пособии базируется на внешнем репозитории GitFlic (GitFlic, 2022). Нужно иметь в виду, что команды Git, предназначенные для работы с внеш- ним репозиторием, не зависят от репозитория, поэтому изложенный мате- риал остаётся универсальным. 2.25.1. Подключение внешнего репозитория, группа команд git remote О сайте GitFic будем думать, как об оболочке, внутри которой хранится множество репозиториев. Единицей хранения в GitFlic является проект. 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. Получение изменений из локального репозитория, команда |