Android studio idea git

Подключаем Git к Android Studio

Android Studio умеет работать с системами контроля версий (version control system, сокр.VCS). Самой популярной системой является Git, которая стала практически стандартом во многих языках программирования.

Сама по себе Git управляется через командную строку. Для изучения её возможностей есть множество документации. Мы сфокусируемся на подключении Git к проекту в Android Studio.

Чтобы лучше понять объяснения, откройте старый проект Hello Kitty или создайте его заново, если успели его удалить.

Для начала нужно установить Git. Перейдите на страницу загрузки http://git-scm.com/downloads и скачайте последнюю версию под вашу операционную систему.

Запускаем процесс инсталяции. Не рекомендую устанавливать в папку по умолчанию в системной папке Windows C:\Program Files, так как из-за пробела между словами часто возникают проблемы у многих пользователей при работе с командной строкой. Я установил в папке D:\Git. Желательно также прописать путь к папке D:\Git\bin\ в переменной окружения PATH.

Запускаем файл git-bash.exe для запуска консоли. Следует сконфигурировать Git, указав своё имя и электронный адрес, чтобы можно было установить авторство изменений в коде. Вводим по очереди две команды:

Возвращаемся в студию. Выбираем в меню File | Settings и в диалоговом окне в левой части выбираем секцию Version Control | Git. Нажимаем кнопку с многоточием и находим нужный файл на диске.

Для проверки можно щёлкнуть по кнопке Test, вы должны увидеть радостное сообщение в успешном случае. Закрываем окно настроек, применив изменения.

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

Далее идём в меню VCS | Import into Version Control | Create Git Repository и в диалоговом окне выбираем корневую папку проекта. Для удобства можно сразу нажать на значок студии (третий слева), чтобы сразу переместиться в корневую папку, если окно откроется с другой папкой.

Нажимаем кнопку OK и создаём локальный Git-репозиторий. Под капотом выполняется команда git init.

Как только вы это сделаете, в студии произойдут удивительные изменения. Многие имена файлов в левой панели окрасятся в коричневый цвет.

Коричневый цвет шрифта означает, что файл распознан системой контроля версий на локальном компьютере, но ещё не добавлен в репозиторий. Нам следует подсказать системе об этом.

Но не будем торопиться. При создании локального репозитория студия также создала несколько специальных файлов .gitignore, которые помогают системе контроля версий игнорировать некоторые файлы проекта при изменениях. Один такой файл вы можете найти в корневой папке проекта, а второй в папке app. Можете открыть их любым текстовым редактором. Начнём с файла из корневой папки.

Как видим, Git будет игнорировать файл .idea/workspace.xml, который относится к конфигурации самой студии на вашем компьютере и к самому проекту не имеет отношения. Аналогично будет проигнорирован файл local.properties, который является уникальным для каждого компьютера. Можно указывать не только отдельные файлы, но и папки. Например, в списке присутствует папка /build. В эту папку попадают файлы при компиляции. Их нет смысла отслеживать, так как они постоянно меняются, когда вы запускаете приложение для проверки. Все файлы, которые должны быть проигнорированы, выводятся обычным чёрным цветом. Обратите внимание на имя файла local.properties на скриншоте выше.

Читайте также:  Как настроить китайские смарт часы с телефоном андроид через блютуз

Кроме чёрного и коричневого цвета, имена файлов могут также выводиться синим цветом (файл изменён), зелёным (новый файл).

При подключении Git в нижней части студии появится новая вкладка Version Control. Откройте её. Сейчас вы видите две секции: Default и Unversioned Files. Секция Default сейчас пуста. При изменении или создании новых файлов они попадут в эту секцию. Секция Unversioned Files содержит файлы, которые ещё не были учтены системой контроля версий.

При создании нового проекта файлы автоматически не учитываются и находятся в секции Unversioned Files. Мы хотим их перенести в репозиторий. В левой части панели находятся две колонки со значками. Найдите значок с изображением папки в скобках (при подведении курсора появится подсказка Group by Directory) и нажмите на неё. Файлы будут сгруппированы, как в проекте. Так проще вам будет понять структуру.

Щёлкаем правой кнопкой мыши на Unversioned Files и выбираем в контекстном меню Add to VCS. Либо можно перетащить мышкой эту секцию на секцию Default. В результате все файлы переместятся и будут учтены системой контроля версий.

После добавления файлов нажмите на значок с зелёной стрелкой вверх и надписью VCS (Commit Changes). Откроется диалоговое окно. В текстовом поле Commit Message введите текст, поясняющий изменения в проекте и нажмите кнопку Commit.

Файлы исчезнут из секции Default и теперь находятся под контролем Git. При изменении файл снова попадёт в данную секцию и вам снова нужно выполнить предыдущую операцию Commit.

Например, откроем файл манифеста и добавим разрешение на работу с интернетом. Файл окрасится в синий цвет. Комментируем изменения в проекте, добавив сообщение Добавлено разрешение на интернет.

Просматривать изменения можно на вкладке Log. Вы можете просматривать коммиты и ветки.

Таким образом мы познакомились с базовыми приёмами работы с Git.

Также вы можете создавать новые ветки, сливать их в одну и выполнять прочие операции.

Естественно, вы можете также выкладывать проект на GitHub или наоборот вносить изменения в локальный проект из удалённого репозитория.

Источник

ПШЕ AndroidStudio или как использовать VCS Tools по полной

Примерно такая реакция была у меня после получения апрува первого пул реквеста на первой неделе работы в одной крупной компании. Причина такой реакции весьма простая — далеко не каждый заказчик/работодатель может себе позволить такую роскошь как большая команда на одну платформу, в особенности это касается мобильной разработки. Из-за ненадобности и возможности быстрой коммуникации в своем мирке, далеко не все вещи, которые используют крупные мастера своего дела, обретают актуальность в небольших командах. Говоря проще — а на кой мне это надо, если мы и так хорошо без этого жили и хорошо справлялись?

После перехода в новую компанию я столкнулся с той же проблемой, но уже по другую сторону баррикад. Если вы еще не догадались о чем пойдет речь дальше — это GIT, говоря точнее, его встроенный инструментарий в AndroidStudio и как он позволяет сделать нашу работу проще.

Я постараюсь не обращать внимания на банальные вещи: init VCS; new/rename/push branch; rebase/merge onto branch; setup remotes e.t.c. Я постараюсь обратить внимание на те элементы, которые по боязни своего незнания, я долгое время избегал(и жалею).

Amend commit

В случае, когда Вы решили дополнить свои изменения к последнему коммиту, стоит воспользоваться следующей коммандой:

А можно ускорить процесс:

Edit commit message

Допустим, Вы создали большой PR с большим количеством коммитов, да перед пушем заметили, что одно из сообщений некорректно и было бы неплохо его отредактировать, пока жесткий ревьювер не четвертовал Вас за такую оплошность:

Читайте также:  Android studio icons github

Interactive rebase

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

Пачка была быстро собрана, коммиты получились хаотичные, да еще и на ревью получил порцию исправлений… Окей, не проблема.

Проверяем отставание наших изменений от ветки, в которую мы хотим вливаться.

Либо через GUIню:

Дальше скачем в tools:

Указываем количество коммитов, которые хотим отредактировать:

Или сразу укажем таргeт ветку:

Дальше определяемся что нам нужно сделать:

Подробнее про команды:

Коммиты отредактированы, осталось только подлить все на ремут сервер. Но ведь история изменена? И хэши явно не совпадают с тем, что находится на удаленной ветке.

Force push перезатрет нашу историю и примет новые изменения как родные.

Multiple remotes

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

Что это? В случае работы в 2 и более ремут хранилищах(актуально, когда доступ в основное хранилище по прямому запросу закрыт), быстрое переключение между удаленным ветками для пушей/пулов тоже упрощен:

Git blame

Полезный трюк для просмотра автора внесенных изменений:

Теперь про более эффективную работу. Если Вы не поленились и внесли правила ведения коммитов в Вашем проекте, стоит включть IssueNavigationLink :

(Кроме всего этого, Вы можете настроить проверку формирования коммит мессаджа с помощью git-hooks — https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
Отредактируем файл project/.idea/vcs.xml :

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

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

Git cherry-pick

Не путать с командой cherry!

Допустим, Вы работаете над фичей/фиксом, во время работы заметили блокирующий Вас баг и поправили его, да всю свою работу не закончили и в рабочую ветку не влились. Ваши компаньоны отрепортили, что проблема блокирует не только Вас, но и кого-то другого, и было бы неплохо поделиться им. Но Вы все еще работаете над своей задачей, а отвлекаться нет желания… В таком случае, будет проще всего забрать Ваш 1 коммит в другую ветку и экстренно вмержить его в рабочую (фризную ветку). Как это сделать?

Заключение

В заключении хотелось бы сразу вспомнить вечный холивар на тему: терминал или GUI редактор для работы с VCS? Тут дело вкусовщины. Понятно дело, что CLI GIT-а более мощный инструмент и для спецефичных задач без него никуда. Но для ежедневных задач встроенный пакет утилит для работы с системами контроля версий в AS — просто must have и сократит время разработки в разы.
Надеюсь, что Вы нашли что-то новое в этой статье и помог облегчить Ваши трудовые будни.

Источник

Глубокое погружение в папку .idea в Android Studio

Как и для многих разработчиков, папка .idea в Android Studio для меня всегда была, как черный ящик: я знал, что она существует, я знал, что её всегда добавляют в .gitignore, но я решил узнать, для чего же там нужны те или иные файлы и папки, чтобы у меня была возможность обрабатывать иногда возникающие git-конфликты, и для того, чтобы точно знать, какой файл можно безопасно добавить в .gitignore, а какой нет.

Читайте также:  Android lingvo свои словари

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

указывает путь, который следует добавить в .gitignore

указывает путь, который Android Studio уже добавила в .gitignore , и вам не следует его версионировать.

указывает путь, который вы должны хранить в git.

assetWizardSettings.xml

Этот файл хранит последнюю иконку, добавленную с помощью интерфейса Android Studio. Его можно безопасно удалить из VCS.

caches

Кэши, как следует из названия, могут быть безопасно добавлены в .gitignore .

Не вижу никаких оснований держать его в VCS, но по умолчанию эта папка в .gitignore не добавлена.

caches/build_file_checksums.ser

По факту, этот файл представляет собой сериализированный экземпляр ProjectBuildFilesChecksums.

Файл необходим, чтобы проверить, изменились ли build.gradle , settings.gradle , local.properties ,

/.gradle/gradle.properties , gradle.properties или файлы build.gradle ваших модулей.

Android Studio использует этот файл для того, чтобы сообщить вам о том, что нужно синхронизировать gradle-файлы.

codeStyles

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

dictionaries

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

gradle.xml

Рекомендую удалить этот файл из git. Он может содержать локальный путь к вашей версии gradle, а также путь к вашему модулю. Например, вы можете разработать модуль в отдельном репозитории, поэтому путь к модулю может быть специфичным для каждого пользователя.

По всем этим причинам я окончательно удаляю файл gradle.xml из VCS.

inspectionProfiles

Эта папка содержит конкретные Lint-правила для вашего проекта. Поэтому так же, как и папка dictionaries , она должна храниться в git.

libraries

Здесь содержится файл, который указывает, где хранятся jar-файлы ваших библиотек. Поскольку путь загрузки может быть специфичным для каждого пользователя, вы не должны хранить эту папку в VCS.

misc.xml

Файл содержит информацию о проекте: версия Java, тип проекта и др.

Эти сведения касаются проекта и не зависят от пользователя. Поэтому его следует хранить в git.

modules.xml

Этот файл содержит пути к .iml -файлам ваших модулей. Поэтому по аналогии с gradle.xml его нельзя хранить в git.

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

runConfigurations.xml

Имя файла может вам намекнуть, что в нём хранятся конфигурации, которые вы можете добавить, нажав «Изменить конфигурации». Этот файл обязательно нужно хранить в VCS.

vcs.xml

Этот файл содержит информацию о VCS, которую вы используете в своём проекте. Он используется для того, чтобы вы могли использовать графический интерфейс для выполнения операций, связанных с управлением версиями. Его тоже стоит добавить в git.

workspace.xml

Здесь содержится информация о вашем рабочем пространстве в Android Studio. Например, последняя позиция курсора на открытом вами файле. Так что это определенно пользовательская информация, которую нет необходимости хранить в git.

Итоги

Я бы предложил вам добавить всего три строки к файлу .gitignore по умолчанию:

Как я уже сказал в начале этой статьи, я не нашёл никакой документации о содержимом папки .idea , поэтому статья может быть неполной и/или не точна на 100%. Если вы знаете ещё что-то, чего нет в этой статье, то пишите об этом в комменнтарии.

Источник

Оцените статью