Немного теории для понимания
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, в которую мы залили код. Обязательно добавьте коллег в один из выбранных вами сервисов, чтобы они также имели доступ к коду и возможности вносить изменения в него. В итоге у нас имеется удаленный репозиторий и возможность вносить в него изменения не только самостоятельно, но и всей вашей командой.
В следующей статье мы рассмотрим модель ветвления и поймем, как можно работать над одним общим кодом, при этом не мешая друг другу.
