Can Git можно использовать как для отладки, так и для выпуска версий приложения

Question

Android Studio позволяет настроить проект для создания как отладочной, так и выпускной версии вашего приложения. Он также позволяет создавать «ароматы» приложения, которое по существу компилируется в разных функциях (пробная версия, полная версия и т. Д.).

Я сомневаюсь, что это необходимо, если использование Git выполнит одно и то же. С помощью Git вы можете создавать ветви, которые эффективно позволяют создавать «функциональные» версии. Однако я не совсем уверен, что Git позволит вам легко переключаться между версией отладки и выпуска. Вы можете создать ветвь «debug» и «release» и просто переключаться между ними, но эти ветки всегда остаются раздельными, пока вы их не объедините. Иногда единственная разница между версией отладки и выпуска приложения - это просто параметры проекта, которые могут включать в себя ключи в приложении, или ресурсы, которые используются только при локальном тестировании. Поэтому мой вопрос заключается в том, можно ли использовать Git в простой форме для обработки отладочной и выпускной версии приложения.

Answer 1

Система разветвления Git очень мощная. Однако, на мой взгляд, он не адаптирован для управления конфигурациями Debug и Realease проекта.

Действительно, 2 ветки одного и того же хранилища соответствуют 2 различным состояниям вашего проекта. Вы можете создать новую ветку для реализации новой функции, исправить конкретную ошибку и т. Д. И слить позже. Вы также можете создать ветвь для управления другой конфигурацией вашего проекта (debug/release), но если вы это сделаете, вам придется дублировать почти все ваши фиксации в этих двух ветвях. Команда «git cherry-pick» помогает вам скопировать фиксацию из ветки в другую, но вам часто придется сбросить и исправить фиксацию, чтобы исправить определенные строки отладки/выпуска.

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

Answer 2

Учитывая, что у вас есть главным образом файлы конфигурации, которые меняются между ветвями, а не весь код, я думаю, что вы можете использовать Git's submodules, который может позволить вам «связать» репозиторий с исходным кодом с такой папкой, как/src вашего основного репозитория (с двумя ветвями отладки/выпуска). Вам придется работать с двумя репозиториями, но, возможно, это чище. Кроме того, это очень полезно, если вам нужно часто менять конфигурационные файлы двух версий ...

Answer 3

Используйте правильные инструменты для правильной задачи.

Если у вас есть версия DEBUG и RELEASE для вашего продукта, это должно обрабатываться вашей строительной средой, а не вашим исходным кодом.

Например, в Visual Studio у вас есть как минимум две конфигурации сборки: отладка и выпуск. Эти конфигурации содержатся в ОДНОМ файле проекта/решении. После сборки вы решаете, какую конфигурацию нужно построить: Debug или Release.

же пошел бы для работы с Makefiles: если вы хотите иметь DEBUG и RELEASE сборки, вы должны иметь DEBUG цель и RELEASE цели, содержащиеся в вашем Makefile. Какая цель для сборки определяется для каждой сборки и не имеет ничего общего с контролем версий, ветвлением или чем-то еще.

Это также важно для переносимости: если вы решите переключиться с Git на другую систему управления версиями в один прекрасный день, вы действительно хотите, чтобы ваши конфигурации сборки управлялись вашим контролем версий? Это добавит дополнительных усилий, которые совершенно не нужны.

Позвольте вашей системе сборки обработать материал системы сборки и позволить вашему контролю версий делать вещи с версией.