Android studio add gitignore

Что должно быть в моем.gitignore для проекта Android Studio?

какие файлы должны быть в моем .gitignore для проекта Android Studio?

Я видел несколько примеров, которые все относятся .iml но IntelliJ docs говорят, что .iml должен быть включен в систему управления версиями.

29 ответов

обновлено до Android Studio 3.0 Пожалуйста, поделитесь недостающими элементами в комментариях.

поздний ответ, но ни один из ответов здесь и здесь был прав на деньги для нас.

Итак, вот наш файл gitignore:

начиная с Android Studio 2.2 и до 3.0, новые проекты создаются с помощью этого файла gitignore:

устаревший — для более старого формата проекта добавьте этот раздел в свой gitignore файл:

этот файл должен находиться в корневой папке проекта, а не в папке модуля проекта.

Редактировать Примечания:

начиная с версии 0.3+ кажется, вы можете commit и push *.iml и построить.Gradle в файлы. Если ваш проект на Gradle в: в новом диалоговом окне открытия/импорта, вы должны проверить «use auto import» установите флажок и отметьте радио. Все пути теперь относительны как предложил @George.

обновил ответ по @128КБ добавленные источник и @Skela предложения

строительство на моем обычном Android .gitignore, и после прочтения документации на веб-сайте Intellij IDEA и чтения сообщений на StackOverflow я построил следующий файл:

также обратите внимание, что, как указано,причине файлы раздел в первую очередь полезен, когда вы создаете свой собственный собственный код с Android NDK. Если, с другой стороны, вы используете стороннюю библиотеку, которая включает эти файлы, вы можете удалить эти строки (*.о и *.Итак) от вашего .гитюдного.

Обновлено 7/2015:

формат проекта на основе каталога (.каталог идей)

этот формат используется всеми последними версиями IDE по умолчанию. Вот что вам нужно поделиться:

• все файлы под .idea каталог в корне проекта за исключением на workspace.xml и tasks.xml файлы определенного пользователя настройки
• все .iml файлы модулей, которые могут быть расположены в разных каталогах модулей (относится к IntelliJ IDEA)

будьте осторожны поделиться следующим:

• артефакты Android, которые производят подписанную сборку (будут содержать пароли хранилища ключей)
• в идее 13 и ранее dataSources.ids , datasources.xml может содержать пароли базы данных. Идея 14 решает эту проблема.

вы можете рассмотреть возможность не делиться следующим:

• gradle.xml-файл, см. эта дискуссия
• папка пользовательских словарей (чтобы избежать конфликтов, если другой разработчик имеет то же имя)
• XML-файлы в разделе .idea/libraries в случае, если они генерируется из Gradle проект

устаревший формат проекта ( .ipr / .iml / .iws файлы)

• долю в проекте и .iml файлы модуля, не разделяю на .iws файл, как он хранит пользовательские настройки

хотя эти инструкции предназначены для IntelliJ IDEA, они верны на 100% для Android Studio.

здесь .gitignore фрагмент, который включает в себя все вышеперечисленные правила:

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

• /build
• /.idea (с возможными исключениями, см. комментарии ответ dalewking)
• *.iml
• local.properties

Я думаю, что почти все согласны с /build .

мне надоело постоянно видеть сообщения о различные library.xml файлы, которые Gradle создает или удаляет в /.idea . The build.gradle будет работать на локальном разработчиков, когда они впервые проверить проект, так почему эти XML-файлы должны быть версионными? Android Studio также будет генерировать остальную часть /.idea когда разработчик создает проект, используя Check out from Version Control , так почему же что-то в этой папке должно быть версионным?

если *.iml is versioned новый пользователь должен будет назвать проект точно так же, как это было, когда привержен. Поскольку это также сгенерированный файл, почему версия его в первую очередь?

на local.properties files указывает на абсолютный путь в файловой системе для SDK, поэтому он определенно не должен быть версионным.

изменить 1 добавлено .gradle игнорировать материал кэширования gradle, который не должен быть версионным (спасибо Василий Макаров).

Изменить 2 добавлено .DS_Store теперь, когда я использую Mac. Эта папка-Mac конкретные и должны не быть версионными.

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

для удобства копирования/вставки:

Источник

How to Use Git in Android Studio

Master your tool, master your craft

Feb 23, 2020 · 6 min read

What’s Covered

In this piece, I’ll show you some basic functionalities for working with Git in Android Studio, including:

• Integrating Git into the project
• Setting up remote connections
• Staging and committing changes
• Pushing the changes to remote
• Fetching the changes from remote
• Working with branches
• Showing log history

Let’s get started!

Note: All the reference paths, options, names, configurations in this article are based on Android Studio on the Mac OS system. It may be slightly different on other systems like Windows or Linux, but the spirit will be the same.

Integrate Git into the project

Test whether Git is configured

In Android Studio, go to Android Studio > Preferences > Version Control > Git. Click Test to ensure that Git is configured properly in Android Studio.

Enable version control integration

Suppose you’ve just created an Android project named MyApplication . In Android Studio, go to VCS > Enable Version Control Integration. This option won’t be visible if it’s integrated with any version control before.

Then choose Git as the version control system.

On a successful enable VCS, a default local master branch will be created

Add .gitignore to exclude files from Git

When you create a new Android project with Android Studio, two .gitignore files are automatically added (one in the project root folder, and the app folder). Files like generated code, binary files (executables, APKs), local configuration files should not be added to Git. Those files should be excluded from version control. Here’s my initial .gitignore file content:

Stage and Commit Changes

The project is ready to use with Git version control. To stage and commit your changes, go to VCS > Commit.

You will get a dialog to examine all files that will be added, enter commit messages and commit. You can deselect any files that you don’t want to belong to this commit.

When you click commit, a popup shows that you haven’t configured username and email yet. You should always configure them because they will be attached to your commit message.

There’s an option to “Set properties globally,” I recommend you don’t check this because if you do every git project on your local machine will have the same username/email. Sometimes you want to have different usernames/emails for your side projects and company projects.

All done — now the whole project has been added to Git.

Set Up Remote Connections

To add the project to the remote repository, go to VCS > Git > Remote.

Click “+” to add new remote, then type your remote URL in the URL box.

Now your local project links to your Github remote repository. Besides Github, you can use Bitbucket, Gitlab or any repository.

Push the Changes to Remote

To push your local changes to the remote repository, go to VCS > Git > Push.

The “Push Commits” popup will display which commit will be pushed to the remote-tracking branch. You can go ahead and make the push.

Fetch the Changes From Remote

To download the latest changes from remote, go to VSC > Git > Pull.

The “Pull Changes” popup appears. I won’t explain the pull strategy, just use the strategy and make the pull.

Work With Branches

Some people refer to Git’s branching model as its killer feature and it certainly sets Git apart in the VCS community. In this section, I’m going to show you how to work with branches in Android Studio.

Create a new branch

Go to VCS > Git > Branches.

“Git Branches” appears. It shows all the local branches and remote branches as well as the “New branch” option.

Tip: If you look at the right corner of Android Studio, you also see your current branch — clicking it will also opens the “Git Branches” popup.

Click “New Branch”, name it as a feature branch.

The other branching options

Suppose you are standing at the feature branch. Click on the master branch and expand the menu, you will see many options:

Let me explain each of them:

• Checkout: checkout master branch.
• Checkout As: checkout new branch from master
• Checkout and Rebase onto Current: checkout master and rebase feature branch onto it.
• Compare with Current: commits that exist in master but don’t exist in feature and vice versa.
• Show Diff with Working Tree: show the difference between the master and the current working tree.
• Rebase Current onto Selected: rebase master on feature.
• Merge into Current: merge master into feature.
• Rename: rename the master branch.
• Delete: delete the master branch.

You will choose the right option based on your needs.

Show Log History

Go to VCS > Git > Show History.

Android Studio will show the history of the currently open file:

You can click on the “Log” tab to see the whole log history:

Here, you can filter the history by branch, user, and date — helping you to find the commit you want quickly.

Conclusion

Thanks for reading this far!

That’s all for Part 1. I hope you learned something new. Stay tuned for Part 2 where we’ll be covering more advanced features of Git in Android Studio.

Источник

Подключаем 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 или наоборот вносить изменения в локальный проект из удалённого репозитория.

Источник