Как работать с Git и Gitflow: разбираемся на примерах

Привет, Хабр! Меня зовут Николай Пискунов, я руководитель направления Big Data, и в блоге beeline cloud я делюсь практическими советами по программированию. В этой статье погрузимся в увлекательный мир Git и узнаем, как он поможет эффективно управлять версиями наших проектов.

Немного теории для понимания

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

История создания Git началась в 2005 году, когда разработчик Линус Торвальдс столкнулся с проблемами при использовании других систем контроля версий для управления исходным кодом ядра Linux. Он решил создать свою собственную систему, которая была бы быстрой, простой в использовании и способной эффективно обрабатывать очень большие проекты.

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

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

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

Но поговорить сегодня я хочу не столько о самом Git, сколько об одном его стандарте — Gitflow.

И если Git — это система контроля версий, которая позволяет отслеживать изменения в коде, создавать ветки для разработки и объединять их, то Gitflow — это модель ветвления, основанная на Git, которая определяет лучшие практики для работы с ветками. Она предлагает использовать основные ветки master и develop, а также создавать отдельные ветки для разработки новых функций, исправления ошибок и выпуска версий.

Небольшое саммари, чтобы двигаться дальше

Итак, мы с вами поняли, что:

Git — это инструмент для контроля версий.
Gitflow — это модель ветвления, которая помогает организовать процесс разработки и управления версиями в проекте.
Git — это технология.
Gitflow — это методология или, если хотите, правила использования этой технологии.

Gitflow очень помогает в командной разработке, когда над проектом трудится несколько человек. Коллеги могут пилить одновременно несколько фич, при этом не мешая друг другу. Этому очень помогает структура ветвления по Gitflow.

.gitignore без игнора: создаем проект и погружаемся в детали

Для упрощения понимания давайте создадим проект, например на Spring Boot, а для хранения кода и командной работы будем использовать Git-репозиторий на https://gitverse.ru/.Также можно использовать https://bitbucket.org/, https://github.com/ и пр., различия в работе минимальны.

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

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

Для начала внутри проекта предлагаю создать и настроить файл .gitignore.

.gitignore — это файл, который указывает Git, какие файлы или директории игнорировать при добавлении изменений в репозиторий.

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

Пример .gitignore-файла:

 # игнорировать все файлы с расширением .log *.log # игнорировать директорию node_modules node_modules/ # игнорировать файл config.json config.json # игнорировать все файлы в директории tmp tmp/

В этом примере Git будет игнорировать все файлы с расширением .log, директорию node_modules, файл config.json и все файлы в директории tmp.

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

Пример .gitignore-файла, который используется в проекте:

HELP.md target/ !.mvn/wrapper/maven-wrapper.jar !**/src/main/**/target/ !**/src/test/**/target/  ### STS ### .apt_generated .classpath .factorypath .project .settings .springBeans .sts4-cache    ### IntelliJ IDEA ### .idea *.iws *.iml *.ipr    ### NetBeans ### /nbproject/private/ /nbbuild/ /dist/ /nbdist/ /.nb-gradle/ build/ !**/src/main/**/build/ !**/src/test/**/build/    ### VS Code ### .vscode/

Теперь надо проинициализировать проект. Это можно сделать командой git init. Эта команда — одна из основных команд Git, которая создает новый репозиторий Git.

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

Команда git init также создает несколько дополнительных файлов и директорий:

.gitignore — файл, который мы создали выше. Он содержит список паттернов файлов и директорий, которые не должны быть включены в репозиторий.

.git/objects — директория, которая хранит объекты Git, такие как коммиты, деревья и другие данные.
.git/ref — директория, которая хранит ссылки на коммиты и ветки.

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

Итак, мы с вами создали новый репозиторий в этой директории.

Фиксируем изменения

Для этого нам требуется выполнить команды git add и git commit.

Команда git add используется для добавления изменений в индекс (или staging area) перед тем, как они будут зафиксированы с помощью команды git commit, которую рассмотрим ниже. Это позволяет выбирать конкретные изменения, которые вы хотите включить в следующий коммит, а также предварительно просматривать свои изменения перед фиксацией. Это помогает подготовить ваш коммит более тщательно и избежать включения ненужных изменений.

Выполним команду bash

$ git add

С помощью этой команды мs добавили в staging area все изменения, которые находились у нас в папке. Символ «.» дает понять Git, что требуется добавить все изменения. Того же эффекта можно добиться с помощью команды git add -A.

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

 $ git add FileName.class $ git add /service/ServiceName.class

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

Чтобы выполнить команду git commit, вы должны указать сообщение коммита, которое обязательно должно быть детальным и описывать суть произведенных изменений. Давайте наш первый коммит так и назовем — first commit. Для этого выполним команду:

git commit -m "first commit"

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

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

 $ git remote add origin [НАЗВАНИЕ РЕПОЗИТОРИЯ, например ssh://git@gitverse.ru:2222/[NAMESPACE]/[PROJECT_NAME].git] $ git branch -M master $ git push -u origin master

Эти команды описаны во всех представленных выше сервисах при создании в них нового проекта.

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

Ветка master: что это и зачем

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

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

Для каких целей использовать ветку master

Хранение последней стабильной версии проекта.
Ветка для выпуска готовой продукции.
Начальная точка для большинства разработчиков.

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

Залив код в репозиторий, мы получим следующую картинку в IDE IDEA:

А так это выглядит в веб-браузере при использовании одного из репозиториев, представленных выше (на скрине представлен https://gitverse.ru/):

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

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

beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

ссылка на оригинал статьи https://habr.com/ru/articles/829142/