Ультимативный гайд по Git & GitHub(PyCharm/Terminal)

2023-08-09T10:19:50.656Z

Время прочтения: 25 минут

Привет! Недавно я загорелся идеей изучить одну из систем контроля версий. Лишним точно не будет, к тому же я мог бы заливать открытый код своих проектов в репозиторий для общего доступа (и публикации в Кодим Крипту) — выбор пал на Git и GitHub, как Веб-сервис, основанный на Git.

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

Что ж, посидев несколько дней и наконец поняв, как все работает, я, в партнерстве со вторым админом канала решил написать ультимативный гайд по Git & GitHub, тем самым сэкономить вам кучу сил, времени и нервов.

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

Статья ориентирована на новичка, но даже если вы таковым не являетесь — не уходите, возможно вы почерпнете здесь что-то новое для себя. Новичок же получит ВСЮ необходимую базу для полноценной работы с Git на первых порах.

Первая Глава - Заядлый
Вторая Глава - Глеб
Авторы канала - Кодим крипту

Это наверное первый действительно всеобъемлющий гайд по Git & GitHub, который сможет понять даже твоя бабушка, Поехали!

Как читать эту статью?

Первая Глава нашей работы целиком и полностью посвящена работе с Git при помощи встроенного интерфейса PyCharm, но даже если вы не юзаете PyCharm - первая глава является обязательной к прочтению(хотя бы просто к прочтению, можно не повторять действия) для дальнейшего понимания материала и формирования в голове общего алгоритма работы с Git.

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

Внимательно будешь читать статью - найдешь тикет на 10 проходок в наш {Layer 1} чатик:)

- Установка Git
- ГЛАВА 1: Git & GitHub через PyCharm
База: 1.Создание проекта и запуск VCS
2. .gitignore
3. Начинаем отслеживать файлы
4.Первый Коммит
5. Просмотр изменений, откат
6.push
7. pull
Промежуточные итоги

Advanced LVL:
1. Клонируем проект
2. Установка venv
3. requirements.txt
4. Создаем новую ветку
5. Pull-request
6. Переход в master branch
Промежуточные итоги

- ГЛАВА 2: Git & GitHub через Terminal
База:
1. Настройка Git
2. Инициализация репозитория
3. Области Git
4. Статусы отслеживания файлов
5. .gitignore
6. Создание проекта
7. Первый Коммит
8. Второй Коммит
9. Перемещение между версиями
10. Ветки
11. Remote репозитории
12. Связь local и remote repository
Промежуточные итоги

Advanced LVL:
1. Слияние веток
2. Перемещение
3. Pull-request
Промежуточные итоги

- Заключение
- Приложение А: Git Справочник

Установка Git

Это первое, с чего стоит начать вне зависимости от того, какой из способов вы выберете(PyCharm/Terminal), все просто:

Скачайте клиент с официального сайта

Выбирайте свою разрядность системы

Выполните установку, не меняя никаких пунктов, кроме расположения(по желанию)

Готово!

ГЛАВА 1: Git & GitHub через PyCharm (by заядлый)

Дисклеймер: Вы вольны использовать любой веб-сервис с Git помимо GitHub, интерфейс везде +- один

Этот раздел посвящен работе с Git при помощи встроенного интерфейса PyCharm, если вы по какой-то причине кодите на питоне и до сих пор не используете PyCharm — то это как минимум странно. Одумайтесь.

Вообще PyCharm платный, но для работы с Git вам хватит и бесплатной версии (кстати если вы учитесь в тех. вузе, то вероятно, у Вашего университета уже приобретена лицензия на JetBrains, попробуйте)

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

1. Создание проекта и запуск VCS

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

Ничего не меняем, кроме расположения, жмем Create

Тут же для примера создадим отдельный модуль, чтобы на его примере увидеть работу Git:

Теперь давайте активируем Git!
VSC -> Enable Version Control Integration, в выпадающем меню выбираем Git

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

2. .gitignore

.gitignore - это специальный файлик, который содержит в себе имена других файлов, которые git не должен отслеживать, которые в последствие не попадут в GitHub репозиторий. Примеры таких файлов: логи, папка venv, .idea, приватники от кошельков..

Создается он во внешней папке проекта, ни в какие venv мы не лезем и ничего там не трогаем!

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

По умолчанию в .gitignore заносим две папки: /venv/ и /.idea/

Виртуальное окружение пользователь всегда сможет восстановить через requirements.txt(подробно в Advanced разделе), а .idea ему не к чему, это настройки вашей IDE.

3. Начинаем отслеживать файлы

Но в самом начале вам необходимо перейти в Settings -> Version Control -> Use non-modal commit interface, чтобы отобразить интерфейс как у меня.

В самом низу(как на картинке) есть вкладка git, переходим туда, разворачиваем папку Unversioned files - это те файлы, которые ждут своего добавления в отслеживание, а я напомню, чтобы Git начал трекать изменения в файлах, их нужно начать отслеживать(в терминале это команда add).

Действуем! Выбираем все файлы кроме .gitignore и тыкаем Add to VCS

Файлы должны стать зелеными и переместиться во вкладку Changes, теперь все изменения в этих файлах будут отображаться во вкладке Git в красивом интерфейсе

Note: если вы создаете новый файл, его также нужно добавлять в отслеживание

4. Первый Коммит

Начальная структура проекта готова, файлы отслеживаются - самое время сделать первое сохранение! Коммиты - это и есть сохранения, между которыми можно перемещаться в процессе работы.

Обычно первый коммит называют init

В поле Commit Message ваша задача в одну строчку описать, что произошло с проектом с момента последнего коммита, например вы добавили новый модуль, пофиксили баг и тд, первый же коммит по классике называют init

Итак, папка Changes должна очиститься, ведь коммит сделан и с тех пор мы не изменили ничего. Давайте изменим!

5. Просмотр изменений, откат

В файле math.py я немного изменю код, что безусловно должно отобразиться во вкладке git -> changes:

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

Если новый код протестирован, работает так, как ожидается, если вы его трижды проверили через show diff - то можно делать следующий коммит по аналогии с прошлым пунктом. Не забудьте добавить качественное описание к коммиту.

Историю коммитов можно смотреть во вкладке Log окна Git

Более того, если мы где-то накосячили, сломали код, всегда можно воспользоваться откатом - Rollback!

Оп! И вкладка Cnanges снова пустая, а код откатился к состоянию последнего коммита.

6. Заливаем в репозиторий GitHub(push)

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

Итак, можно поступить следующим образом:

Репозиторий автоматически создастся в привязанном гитхаб аккаунте.

Если репозиторий уже есть, или например вы просто внесли какие-то изменения в существующий проект у себя на пк, и их нужно залить в репозиторий, вы можете использовать эту кнопку:

тогда существующий репозиторий обновится в соответствии с вашим кодом!

В обоих случаях это выглядит примерно вот так:

Репозиторий на GitHub

Как видите, файлы из .gitignore не экспортировались

7. Подтягиваем проект из Репозитория(pull)

Допустим ваш друг решил модифицировать проект и добавил туда пару новых фич, для дальнейшей разработки вам нужно синхронизировать удаленный(репозиторий) и локальные(на твоем пк) проекты. Для этого есть команда pull, рассмотрим на примере:

В директории modules кто-то(я) добавил новый файл со своим кодом, естественно у нас на пк его нет, как подтянуть его к нам?

Переходим обратно в PyCharm и тыкаем синюю стрелку:

Ждем, ждем.. Готово! Можете проверять, test_file.py теперь и у вас на пк

Подтягивание изменений(pull) - обязательное ежедневное начальное действие перед началом работы с проектом, если вы работаете не один, вдруг за ночь ваш коллега что-то добавил/изменил?

Промежуточные итоги

Итак, во-первых, в течение всего урока я ни разу не открыл терминал, все делается при помощи встроенного интерфейса PyCharm, а во-вторых, базы, которая дана выше хватит для выполнения большинства повседневных задач!

Быстренько повторим алгоритм:
1) Создаем проект, включаем VCS
2) Создаем .gitignore
3) Добавляем папки в отслеживание
4) Коммитим
5) Пушим в репозиторий
6) Подтягиваем изменения, если условно за ночь кто-то изменил репозиторий

На этом можно было бы завершить первую главу гайда, но мы еще не рассказали про ветки, полноценную совместную разработку, клонирование и тд - Welcome to Advanced!

ADVANCED LVL

Advanced lvl - это для тех, кто планирует работать в команде, разрабатывать проект, задействуя ветки, или для тех, кто просто хочет копнуть в работу с git чуть глубже. Мы рассмотрим:

Клонирование проекта
Установку виртуального окружения
Установку зависимостей
Создание новых веток
Слияние веток и pull request

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

1. Клонируем проект

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

На картинке я взял только что созданный репозиторий Глеба, чтобы добавить туда пару новых модулей, жмем Code -> Local -> HTTPS -> копируем ссылку

Идем в PyCharm, закрываем текущий проект, во вкладке с проектами выбираем Get from VCS и вставляем ссылку, проект склонирован!

Но это еще не все! Если проект использует какие-то сторонние библиотеки, у вас код не запустится, ведь либы находились в папке venv, которую в GitHub не экспортируют. Обязательно ищем файл README.md и изучаем содержимое, только потом переходим к следующему пункту.

2. Установка виртуального окружения

Как неоднократно упоминалось выше, при клонировании/импорте проекта, виртуальное окружение не создается, IDE, конечно, может нам предложить создать его, но чаще всего приходится делать все ручками, давайте сделаем!

Идем в настройки:

Project: name -> Python Interpreter:

Добавляем локальный интерпретатор:

Новое виртуальное окружение:

Готово! Остается установить в папку venv необходимые зависимости из папки requirements.txt если таковая имеется

3. Установка зависимостей(`requirements.txt`)

Если клонированный проект использует какие-то сторонние библиотеки, например web3, aiogram и тд, вы обязательно о них узнаете, когда найдете файл requirements.txt, его необходимо "установить":

Тут все просто, IDE сама предложит нам установить зависимости, не противимся и жмем install requirements:

Ждем несколько секунд.. Готово! Можно работать с проектом.

Note: снизу есть небольшой прогрессбар, на котором обычно отображаются все сетевые процессы, например установка библиотек, push в репозиторий и тд

4. Создаем новую ветку

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

Теоретический пример: Мы с Глебом работаем над созданием бота в TG, мы делим задачи между собой и в один момент я решил поручить Глебу реализовать авторизацию в боте.

Глеб идет и создает отдельную ветку, называя ее к примеру: auth. Она изначально является копией мастер ветки. Далее реализовывает функционал, проверяет все, комиттит и пушит в репозиторий.

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

Если ревью пройдено ветка Глеба и master ветки сливаются(мержатся) в одну, то есть изменения ветки Глеба вносятся в master(основную) ветку

Еще раз, master ветка - это то, что видит конечный пользователь продукта, поэтому она всячески защищена от шальных изменений.

А теперь по порядку, создадим ветку!

Ветка должна смениться с main(или master) на только что созданную. Ветка создана!

5. Pull-request

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

Для начала, я, конечно же, все проверяю и делаю коммит. Если задача в целом реализована - то вы можете сразу же сделать push, нажав кнопку commit and push:

На странице GitHub отобразится специальное окно, говорящее вам о том, что вам нужно создать pull request -это запрос к другим участникам проекта с просьбой посмотреть ваш код, проверить на работоспособность и правильность, вам могут выносить замечания, которые вы должны будете исправлять, а также могут сразу принять ваш реквест, тогда ваша ветка автоматически сольется с основной

Note: в ряде случаев, для мерджа необходимы "одобрения" нескольких членов команды, в виде лайков. Если набралось определенное кол-во, например 2, ваш код автоматом сливается

Создаем pull request!

Примерно так это выглядит, когда Глеб зайдет и проверит мой код(это его проект), мои изменения автоматически отобразятся в репозитории.

Как видите тут есть вкладки с коммитами, подобие show diff и многое другое.

Итак, изменения приняты, master ветка обновлена, что дальше?

6. Удаление ветки и переход в master branch

Вероятнее всего, после мержа веток ваша ветка будет удалена, но удалена удаленно, то есть у вас на ПК она останется. Что делаем?

Для начала нам нужно перейти на master ветку:

Но это лишь старый вариант ветки, ведь она была изменена, подтягиваем изменения(pull):

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

VSЁ! И так по кругу! Пришел новый таск, создали новую ветку, реализовали функционал, закоммитили, вызвали pull requiest, залили изменения в master ветку..

Промежуточные итоги

Итак, в рамках Advanced LVL вы должны были научиться работать в команде используя Git и Pycharm не написав ни единой строчки кода в терминале! Теперь вы можете разрабатывать единый проект вместе с вашим товарищем, удобно делить задачи и не мешать друг другу!

На этом я(Заядлый) с вами прощаюсь, передаю перо Глебу, чтобы он рассказал вам о том, как работать с Git через терминал(не дай бог), ситуации бывают разные, например слабое железо для PyCharm..

ГЛАВА 2: Git & GitHub через Терминал / (by глеб)

Всем привет, в этой главе я(Глеб) познакомлю вас с командами git и научу создавать ваш первый репозиторий именно через терминал!

Почему важно уметь работать с Git в терминале?

В первую очередь - это практика, которая является самым важным базисом в программировании.
Банальный базовый инструмент, которым должен владеть каждый пользователь.
Возможности командной строки - выполнение любых изменений, проверка и устранение любых неисправностей, тестирование кода, проверка логов системы и безопасности и многое другое.
Четкая последовательность действий. Используя командную строку вы всегда получаете однозначный ответ, отслеживаете порядок действий и управляете абсолютно всеми командами.
Минимальные затраты системных ресурсов для работы по сравнению с IDE(вдруг у вас PyCharm не тянет)

Что вам нужно для начала:

Установленный Git
Аккаунт на GitHub
Командная строка

1. Первоначальная настройка Git

Note: Некоторые команды у меня могут отличаться от ваших, если вы работаете не на Windows, гуглите

Открываем Terminal и проверяем установленный Git и его версию с помощью команды git -v

самая актуальная версия на момент написания статьи

Настраиваем имя и привязываем ваш Git к аккаунту на GitHub:

git config --global user.name "ваше имя"

git config --global user.email ваша почта аккаунта GitHub

Опция --global значит, что имя и почта будут использоваться для всех ваших действий в Git.

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

2. Инициализация нового репозитория

Для начала нам необходимо создать папку, где будут хранится все наши проекты. Сделать это можно с помощью команды mkdir название папки
Переходим в только что созданную папку с помощью cd название папки
Прописываем команду git init

В командной строке вы должны увидеть результат создания репозитория

Проверить новую папку можно с помощью cd .git

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

3. Области Git

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

демонстарция процессов перехода отслеживания объектов

Working directory - файловая система вашего компьютера.
Staging area(индекс) - область подготовленных файлов, хранит содержание следующего коммита.

3. Repository - хранит все версии файлов вашего проекта и ваши коммиты.

4. Статусы отслеживания файлов

При работе в терминале и в частности для написания коммитов, нам необходимо понимать в каком статусе находится файл. Чтобы увидеть состояние файлов, напишите в консоли git status

Файлы и коммиты мы еще не добавляли

untracked - новые файлы в рабочей директории, нет в области staging area и repository.
staged - файлы, которые подготовлены для сохранения изменений и находятся staging area.
unmodified - файлы синхронизованы между working directory и repository, файл имеет самую актуальную версию во всех разделах.
modified - файлы, находящиеся в рабочей директории, где находится более новая версия файла по сравнению с хранящейся в репозитории или в индексе.

Чтобы посмотреть сами изменения, а не изменённые файлы, можно использовать следующие команды:

git diff - сравнение рабочей директории с индексом.
git diff --staged- сравнение области индекса с репозиторием.

5. .gitignore

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

Игнорируемые элементы отслеживаются в специальном файле .gitignore, который регистрируется в корневом каталоге репозитория. В Git нет специальной команды для указания игнорируемых файлов: вместо этого необходимо вручную отредактировать файл .gitignore, чтобы указать в нем новые файлы, которые должны быть проигнорированы. Файлы .gitignore содержат шаблоны, которые сопоставляются с именами файлов в репозитории для определения необходимости игнорировать эти файлы. Для того, чтобы легче воспринять этот материал, я советую зайти на данный сайт и просмотреть все шаблоны

Для игнорирования закомиченного файла, для которого ранее был сделан коммит, необходимо удалить этот файл из репозитория, а затем добавить для него правило в .gitignore . Используйте команду git rm с параметром --cached, чтобы удалить этот файл из репозитория, но оставить его в рабочем каталоге как игнорируемый файл.

6. Создание файлов и папок в проекте

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

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

Переходим в терминал и заходим в ранее созданную папку под проекты, где хранится наш созданный репозиторий.
Для создания файла в терминале введите: echo "текст" > название файла.txt

Создали файл и проверили его наличие в папке

Текст файла можно прочитать с помощью команды type

Теперь создадим папку и пару дополнительных файлов в ней для наблюдения их состояний. Для создания файлов используем команду echo "текст" > название файла.txt, а для создания папки используем mkdir название папки

Создал папку и в ней создал 3 новых текстовых документа

В итоге мы получили 1 папку с 3 файламми и 1 файл, который лежит в корне проекта

Вид в проводнике

Теперь мы можем проверить статус наших файла с помощью команды git status

Папка и файл имеют статус "untracked"

Таким образом мы наполнили наш локальный репозиторий и можем приступать к коммитам.

7. Создание первого коммита

Для написания первого коммита необходимо подготовить файлы и перенести их в индекс.

Добавим файлы Codimcrypty.txt и Admins.txt в индекс с помощью команды git add

подготовленные файлы для commit

Напишем наш первый коммит для этих файлов с помощью команды git commit -m "текст"

Изменения 2 файлов и добавление 2 новых строк

Каждый коммит содержит уникальную контрольную сумму - идентификатор/хеш, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит, увидеть это можно с помощью команды git log

Показывает хеш, дату, автора и сам коммит

Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта.

Git распределяет все объекты по папкам и подпапкам исходя из хеша и найти эту папку можно по первым двум символам хеша. Для этого необходимо перейти в скрытую папку .git и objects и далее выбрать нужную вам папку.

в моем случае это папка 6b

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

8. Написание второго коммита

Создадим новую папку, добавим туда файл, добавим их в индекс и напишем второй коммит для практической наглядности перемещения между версиями проекта.

новая папка KurimKrypty

Дали второй коммит новому файлу в новой папке

9. Перемещение между версиями

Чтобы переместиться между версиями проекта нам прежде всего необходимо перемести указатель HEAD на первый коммит.

Для этого скопируем часть хеша нашего первого коммита и пропишем команду git checkout часть хеша

как видим HEAD успешно переместился

Введем команду dir для просмотра всех объектов папки и можем заметить отсутствие недавно созданной папки KurimKrypty. Это произошло из-за возврата на 1 версию нашего проекта и Git изменил содержимое рабочей директории.

HEAD ссылается на коммит а не мастер ветку

Для возврата на master ветку используем команду git checkout master

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

10. Ветки в Git и работа с ними

Ветка - ссылка на коммит

Ветвление - это возможность работать над разными версиями проекта. Вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках. Каждая ветвь содержит указатель HEAD на последний коммит, что позволяет без лишних затрат создать много веток. Ветка по умолчанию называется master/main.

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

Команды для работы с ветками

git branch имя ветки - создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент <имя ветки>, то команда выведет список всех локальных веток.
git checkout имя ветки - переключается на эту ветку. Можно передать опцию -b, чтобы создать новую ветку перед переключением.
git branch -d имя ветки - удаляет ветку.
git branch - отображает список всех ветвей в локальном репозитории.
git branch -m новое имя ветки - переименовывает текущую ветку.

Cоздал новую ветку и переключился на нее

11. Удаленные репозитории

Чтобы иметь возможность совместной работы над каким-либо проектом, необходимо знать как управлять удалёнными репозиториями. Удалённые репозитории - репозитории, хранящиеся на сервере. Я использую Github, как самую распространённую и удобную платформу и все мои будущие проекты будут публиковаться именно там.

При использовании команды git remote url репозитория мы добавляем удаленный репозиторий, который находится по указанному адресу и которому присваивается имя origin.

Origin - имя удаленного репозитория по-умолчанию.

Наиболее употребляемые команды:

git remote add имя url - добавляет удалённый репозиторий с заданным именем.
git remote remove имя - удаляет удалённый репозиторий с заданным именем.
git remote rename старое имя новое имя - переименовывает удалённый репозиторий.
git remote set-url имя url - присваивает репозиторию с именем новый адрес;
git remote show имя- показывает информацию о репозитории.

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

12. Связь локального репозитория с удаленным

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

Переходим в наш ранее созданный аккаунт GitHub и переходим в раздел создания нового репозитория.

Создаем новый пустой репозиторий, выбираем название проекта и настраиваем под себя

Я ничего не менял

Пролистываем создавшийся репозиторий вниз до указаний о пуше через терминал

Нам нужны эти 3 строки

git remote add origin - добавляет удаленный репозиторий.
git branch -M main - рекомендация от GitHub по названию главной ветки.
git push -u origin main - загрузить изменения с локального на удаленный.

Результат выполнения в терминале

Результат на GitHub

Промежуточные итоги

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

Справочник по git командам

Тут собраны самые основные и наиболее часто используемые git команды в алфавитном порядке

git add - добавляет файлы в индекс git.
git archive - создает архив из ветки.
git bisect - бинарный поиск коммита, который привел к ошибке.
git branch - работа с ветками: просмотр, создание, удаление.
git bundle - позволяет упаковать в бинарный файл то, что было бы отправлено в репозиторий с помощью git push.
git checkout - переключает нас на разные ветки репозитория и восстанавливает файлы в рабочей ветке (приводит содержимое в соответствие с удаленным репозиторием). Также позволяет создать новую ветку.
git cherry-pick - из нескольких коммитов собирает один и применяет его в текущей ветке.
git clean - удаляет файлы, которые не отслеживаются в репозитории.
git clone - команда клонирует репозиторий в новую директорию.
git config - команда позволяет работать с настройками репозитория, читать их или задавать новые значения опциям.
git commit - добавляет описание к файлам.
git diff - сравнение содержимого (фиксами, деревьями и так далее).
git fetch - скачивание объектов и ссылок из другого репозитория. Обратите внимание, что данная команда скачивает только информацию об изменениях, но не сами файлы.
git gc - чистка репозитория от устаревших и временных данных.
git gui - портативный графический интерфейс к Git.
git init - команда используется для инициализации проекта, как репозитория git.
git log - показывает журналы коммитов.
git merge - объединяет ветки.
git mv - перемещает или переименовывает файл.
git notes - создать примечание для объекта.
git pull - скачиваем файлы из другого репозитория.
git push - отправляет файлы на сервер.
git rebase - слияние веток с заменой всех коммитов на один единственный. В итоге мы получаем ветку, которая, как будто, только что была создана заново.
git reset - сбрасывает состояние изменений для текущей ветки. Позволяет без объединений заменить файлы при выполнении git pull.
git restore - восстановление файлов рабочего дерева. А именно, приводит содержимое в соответствие с удаленным репозиторием.
git remote add - команда используется для добавления или подключения к удаленному репозиторию.
git remote -v - команда используется для просмотра подключенных удаленных репозиториев.
git rm - удаляет файлы из ветки и индекса.
git shortlog - выполняет группировку всех коммитов по автору.
git show - показывает объект в удобочитаемом виде.
git status - команда используется для просмотра статуса файлов в вашем локальном репозитории.
git switch - позволяет переключаться между ветками.
git tag - работа с тегами.
git worktree - управление несколькими рабочими ветками.

ADVANCED LVL

В моей части, advanced level представляет из себя знания, которые упростят вам работу с гитом и его функциями, но не являются первостепенными для создания первого проекта. Читайте, набирайтесь опыта и задавайте вопросы в L1 чате.

1. Слияние веток

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

Слиние, включает в себя создание нового коммита, который основан на общем коммите - предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов.

Feature branch(тематическая ветка) - ветка из которой мы переносим готовый

Receving branch(основная ветка) - ветка в которую мы сливаем изменения

Для слияния мы переходим на основную ветку и используем команду git merge <тематическая ветка>.

2. Перемещение

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

Для перемещения используется команда git rebase <основная ветка> <тематическая ветка>, которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Проблема перемещения

После слияния log с историей может выглядеть довольно беспорядочно, а перемещение позволяет переписать историю в нормальной, последовательной форме. Но перемещение — не всегда выход от запутанных логов: перемещённые коммиты отличаются от оригинальных, хотя и имеют одного и того же автора, сообщение и изменения.

Вот пример:

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

Перемещайте изменения только на вашей приватной локальной ветке - не перемещайте коммиты, от которых зависит ещё кто-то.

3. Работа с pull request

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

Пример пул реквеста от Жени в мой проект

Любой пул реквест мы можем одобрить или отклонить, если у него есть проблемы в коде, коммите и т.д. Если вы и дальше работаете в той же ветке, а пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название текущей ветки.

Про создание пул реквеста а GitHub и как это выглядит со стороны, вы уже увидели у Жени, а я перейду к структуре пулл реквеста.

Структура запроса pull

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

Промежуточные итоги

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

Я, надеюcь, вы узнали для себя кое-что новое из этой главы и научились работать с Git через консоль. Выражаю огромную благодарность за прочтение этой статьи и желаю вам успехов в разработке!

ЗАКЛЮЧЕНИЕ

В целом, для работы с Git совсем не зазорно использовать терминал, но только представьте, что человек платит за лицензию PyCharm или любой другой крутой IDE и по итогу все, чем он пользуется - это зеленая кнопка run, чтобы не утруждать себя запуском приложения из консоли:) Это глупо, и не разумно, остановитесь и выделите хотя бы немного времени на то, чтобы разобраться со средой, в которой работаете.

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

Цель этой статьи: помочь каждому, кто давно хотел работать с Git, начать, и замотивировать тех, кто до этого считал системы контроля версий - ненужной тратой времени.

— Я считаю, что цель вы выполнили. Спасибоу!

Обещанные 10 тикетов в {Layer 1}: https://t.me/+6qxiOTYaOEA4NTcy

Заядлый

Ультимативный гайд по Git & GitHub(PyCharm/Terminal)

Как читать эту статью?

Навигация

Установка Git

ГЛАВА 1: Git & GitHub через PyCharm (by заядлый)

1. Создание проекта и запуск VCS

2. .gitignore

3. Начинаем отслеживать файлы

4. Первый Коммит

5. Просмотр изменений, откат

6. Заливаем в репозиторий GitHub(push)

7. Подтягиваем проект из Репозитория(pull)

Промежуточные итоги

ADVANCED LVL

1. Клонируем проект

2. Установка виртуального окружения

3. Установка зависимостей(requirements.txt)

4. Создаем новую ветку

5. Pull-request

6. Удаление ветки и переход в master branch

Промежуточные итоги

ГЛАВА 2: Git & GitHub через Терминал / (by глеб)

1. Первоначальная настройка Git

2. Инициализация нового репозитория

3. Области Git

4. Статусы отслеживания файлов

5. .gitignore

6. Создание файлов и папок в проекте

7. Создание первого коммита

8. Написание второго коммита

9. Перемещение между версиями

10. Ветки в Git и работа с ними

Команды для работы с ветками

11. Удаленные репозитории

12. Связь локального репозитория с удаленным

Промежуточные итоги

Справочник по git командам

ADVANCED LVL

1. Слияние веток

2. Перемещение

3. Работа с pull request

Структура запроса pull

Промежуточные итоги

ЗАКЛЮЧЕНИЕ

3. Установка зависимостей(`requirements.txt`)