Работа с Git: введение в GitHub (2023)

С помощью этой статьи вы узнаете

• Зачем нужны системы контроля версий

• Откуда взялся Гит?

• Как создать и внести изменения в собственный репозиторий на GitHub

• Что такое форк, ветка и другие интересные слова из мира Git

• Как создать свой запрос на включение

введение

результатнеопытные разработчикиПроблемный Git Master и не понимает логику сервиса с первого запуска. Но как только вы создадите несколько репозиториев или, что еще лучше, углубитесь в настоящую историю создания стартапа на треках DevOps, работа с ветками станет более удобной для пользователя, а PR и MR больше не будут путать. Ошибки в любом случае будут, но будьте готовы!

Начинать

Когда пишешь свою первую программу, все кажется таким лаконичным, простым и понятным. Но по мере развития вашей программы она получает новые возможности, становится все более сложной и крупной. Потом появляются первые ошибки. И было бы здорово иметь возможность помнить историю изменений или видеть, что было добавлено или удалено в коде, почему может возникнуть ошибка.

Первое и самое простое решение: "А перед внесением каких-либо изменений сохраняем ли мы копию программы (просто копируем папку с кодом)?"

На самом деле, это сработает, но пока. Проект будет продолжать развиваться и будет полезен не только вам, но и вашим друзьям, которые хотят добавить что-то свое в код. В рядах программистов это имеет значение, и нужно как-то договориться, кто какой код трогает, а потом синхронизировать изменения, чтобы все фичи продавались.

Пришло время систем контроля версий, которые могут помнить, какие изменения были внесены в какие файлы, а также отображать историю этих изменений.

О Git

Существует несколько систем контроля версий: Git, Subversion, Team Foundation Server, Mercurial. Сегодня мы познакомимся с Git —самый любимыйиз них, по скромному признанию, более 90% разработчиков.

Git был выпущен 7 апреля 2005 года и был создан для управления разработкой ядра Linux. Между прочим, он был создан им самим.Линус Торвальдс, а на сегодняшний день разрабатывается и поддерживаетсяДжунио Хамано.

Git — это распределенная система контроля версий: есть сервер, через который разработчики обмениваются кодом. Разработчик копирует (клонирует) проект на свою локальную машину, вносит изменения и сохраняет их на удаленном сервере. При необходимости другие разработчики могут скопировать эти изменения себе.

История и копия проекта хранятся локально и, в общем-то, никакой дополнительной информации от других клиентов не требуется. Вы также можете работать с репозиторием без интернета (например, в самолете) и при его появлении просто загружать изменения в удаленный репозиторий на выделенном сервере.

Если компьютер разработчика выходит из строя, проект не теряется, а живет на выделенном сервере. Такой выделенный сервер можетвстань и приспособьсяили используйте готовые растворы.

GitHub — крупнейший веб-сервис, который позволяет вам совместно разрабатывать с Git и сохранять изменения на своих серверах. Правда в томфункциональностьGitHub гораздо больше, но пока нас интересует только совместная разработка и история изменений. есть такжеGitlabGenericName,бит куби другие, но мы будем использовать GitHub как самый популярный прямо сейчас.

презентация

Готовимся к полету.

НачинатьВойдите в GitHub: введите имя пользователя, адрес электронной почты и создайте пароль. После «Создать учетную запись» не забудьте проверить и подтвердить адрес электронной почты (вы можете пропустить поиск Github для подтверждения по электронной почте).

GitHub имеет отдельные права на работу с репозиториями. Вы можете установить разные политики: сделать репозиторий общедоступным иЧастный, ограничивает права кругу пользователей или одному человеку, например, чтобы иметь возможность просматривать хранилище, но не изменять содержащиеся в нем данные.

Чтобы сервис определил, кто вы и есть ли у вас разрешение на работу с тем или иным репозиторием, представьтесь и пройдите процедуруаутентификация.

GitHub обеспечивает безопасность с помощью двух сетевых протоколов,HTTPSмиSSH, и вся работа с сервисом ведется через один из них.

Мы будем работать с GitHub из терминала по SSH. Для этого мы один раз генерируем специальные ключи и добавляем один из них в нашу учетную запись GitHub.

Также можно работать по HTTPS, но каждый раз нужно будет вводить пароль и специальный пароль.Символ.

Несколько слов о SSH и о том, как он работает. SSH — это сетевой протокол для зашифрованного соединения между клиентом и сервером, через который можно безопасно передавать данные.

При подключении используется пара ключей: открытый (открытый, public) и закрытый (private, private). Пользователь создает пару ключей специальной командой и хранит приватный ключ у себя, а публичный выкладывает на сервер (в нашем случае на GitHub). и все работает спасибоасимметричное шифрование.

Алгоритм следующий: отправитель (GitHub) шифрует сообщение открытым ключом и отправляет сообщение клиенту (нам), а мы расшифровываем его закрытым ключом, который бережно храним при себе. То, что зашифровано открытым ключом, может быть расшифровано только закрытым ключом.

Давайте создадим пару ключей и добавим открытый ключ на GitHub.

Чтобы создать пару ключей, вы должны ввести команду в терминале, указать путь для сохранения ключей и указать пароль для ключа (необязательно).

Также верим, что путь к ключам указан по умолчанию и пароль на ключи не установлен.

Пароль ключа требуется в качестве дополнительной меры безопасности на случай, если ваш закрытый ключ внезапно попадет в чужие руки.

$ ssh-keygen Генерация пары открытый/закрытый ключ rsa.# путь к ключам, путь по умолчанию в скобках, ничего не отображается, даже звездочки# если вы нажмете ввод, ничего не вводя, пароль будет пустым Введите парольную фразу (пусто, если нет парольной фразы): # Повторите пароль ssh/id_rsaВаш открытый ключ был найден в /Users/ifireice/.ssh/id_rsa.pub ---+| сохранен || ох || "=" || + + || +S* X || oB.@X. || . ИЛИ.# * . || . +.*.%о || . *.+Э. |+----[SHA256]-----+

Бинго, сгенерированные ключи: в указанном каталоге появляются два файла: id_rsa и id_rsa.pub.

Теперь вам нужно добавить открытый ключ в свою учетную запись GitHub:

# выведите содержимое публичного ключа в консоль$ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDJfHIi73sKd6cqm3RwKuY1zl46aAaE6X9Gp/6zJiY3BiJj95oJjPdpfpPhVFWLIbmT8zFAtOLbX9N4C3b0enHUzgMacP/Kl4AbrAkhLqaua9iDVNxxiTVxADG1M5525oc/eAvx7y0pXIb9ouWdYJSKa8/TUYFhWlCzV2quY9SA0FaMs7eY41+KWYpG.....tA0oGxv+7WmXQmQzleLIRG13KQ+VAbL2vabdPcRoGuZavh0smOr/GtVSnLdspZ5RgONMSPWlF2I1YHMRQ7CIKPs= ifireice@ifireice-osx$

Скопируйте ключ ssh-rsa внизу файла и вставьте его в свою учетную запись GitHub.

Что ж, мы пока закончили с настройкой GitHub, осталось установить Git на машину. Вы можете сделать это, используяофициальноИнструкции (выберите пункт для вашей операционной системы).

Терминология

Пришло время расширить свой словарный запас Git, прежде чем создавать наш первый запрос на включение.

Репозиторий (Репозиторий)— это каталог проекта, который сканирует Git. В каталоге хранится проект, история изменений и метаинформация о проекте (в скрытом каталоге.git).

Индекс— хранилище, содержащее имена файлов и их изменения, которые должны быть включены в следующий коммит. По сути, индекс — это просто файл. Сами файлы в индекс не идут, их нужно добавлять явнодобавить git.

сила (сила)- Это исправление для изменения истории проекта (изменения индекса). Коммит хранит измененные файлы, имя автора коммита и время коммита. Кроме того, каждый коммит имеет уникальный идентификатор, который вы можете использовать для ссылки на него в любое время. Думайте о коммите как о точке сохранения.

детский- Последовательность обязательств. Собственно ссылка на последний коммит на этой ветке. Ветки не зависят друг от друга: вы можете вносить изменения в одну, не затрагивая другую (если только вы специально не попросите об этом). Вы начинаете работать над веткой - main, ее вы увидите чуть позже.

Гейбл- собственный филиал (Гейбл) проекта. Это означает, что GitHub создаст собственную копию проекта, эта копия будет находиться в вашем пространстве имен, и вы легко сможете внести изменения, нажав Changes.

Запрос на слияние: PR Pull Request (PR, он же MR Merge Request (mr))- предложение изменить код в чужом репозитории. Предположим, вы взяли чужой репозиторий и поработали с ним, а теперь хотите, чтобы ваши изменения были слиты в исходный репозиторий. Поэтому он создает PR с запросом на добавление ваших изменений в репозиторий.

Начало работы

Начнем очень просто: создадим наш репозиторий и сделаем нашу первую фиксацию.

Определим параметры:

• (1) Имя репозитория: Der Name des Repositories.

• (2) Описание: Описание репозитория.

• (3)тип репозитория: Public (публичный) или Private (частный). Теперь выберем общедоступный: каждый может видеть содержимое репозитория.

• (4) Установите флажок «Создать файл README». Этот файл имеет форматтройникОпишите проект или другую документацию. Содержимое этого файла видно, если мы заходим на главную страницу репозитория. Примеры1,2,3.

• (5) Когда мы знаем, на каком языке будет проект, мы можем добавить шаблон.игнорировать.gitдля этого языка. Теперь у нас нет языка, поэтому мы ничему не верим..игнорировать.git.

• (6) Выберитетип лицензиидля нашего кода. Лицензия определяет права проекта. стоит обратить вниманиеBSD3оКОМпотому что они предлагают баланс прав и обязанностей.

(7) По умолчанию имя основной ветки на GitHub — main, но до этогосамый молодойЭрыЛерер.

И нажмите кнопку «Создать репозиторий». Удачи, у нас есть первый репозиторий!

Что произойдет, если мы не добавим README и .gitignore?

На самом деле ничего страшного не произойдет, но вам еще предстоит сделать несколько шагов.инициализироватьgit перед началом работы с ним.

Итак, мы создали репозиторий на удаленном сервере, теперь пришло время «схватить» его на нашей локальной машине и внести некоторые изменения.

Чтобы получить репозиторий, его нужно клонировать командойgit-клони путь к репозиторию.

Сначала получите путь к репозиторию.

Теперь заходим в консоль, идем в директорию куда хотим сохранить проекты и выполняем(git@github.com:ifireiceya/MiPrimerRepo.gitэто путь, который мы скопировали ранее):

$ git clone git@github.com:ifireiceya/MyFirstRepo.gitКлонирование в MyFirstRepo...remote: перечислить объекты: 4, done.remote: подсчитать объекты: 100% (4/4), done.remote: сжать объекты: 100% (4/4), готово. Удаленный: всего 4 (дельта 0), повторно использовано 0 (дельта 0), упаковка повторно использована 0 Получено объектов: 100% (4/4), выполнено.

Давайте перейдем в новый каталог, в котором теперь есть копия нашего проекта GitHub:

$ cd MiPrimerRepo

Мы можем увидеть, что уже находится в этом каталоге:

$ ls -a.git ЛИЦЕНЗИЯ ЧТЕНИЕ.md

Мы видим два семейных файла,ЛИЦЕНЗИЯмиLÉAME.mdи скрытый каталог .git.

ЭМ.gitМетаинформация и вся история проекта сохраняются. Для каждого проекта существует только один каталог..gitи является корнем проекта.

$ls .gitHEAD # указатель на конфигурацию вашей активной ветки # персональная конфигурация для описания проекта # описание ловушек проекта # hooksindex до/после действия # записи файла индекса # история веток проекта (где они были) объекты # ваши объекты (коммиты, теги , и т.д.) pack-refs refs # Указатели на ваши ветки разработки

Давайте немного настроим Git. Вам нужно сделать это только один раз, затем настройки будут сохранены, но при необходимости вы сможете изменить их.

Добавлена ​​утилита при установке Gitgit конфигурация, что позволяет просматривать и изменять большинство настроек Git. Говорим ли мы о пользовательских данных или о том, как работает репозиторий,git конфигурацияЭто самый удобный способ настройки.

Настройте имя пользователя и адрес электронной почты. Эта информация важна, потому что она включена в каждый коммит.

Итак, в терминале перейдите в репозиторий Git, для которого мы устанавливаем настройки, и запустите:

$ git config user.name "Дарья Меленцова"$ git config user.email iffireice@example.com# Если вы добавите параметр --global, эти настройки будут сохранены в конфигурации пользователя и применены ко всем проектам. # Мы запускаем эту команду без параметра --global, чтобы настройки применялись только к вашему проекту.

Для дальнейшей настройки параметров используйтеgit конфигурация, Лилоэта документация.

вносить изменения

Теперь нам нужно внести изменения в проект. Но перед этим рассмотрим две полезные команды:

• статус git- показывает текущий статус файлов в репозитории (какие файлы были изменены, удалены, добавлены);

• журнал git- показывает историю изменений (это зафиксированные изменения, то есть коммиты).

Давайте запустим эти команды и посмотрим, что они сгенерируют для нашего репозитория.

мы въезжаемстатус git:

$ git status В ветке mainВаша ветка обновлена ​​с помощью «origin/main». Нечего подтверждать, очистить дерево работ

И мы видим, что у нас нет никаких изменений. Вы говорите, что «в репозитории нет коммитов». Конечно, мы успели только клонировать репозиторий и еще ничего не сделали.

Давайте попробуемжурнал git, показывая, что в проекте был только одинпервое подтверждение- если мы создадим репозиторий сLÉAME.md:

$ git logcommit 9ae1cbcc77f3b64d604612d4a599bdbb8b1cf204 (HEAD -> main, origin/main, origin/HEAD) Автор: ifireiceya <117034707+ifireiceya@users.noreply.github.com> Источник: 31 сентября, 00:01:05 2022 +0300 Подтвердите инициал FIM)

Мы гарантируем отсутствие неучтенных изменений. Пора что-то делать!

Откройте ваш любимый текстовый редактор и создайте новый файл с именемhw.py.

Это будет небольшая программа на Python, которая при запуске скажет «Hello world!» (внезапно):

$ vi hw.pyprint("Привет, мир!")

Отлично, код пишется и даже хранится локально в нашем репозитории (все делаем в каталоге проекта).

Теперь наша задача сохранить изменения в «исходном» (удаленном) репозитории. Для этого вам нужно:

1. Отправьте новый файл в Git, т.е. добавьте файл в индекс:добавить git.

2. Фиксировать (фиксировать) изменения -Зафиксировать Git.

3. Синхронизировать изменения с сервером -git push.

4. Просмотрите репозиторий и убедитесь, что все работает.

Давай сделаем это!

файл появилсяhw.pyно он красный. Паника! Все сломано?

Нет, все идет по плану, но прежде чем продолжить, стоит посмотреть на состояние файлов с точки зрения Git.

Согласно Git, файл может находиться в одном из четырех состояний:

1. Без отслеживания (без отслеживания).

2. Modified — файл, который был изменен, но еще не добавлен в фиксацию (не зафиксирован).

   (Video) Git - для новичков - #1 - основы

3. Просканировано (подготовлено): файл, добавленный в индекс.

4. Фиксированный — файл уже хранится в локальной базе данных, и с момента последней фиксации не было внесено никаких изменений.

В отношении состояния файлов используются три основных раздела проекта:

• рабочий каталогэто каталог, который содержит то, над чем вы сейчас работаете, или то, что вы только что вытащили из истории проекта. Рабочий каталог — это временное место, где вы можете изменять, а затем отправлять файлы.

• зона подготовкиэто индексный файл в каталоге Git, который содержит информацию о том, что будет включено в следующую фиксацию.

• каталог git- место, где Git хранит метаданные вашего проекта и объекты базы данных. помнить больше о.git?

Что происходит на практике

Добавляем новый файлhw.pyи мы видим, что у него есть состояниене отслеживается, что означает, что независимо от того, что мы делаем с файлом, Git игнорирует любые изменения в нем.

Чтобы Git отслеживал изменения в файле, его необходимо добавить в индекс.

Для этого воспользуемся командойgit добавить <имя файла>.

Кстати, вы заметили, что Git довольно прост в использовании и часто запрашивает команды для запуска?

$ git add hw.py# Если вам нужно добавить много файлов и вы не хотите их описывать, вы можете использовать команду # git add .#, но вам нужно точно понимать, что мы добавляем, иначе я позже придется отсортировать индексные файлы, чтобы удалить их, кстати, для удаления используется команда git rm, но перед ее использованием стоит прочитать документ

И не забудьте файл ..игнорировать.git, в котором перечислены папки и файлы в репозитории, которые Git не должен сканировать и синхронизировать (не индексировать). Как правило, добавляются файлы журналов, выходные данные сборки и многое другое. поддерживаетмодели. Кстати, .gitignore — это тоже файл, который нужно добавить в индекс.

• Если файл соответствует правилам.игнорировать.git, поэтому он не появляется встатус git.

• Когда файл был добавлен в индекс и правило было добавлено к файлу в.игнорировать.git- Файл по-прежнему отслеживается и должен быть явным.гаситьиндексы.

Посмотрим, как изменилось состояние нашего файла:

Давайте зафиксируем изменения, потому что наша работа выполнена: мы написали программу на Python и хотим сообщить Git, что мы закончили работу с файлом и нам нужно запомнить его текущее состояние.

Для этого нужно закоммитить файл с помощью командыЗафиксировать Git.

При создании коммита его обычно описывают кратко и лаконично с ключом-МЕТРО:

$ git commit -m «добавить python hello world» [main 6d8a5c3] добавить python hello world 1 файл изменен, 1 вставить (+) режим создания 100644 hw.py

Несколько слов о написании сообщений фиксации:

• максимум 50 символов;

• намеренно и четко, как будто вы пишете для человека, которому нужно понимать, что происходит внутри коммита;

• сообщение должно начинаться с заглавной буквы;

• Если вы изменили код, пожалуйста, включите исходный код в сообщение.

$gitlog

$ git pushObject count: 100% (4/4), готово. Дельта-сжатие до 12 потоков Сжатие объектов: 100% (2/2), выполнено. Запись объекта: 100% (3/3), 341 байт | 341,00 КиБ/с, готово. Всего 3 (дельта 0), повторно использовано 0 (дельта 0), пакет повторно использован 0 На github.com: ifireiceya/MyFirstRepo.git 9ae1cbc..6d8a5c3 main -> main

Рекомендуем проверить наличие наших изменений на GitHub. Заходим в репозиторий и смотрим на него.

Задача немного сложнее.

Это здорово, но мы не всегда создаем репозитории, и часто нам нужно добавить новые функции или исправления в существующий репозиторий или даже в чужой.

Например, у нас есть любимый проект с открытым исходным кодом, которому мы хотим принести пользу и закрыть некоторыепроизводство.

В образовательных целях мы используем репозиторий GitHub для этой статьи. Там нужно исправить найденную в статье опечатку. Например, вот эта опечатка.

Но мы сделаем это с точки зрения внешних пользователей в чужом репозитории.

Репозиторий хранится в ifireice/git, а изменения вносятся пользователем ifreice.

У пользователя ifireiceya нет доступа к ifireice/git, и ему приходится пробиваться через форк, то есть он должен сначала сделать копию этого репозитория для себя и разработать его у себя, а потом отправить пулл запрос к основному репозиторию.

Но один за другим. Сначала разветвляемся.

Откроется окно для создания новой ветки.

Владелец репозитория меняется (1) и может при желании изменить описание проекта.

Вы можете вносить изменения в свою собственную копию, и они вообще не будут отражаться в оригинальном репозитории.

Теперь мы клонировали репозиторий форка на нашу машину и продолжаем его развивать.

Мы просто будем работать немного по-другому, не так, как с нашим репозиторием.

В нашем репозитории мы работаем в веткеГлавныйи сохраните все изменения там.

И вот у нас есть большой проект и над ним могут работать одновременно несколько разработчиков. Чтобы разные изменения не смешивались и один разработчик не мешал другому, разработка ведется в разных независимых версиях веток продукта. Когда задание завершено, все изменения объединяются в главную ветку.

Мы клонировали репозиторий и создали отдельную ветку, где исправили опечатку:

$ git clone git@github.com:ifireiceya/git.git$ cd git# создать новую ветку и сразу переключиться на работу там $ git checkout -b fix-misprintПеремещено в новую ветку fix-misprint

Используйте команду, чтобы увидеть, какие ветки есть в проекте, а какая в данный момент активнаРамо Гит:

$ git branch* fix-misprint main# * Проверить текущую активную ветку

На самом деле практика работы с ветками распространена не только при разработке в чужих (сотруднических) репозиториях, к которым у вас нет доступа, но и в ваших собственных. Существуют различные стратегии выбора ветвей, но это не ново. Просто нужно знать, что ветки есть и с их помощью удобно развиваться.

Мы можем увидеть, что изменилось с момента последней фиксации, используя команду git diff (красный с «-» — это то, что было, зеленый с «+» — то, что стало):

$ git разница

$ git statusOn ветка fix-misprintChanges не подготовлена ​​для фиксации: (используйте git add <file>..., чтобы обновить то, что было зафиксировано) (используйте git restore <file>..., чтобы изменить изменения и отменить их в рабочем каталоге): ПРОЧТИ МЕНЯ. mdno Добавлены изменения фиксации (используйте "git add" и/или "git commit -a")$ git commit -am "Поправили опечатку"[fix-misprint 188caa7] Поправили опечатку 1 файл изменен, 1 push (+), 1 удаление ( -)$ git pushfatal: текущая ветка fix-misprint не имеет восходящей ветки. Чтобы отправить текущую ветку и установить удаленный восходящий поток, используйте git push --set-upstream origin fix-misprint

Ой смертельно. Читаем подсказку Git и запускаем:

$ git push --set-upstream origin fix-misprintObject перечисление: 5, готово. Количество предметов: 100% (5/5), выполнено. Дельта-сжатие до 12 потоков Сжатие объектов: 100% (3/3), полное. Объекты записи: 100% (3/3), 402 байта | 402,00 КиБ/с, готово. Всего 3 (Дельта 1), повторно использовано 0 (Дельта 0), повторно использовано пакетов 0 Удаленный: Дельта разрешения: 100% (1/1), выполнено с 1 локальным объектом. удаленный: удаленный: Создайте запрос на получение исправления опечатки на GitHub по адресу: удаленный: https://github.com/ifireiceya/git/pull/new/fix-misprintremote:To github.com:ifireiceya/git.git * [новая ветвь ] fix -misprint -> fix-misprintBranch «fix-misprint», настроенный на отслеживание удаленной ветки «fix-misprint» «источника».

Удачи!

Почему произошла фатальная вещь: простой Git push предполагает, что ветвь, которую отслеживает текущая локальная ветвь, уже существует на удаленном сервере. Наша ветка новая и создается только локально, поэтому нам нужно создать ее, указав--set-upstream.

Проверим, появилась ли ветка на GitHub.

Форк сделан, ветка подтянута, баг исправлен, осталось закоммитить изменения в оригинальный репозиторий.

Для этого мы создаем запрос на включение.

И мы увидим такую ​​картину.

(1) репозиторий, в который мы хотим добавить изменения. —сифуэго/мерзавец

(2) ветка, в которую мы хотим добавить изменения -Главный

(3) репозиторий, из которого мы хотим добавить изменения —ifireiceya/git

(4) ветка, из которой мы хотим добавить изменения -Главный

Наша работа завершена. Владельцы репозитория просматривают ваши изменения, принимают или предлагают вам добавить или отклонить изменения.

Мы предполагаем, что у нас все хорошо и что наши изменения приняты без лишних слов.

Как написано на странице отзыва:

На данный момент - все. Увидимся в следующих выпусках Git и далее.

Ты выучил

• Рассказываем о системах контроля версий

• Настроить GitHub

• Создал первый репозиторий и внес в него изменения.

• Узнайте о ветвях, разветвлениях и многом другом

• Он сделал первый пиар

Что НЕ было изучено

• конфликты

• Отменить изменения (перезапуск,реверсивный)

• Чтобы извлечь файл из другой ветки (сборщик вишни)

• Фукс

что еще почитать

• Отличная книгаProGitGenericName(доступно на русском и английском языках)

• Курс DevOps для эксплуатации и разработки

• магистральная разработка- Стратегия ветвления

• GitFlow- другая стратегия ветвления