Привет, Хабр! Меня зовут Николай Пискунов, я руководитель направления 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-репозиторий на gitverse.ru.Также можно использовать bitbucket.org, 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:

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

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

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

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