Введение в систему контроля версий и Git

Знакомы с Google Документами? Что ж, если да, можно с уверенностью предположить, что вы знакомы с небольшой вкладкой «История версий», которая позволяет авторам и заинтересованным лицам проверять и отслеживать все изменения, внесенные в документ. в любой данный момент времени. Удобный инструмент, не правда ли?

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

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

Здесь на помощь приходит программное обеспечение для контроля версий.

Почему контроль версий важен в разработке программного обеспечения

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

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

Доступное программное обеспечение для контроля версий

Хотя в своем обзоре GitLab лидер в области распределенного программного обеспечения обнаружил, что 98 % пользователей используют инструменты Git с открытым исходным кодом, а более 92 % разработчиков используют Git в качестве языка управления версиями в процессе разработки приложений, есть ряд причин, по которым разработчики могут обратить внимание на альтернативу Git. Некоторые из этих причин могут варьироваться от структуры ценообразования GitHub и того факта, что Github запущен как на iOS, так и на Android, отвращения к Octocat или простого уровня комфорта с языком управления версиями, отличным от Git.

Какой бы ни была ваша причина, вот альтернатива Git для контроля версий:

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

Почему Appinventiv использует Git для контроля версий

1. За молниеносную скорость

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

2. За возможность работать в автономном режиме

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

3. Для сброса отмены

Git поставляется с командой «отменить», которая позволяет вам исправить и отменить всю фиксацию. Фактически, он даже дает вам возможность восстановить «удаленный» коммит с помощью опции Reflog.

4. Для резервного копирования

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

5. За полезные коммиты

Когда наша команда разработчиков вносит набор несвязанных изменений — берет некоторые функции из A, исправляет некоторые ошибки в другом — другим членам команды может быть очень трудно понять, что произошло, и им может быть трудно откатиться. Функции A, если они вызывают проблемы.

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

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

Давайте перейдем к этому сейчас.

Процесс контроля версий при использовании Git

Создание репозитория

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

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

Когда вы создаете репозиторий, вы обычно получаете два варианта — общедоступный и частный. Публичный репозиторий — это тот, который могут просматривать другие разработчики, использующие Git, а частный, с другой стороны, — это тот, который могут просматривать только несколько человек.

Ветвление

Рядом с Созданием репозитория находится Ветвление. В такой компании, как Appinventiv, где в любой момент времени более 15-20 разработчиков работают над одним проектом, нередко разработчики используют один и тот же исходный код и работают над ним. Что происходит, так это то, что пока одни разработчики заняты исправлением проблем, другие могут реализовывать некоторые функции.

В такой ситуации нам нужна система, которая упрощает работу с разными версиями кода в одной кодовой базе.

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

Прежде чем мы продолжим рассказ о том, как работает процесс ветвления в Gitflow, позвольте мне объяснить концепцию на примере.

Предположим, в вашей команде 5 разработчиков, и они работают над созданием приложения, похожего на Instagram. Теперь отдельные функции приложения, такие как лента новостей и уведомления, обозначаются как модуль 1, модуль 2 и т. д. и т. д. Теперь эти разные модули являются ветками разработки, которые после работы объединяются с родительской веткой или Master.

В тот момент, когда разработчик добавляет ветку, он создает независимую линию разработки, которая изолирует его работу от работы членов его команды. Затем различные ветки объединяются в родительскую ветвь.

Ветвление — это метод, который позволяет членам команды определить, какие изменения им следует ожидать, и это то, что упрощает откат.

В наших проектах мы обычно сохраняем эти ветки —

• Мастер Филиал
• Филиал развития
• Ветка функций
• Релизная ветвь
• Горячие исправления и исправления ошибок

Совершить

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

Толкать

Когда вы делаете фиксацию в локальном репозитории Git, дальше происходит отправка изменений на сервер, известный как Push .

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

Далее мы рассмотрим, что делается на этапе Pull Change.

Пулл-реквест

Когда несколько разработчиков работают над одним и тем же файлом, происходит то, что какой-то коммит может быть отправлен на сервер другим разработчиком до того, как вы отправите его. И когда это происходит, возникает конфликт (подробнее об этом позже).

Чтобы избежать повторной загрузки одной и той же кодовой базы на сервер, разработчики сначала извлекают изменения из репозитория и проверяют, что коды разные. Теперь, как правило, когда два или более разработчиков работают над одним и тем же файлом и отправляют свою фиксацию на сервер, появляется возможность «Объединить».

Давайте поговорим о слиянии дальше.

Объединить

Слияние — это шаг, на котором разработчики объединяют все ветки сначала друг с другом, а затем с главной или родительской веткой.

Каждый раз, когда доставщик вводит команду Push, он получает опцию Merge, которая затем запрашивает у него ветку, с которой он хотел бы объединить коммит.

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

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

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

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

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

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