Про Git, Github и Gitflow простыми словами
Не самое исчерпывающее, но точно вполне доходчивое руководство по Git, Github и Gitflow – для тех, кого эти слова смущают, хотя не должны.
Если вы не поняли Боромира, значит, зашли по адресу. С системами контроля версий должен уметь работать любой программист, даже если вы только учитесь.
Контроль версий помогает не только избежать досадных косяков при внесении изменений, но и необходим для командной работы над проектом. В этом материале мы рассмотрим основные команды для консоли и разберем самую популярную модель управления ветками проекта. И про ветки тоже поговорим.
Git – это распределенная система контроля версий (version control system – VCS).
Контроль версий означает что вы храните все версии редактируемых документов и можете вернуться к любой сохраненной версии в любой момент времени. Кажется, будто такой подход популярен только среди программистов, но на деле им пользуются, например, дизайнеры и другие люди, несколько более подкованные технически, чтобы контролировать изменения в работе.
Распределенность git’а отличает его от прочих vcs. Под распределенностью следует понимать, буквально, возможность использования одной системы контроля на проекте множеством разработчиков.
К слову, Git создал вот этот обходительный джентельмен:
Линус Торвальдс, создатель Git и Linux, передает привет Nvidia
С чего начнем?
Для начала, убедитесь, что у вас установлен Git.
Теперь, все что нам понадобится, чтобы создать репозиторий, это команда git init в нужном каталоге.
Откройте командную строку, и перейдите в Desktop (да, будем оригинальны), а там создайте каталог (например, proglib).
Теперь, проходим в новый каталог и выполняем git init.
Все, у нас есть пустой репозиторий.
Добавление файлов
Давайте создадим простой README.md файл, что-то вроде:
git status – простая команда, которая будет регулярно использоваться. Она показывает информацию о статусе проекта в git. Если вы выполните ее в каталоге proglib, будет видно, что файл README.md не отслеживается git’ом.
Если выпонить git status еще раз, мы увидим, что теперь в системе появился новый файл, который мы добавили.
Коммитим изменения
Чтобы закомминтить изменения в локальный репозиторий, просто напишите в командной строке:
Разумеется, в сообщении можно указать что угодно. Но пожалуйста, сделайте себе одолжение, и пишите вразумительные и ясные комментарии.
Пушим в удаленный репозиторий
Мы будем пушить изменения на Github, так что если у вас вдруг нет аккаунта, создайте его.
Нажмите кнопку Start a project и задайте проекту имя, остальные настройки можно оставить по умолчанию.
Ветки
Git делает ветвление очень простым. Допустим, мы находимся в мастер-ветке и хотим дописать функционал, основываясь на коде из этой ветки. Для этого нужно всего лишь написать команду для создания дополнительной ветки и провести всю работу там. А как закончите, замерджить (то есть, слить ветки) все обратно в мастер.
Внесите изменения в ваш README.md, сохраните их и используйте следующие команды, чтобы закоммитить изменения и замерджить их в мастер:
Теперь, когда вы знаете насколько просто работать с ветвлением, вас не удивит, что у многих людей своеобразный подход к управлению ветками.
Но есть один подход, который популярен в сообществе. Знакомьтесь, популярная модуль управления ветками Gitflow:
Схема выглядит беспорядочно, когда видишь ее впервые, так что пойдем по порядку. У нас есть две основные ветки: master и develop.
В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.
Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.
Далее, у нас есть ветка release, которая используется для подготовки к новому релизу проекта.
Наконец, есть ветка hotfix, которая служит для срочного исправления багов, найденных, например, на продакте.
Вот как в теории, происходит рабочий процесс в Gitflow:
1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop
8. Кроме того, этот момент можно отметить на master-ветке
Gitflow как инструмент
Проделаем описанное выше шаг за шагом, но для начала убедитесь, что у вас есть gitflow-avh – инструмент для работы с Gitflow. На маке его можно установить с помощью homebrew:
gitflow-avh – это коллекция расширений для git, которая помогает избежать многих повторяющихся операций и вообще делает жизнь проще (это не точно). К примеру, при работе с feature-веткой, утилита проверит, слилась ли она в develop и удалит ее, если все прошло хорошо. Конечно, можно следовать модели Gitflow и самостоятельно, делая операции руками, но ведь проще же использовать готовое решение, так?
Как условие для начала работы, нам нужен git репозиторий. Если вы не начали читать статью с этого места, то у вас один уже есть. Теперь выполним команду git-flow init, как для git.
Далее будет несколько вопросов, но если оставить опции по умолчанию, эта команда просто создаст и назовет ветки в соответствие с моделью Gtiflow.
Когда все закончится, вы увидите, что находитесь на ветке develop. Теперь, создадим новую feature-ветку:
Затем, откроем README.md и внесем изменения. После, сделаем коммит:
Теперь, если мы всем довольны, закончим с этой веткой:
Как можно видеть в выводе в консоли, эта команда сделала следующее:
1. Слила ветки new_docs и develop
2. Удалила new_docs
3. Выполнила переход на ветку develop, чтобы можно было продолжать работу
Допустим, новая фича нас устраивает, она оттестирована и работает исправно. Теперь нам нужно сделать релиз.
Для начала, необходимо выполнить команду:
Здесь можно внести любые последние потенциальные исправления, обновить версию (имеет значение при разработке мобильных приложений) и так далее.
Когда работа закончена, просто напишем:
Вам нужно будет добавить несколько сообщений и меток, а потом утилита сделает следующее:
1. Сольет release и master
2. Пометит release как 2.0
3. Сольет release и develop
4. Удалит release
5. Выполнит переход на develop
Совместная работа
Иногда совместная работа напоминает классику:
На гитхабе вы можете добавить кого-то, кого вы знаете в сотрудники в настройках Settings-Collaborators. Приглашенные таким образом участники получат разрешение пушить в ваш репозиторий или вы можете создать команду разработчиков и регулировать уровни доступа от проекта к проекту.
Но даже если вы хорошо знаете человека, вам не всегда может понравится, что кто-то делает коммиты в мастер без вашего ведома. Для таких случаев в github сущестуют pull-request’ы и code review.
Работает это следующим образом: вы делаете какое-то улучшение или фикс на featire-ветке, делаете pull request, кто-то из старших разработчиков, курирующих проект смотрит ваш код (читай, делает code review), возможно, делает какие-то замечания и, в конечном итоге добавляет ваш код в мастер-ветку (или куда-то еще).
Выглядит неплохо, НО
На деле отношение к код ревью может быть разным. Буквально, от
И как же к относится к code review? Конечно, это очень важная штука и нужно иметь терпение и делать ревью всех пул реквестов, если речь идет о вашем проекте, например. В долгосрочной перспективе это окупится. И, конечно, легко сказать «just do it», но в некоторых случаях сложившиеся традиции в команде разработчиков могут заставить пересмотреть свое отношение к некоторым вещам.
Проверяем на практике
Создадим новую feature-ветку:
Повторим процесс изменения документа и создания коммита.
А теперь сделаем кое-что новенькое:
То есть, отправим пул-реквест. Если зайти на гитхаб, можно его увидеть.
Теперь, нажмите кнопку Compare & pull request:
Здесь можно добавить комментарий к пул-реквесту.
На этом моменте, кто-то из вашей команды должен прийти и проверить ваш код. Вы даже можете дать об этом знать кому следует через инструмент управления проектом, которым ваша команда пользуется (JIRA, Trello, Leankit, Kanbanflow, etc) добавив таск/карточку в соответствующую колонку.
Когда пул-реквест будет подтвержден, вы как автор, должны сделать следующее:
Вы увидите, что Github закрыл пул-реквест и удалил ветку.
И как бы то ни было, не стесняйтесь делать пул реквесты, если вам кажется, что ваш код недостаточно хорош: идеального кода не бывает.
Git. Коротко о главном
Cодержание:
4. Самые распространенные команды в Git;
5. Работа с историей;
7. Примеры ведения истории проекта;
Введение
Привет, Хабр! Меня зовут Егор, я занимаюсь разработкой мобильных приложений на Flutter. Это моя первая работа в сфере IT, и как подобает начинающим, я столкнулся с проблемой изучения систем контроля версий. В данной публикации я хочу поделиться приобретенными знаниями и подробно рассмотреть одну из таких систем, а именно Git. Итак, начнем.
“Whoah, I’ve just read this quick tuto about git and oh my god it is cool. I feel now super comfortable using it, and I’m not afraid at all to break something.” — said no one ever.
Не так страшен чёрт, как его малюют. Хотя, как мне кажется, это не касается Git. Так или иначе многие сталкиваются с необходимостью обучиться грамотной работе с этим инструментом. Несмотря на обилие информации и туториалов, это задача является не самой тривиальной. Исходя из своего опыта, могу сделать вывод: необходимо изучить самые разные ресурсы, прежде чем наступит понимание.
Тем не менее, я бы хотел дополнить просторы интернета очередной статьей о Git. Постараюсь изложить все таким образом, как если бы у меня была возможность объяснить все самому себе из прошлого. Как следует из названия, я расскажу о Git очень коротко; а точнее о возможностях, которые он нам предоставляет.
Перед тем, как говорить про какую-либо конкретную систему контроля версий, необходимо понимать, что это такое и какими они бывают.
Системы контроля версий можно разделить на две группы:
1. Централизованные системы контроля версий;
2. Распределенные системы контроля версий.
Git является распределенной системой контроля версий, разработанной Линусом Торвальдсом для управления разработкой ядра Linux. На данный момент Git завоевал огромную популярность в IT сообществе и, как следствие, его часто можно встретить в стеке технологий различных компаний.
Далее я расскажу про структуру Git репозитория и как его завести. Познакомлю вас с основными, наиболее популярными командами в Git. Также вы узнаете о том, как инспектировать историю своего проекта и как откатить его до определенной точки. И, в заключение, я слегка затрону тему ветвления.
Установка Git
Прежде чем мы продолжим, вам необходимо установить Git.
Ниже я представлю краткую инструкцию к установке, но вы также можете пройти по этой ссылке на официальный источник и разобраться в этом самостоятельно.
Windows. Перейдите по ссылке и скачайте Git соответствующий архитектуре вашего процессора (32 или 64-bit) и установите его.
Linux. Перейдите по ссылке для более подробной инструкции.
Как правило, ваша работа с Git будет начинаться с того, что вам потребуется проинициализировать Git директорию в своем проекте. Это делается с помощью команды:
В данной директории будет содержаться вся конфигурация Git и история проекта. При желании можно править эти файлы вручную, внося необходимые изменения в историю проекта.
В данном файле содержатся настройки Git репозитория. Например, здесь можно хранить email и имя пользователя.
В этом каталоге Git предоставляет набор скриптов, которые могут автоматически запускаться во время выполнения git команд. В некоторых случаях это значительно упрощает разработку. Например, вы можете написать скрипт, который будет редактировать сообщение коммита согласно вашим требованиям.
Каталог refs хранит в себе копию ссылок на объекты коммитов в локальных и удаленных ветках.
Каталог logs хранит в себе историю проекта для всех веток в вашем проекте.
Каталог objects хранит в себе BLOB объекты, каждый из которых проиндексирован уникальным SHA.
Файл содержит ссылку на текущую ветку, в которой вы работаете
Каждый раз во время слияния в этот файл попадает SHA ветки, с которой проводилось слияние
Файл хранит в себе ссылки в виде SHA на ветки, которые участвовали в git fetch
Файл хранит в себе ссылки в виде SHA на ветки, которые участвовали в git merge
Файл содержит в себе последнее введенное вами сообщение коммита
Самые распространенные команды в Git.
При работе с системами контроля версий разработчики сталкиваются с определенной, повторяющейся последовательностью действий. Оно и понятно, ведь, по сути, если не брать в расчет возможности Git для управления состоянием проекта и прочие плюшки, то как правило ваша работа ограничена рядом действий:
1. Внести изменения в проект;
Итак, разберемся в этом подробнее. Проинициализировав Git репозиторий, вы начинаете вносить какие-то изменения в проект. Предположим, что вы создали файл `hello_world.txt` и работаете над его редактированием.
Введем git status и увидим следующее:
Команда git status отображает состояние директории и индекса(staging area). Это позволяет определить, какие файлы в проекте отслеживаются Git, а также какие изменения будут включены в следующий коммит.
Так как вы создали новый файл, Git определяет его как неотслеживаемый, и тут же подсказывает, что делать дальше:
git add hello_world.txt
Файл добавлен в индекс. Теперь можно закоммитить внесенные изменения и оставить небольшое описание. Делается это командой:
Готово! Мы сделали наш первый коммит! Далее добавим в наш файл строку “Hello, World!”, и снова проверим git status:
Что ж, мы научились записывать и хранить изменения на своей машине, теперь нам нужно отправить версию нашей истории на удаленный сервер. В данном примере я воспользуюсь репозиторием на GitHub.
Для начала вам нужно создать удаленный репозиторий. Как это реализовать в случае с GitHub подробно описано тут.
Далее необходимо добавить удаленный репозиторий в Git:
Эта команда сопоставит удаленное хранилище с ссылкой на локальный репозиторий. С этого момента можно обращаться к удаленному репозиторию через эту ссылку. Например:
git remote add origin https://github.com/user/hello_world.git
Готово! Теперь история изменений вашего проекта будет храниться в удаленном репозитории.
Работа с историей
Итак, как записывать, сохранять и отправлять изменения в удаленное хранилище мы разобрались.
Настало время поговорить о том, как управлять историей проекта. А именно как просматривать изменения и как откатить проект до определенной точки.
Для инспектирования истории в Git предусмотрен определенный ряд команд, рассмотрим несколько из них:
Данная команда предназначена для отображения всей вашей истории. Она может быть весьма удобна, если вам понадобилось узнать, какие изменения вы вносили ранее. Или если вам нужно откатиться до определенного места в истории, либо если есть нужда её отредактировать.
Если ввести git log без каких либо параметров, выглядит это примерно так:
git log имеет огромное множество дополнительных параметров, которые будут влиять на вывод в консоль. Вам предоставляется выбор на любой вкус.
Хотите просмотреть последние три коммита? Пожалуйста:
Есть необходимость вывести все в одну линию? Запросто:
Так можно продолжать до бесконечности, поэтому я оставлю ссылочку, перейдя по которой, вы сможете с ними подробней ознакомиться.
Команда git show используется для отображения полной информации о любом объекте в Git, будь то коммит или ветка. По умолчанию git show отображает информацию коммита, на который в данный момент времени указывает HEAD.
Для удобства работы git show оснащен рядом дополнительных параметров, некоторые из них мы рассмотрим ниже.
Здесь представлена полная информация о последнем коммите, а также какие именно изменения он в себя включает.
Мы также можем вывести диапазон из указанных коммитов. Диапазон указывается полуоткрытым интервалом, содержащим id коммитов, не включая первый элемент. Выглядит это следующим образом:
git show 349de9d..957e113
Для более лаконичного вывода, можно воспользоваться командой:
Таким образом, мы сократим id коммита, а также исключим авторство и дату коммита.
Подробнее с командой `git show` и с её параметрами можно ознакомиться перейдя по ссылке.
Эта команда выводит упорядоченный список коммитов, на которые указывал HEAD. Грубо говоря, она отображает историю всех ваших перемещений по проекту.
Основное преимущество этой команды заключается в том, что если вы вдруг случайно удалили часть истории или откатились назад, вы сможете проинспектировать момент утраты нужной вам информации и откатиться обратно.
Вывод этой команды выглядит следующим образом:
Теперь давайте рассмотрим очень полезную команду `git reset`. Она позволяет откатить проект до определенной точки.
Эту команду можно использовать с тремя параметрами:
Давайте вернемся к нашему репозиторию и рассмотрим следующий пример:
Итак, в ходе нашей работы, мы сделали четыре коммита. Предположим, что мы хотим откатить проект до второго коммита. Давайте посмотрим, как это будет происходить, используя разные параметры:
Далее, проверим индекс:
Как и ожидалось, указатель HEAD переместился на второй коммит, а состояние индекса осталось неизменным.
Проверим git status:
Снова проверяем git status :
Здесь указатель HEAD переместился на второй коммит, а все предыдущие изменения были стерты, что видно по пустому индексу и зоне отслеживаемых файлов.
И если посмотреть сейчас содержимое файла, то мы увидим единственную строку “Hello, world!”, которую мы с вами добавляли в файл во втором коммите.
Ветвление в Git
Почти каждая система контроля версий имеет поддержку ветвления. Ветвление означает, что у вас есть возможность работать над разными версиями проекта. То есть, если раньше история вашей разработки являла собой прямую последовательность коммитов, то теперь она может расходиться в определенных точках.
Это очень полезная функция по многим причинам, например для взаимодействия нескольких разработчиков. Представьте, вы с коллегой корпите над одним проектом. Каждый из вас работает над разными фичами, и для того чтобы не мешать друг другу, вы можете работать в разных ветках, а по окончанию работы слить эти ветки в одну.
Давайте попробуем с этим поработать на нашем примере. У нас имеется следующая последовательность коммитов.
Git по умолчанию во время инициализации создает ветку master и уже ведет свою работу в ней. Мы можем в этом убедиться введя команду:
Предположим, что нам по какой-либо причине понадобилось создать новую ветку и вести работу в ней. Для этого сначала необходимо её создать.
Делается это при помощи команды git branch
. Давайте создадим ветку “dev”:
Теперь введя команду git branch мы увидим следующее:
Звёздочкой Git указывает на текущую ветку, в которой мы работаем.
Для того чтобы переключиться на другую ветку используют команду git checkout
. Давайте переключимся на ветку “dev”.
Теперь внесем любые изменения в файл hello_world.txt и сделаем коммит, после чего посмотрим, как выглядят наши ветки после редактирования.
Теперь перейдем на ветку master
git checkout master
Помимо разделения истории в Git мы также можем соединять воедино два потока разработки. Это значит, что нашу проделанную работу в новой ветке мы можем слить обратно в master. Такой процесс слияния можно выполнить при помощи команды git merge
. То есть, если мы хотим слить изменения из ветки “dev” в ветку “master”, нам необходимо перейти на ветку “master” и в ней выполнить:
Примеры ведения истории проекта
Моя статья подходит к концу, но перед завершением хочу отметить, что во многих командах существуют определенные соглашения по поводу ведения истории в Git.
Например вас могут попросить соблюдать несколько правил, при написании сообщения коммита. Или перед работой вас могут ознакомить с определенной стратегией ветвления в проектах компании. Вас также могут ограничить в количестве отправляемых коммитов в удаленный репозиторий.
В качестве примера, я расскажу какие соглашения действуют в компании, в которой я работаю.
1. Сообщение коммита:
Ниже представлен шаблон наших сообщений коммита:
Мы указываем дату совершения коммита и версию приложения для удобства поиска работы в истории.
Модификаторы формата коммита предоставляют информацию о том какой фронт работы был выполнен в этом коммите.
Мы используем следующие модификаторы:
2. Стратегия ветвления:
В действительности можно насчитать достаточно много стратегий ветвления. Все они могут незначительно различаться, но выполнять совершенно разные задачи.
В нашем случае, мы выделяем две основные ветки master и «release». Master используется для подготовки к выкладке новых версий приложения. Код попавший в «master» проходит автоматические тесты, после которых выполняется сборка проекта, которую необходимо вручную протестировать перед дальнейшими действиями. Далее если замечаний к работе нет, мы сливаем ветку «master» в ветку «release». Там снова запускаются автоматические тесты, и собираются сборки к выкладке в маркеты.
Для ведения разработки мы создаем feature векти. Это означает, что каждая ветка отвечает за разработку какой-нибудь функциональности. Например, если мы хотим внедрить в приложение хранение данных в облаке, то программист создаст ветку «feature-cloud» и будет вести работу в ней.
Заключение
В качестве тренировки и закрепления имеющихся навыков, оставлю ссылку на удобный тренажер для Git.
А также на книги, которыми я пользовался и интернет ресурсы:
Также было бы интересно узнать какие практики по Git есть у вас в компаниях и какие интересные ресурсы вы можете подсказать.
Git для новичков (часть 1)
Что такое Git и зачем он нужен?
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса:
Как работает
В итоге получается очень простой граф, состоящий из одной ветки ( main ) и четырех commit. Все это может превратиться в более сложный граф, состоящий из нескольких веток, которые сливаются в одну.
Об этом мы поговорим в следующих статьях. Для начала разберем работу с одной веткой.
Установка
Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.
Но для начала, все же установим сам Git.
Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:
Linux. Открываем терминал и вводим следующую команду.
Настройка
Вы установили себе Git и можете им пользоваться. Давайте теперь его настроим, чтобы когда вы создавали commit, указывался автор, кто его создал.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
Создание репозитория
Теперь вы готовы к работе с Git локально на компьютере.
Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.
Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.
Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.
Процесс работы с Git
Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:
Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код
Это поможет держать вашу ветки в чистоте и порядке. Тем самым, вы будете видеть историю изменений по каждому нововведению в вашем проекте, а не по каждому файлу.
Визуальный интерфейс
Как я и говорил ранее, существуют дополнительные программы для облегчения использования Git. Некоторые текстовые редакторы или полноценные среды разработки уже включают в себя вспомогательный интерфейс для работы с ним.
Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:
Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.
Создаем свой первый проект и выкладываем на GitHub
Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).
Перед началом предлагаю зарегистрироваться на GitHub.
Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.
Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее
После этого у вас появится вот такой интерфейс
Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки
Давайте теперь перейдем во вкладу для работы с Git-ом.
Откроется вот такое окно:
Кнопка для публикации нашего проекта на GitHub
Вы создали и опубликовали репозиторий на GitHub.
Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.
Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:
Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Отправляем наш commit в GitHub
Поздравляю, вы научились создавать commit и отправлять его в GitHub!
Это первая вводная статья по утилите Git. Здесь мы рассмотрели:
Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub
Забегая вперед, советую вам погуглить, как работают следующие команды:
P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.
