Как синхронизировать проект в android studio

Как синхронизировать проект в android studio

Теперь создадим первое приложение в среде Android Studio для операционной системы Android. Откроем Android Studio и на начальном экране выберем пункт New Project :

При создании проекта Android Studio вначале предложит нам выбрать шаблон проекта:

Android Studio предоставляет ряд шаблонов для различных ситуаций. Выберем в этом списке шаблон Empty Activity , который предосавляет самый простейший фукционал, необходимый для начала, и нажмем на кнопку Next .

После этого отобразится окно настроек нового проекта:

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

• В поле Name вводится название приложения. Укажем в качестве имени название HelloApp
• В поле Package Name указывается имя пакета, где будет размещаться главный класс приложения. В данном случае для тестовых проектов это значение не играет ольшого значения, поэтому установим com.example.helloapp .
• В поле Save Location установливается расположение файлов проекта на жестком диске. Можно оставить значение по умолчанию.
• В поле Language в качестве языка программирования укажем Java (будьт внимательны, так как по умолчанию в этом поле стоит Kotlin)
• В поле Minimum SDK указывается самая минимальная поддерживаемая версия SDK. Оставим значение по умолчанию — API 21: Android 5.0 (Lollipop) , которая означает, что наше приложение можно будет запустить начиная с Android 5.0, а это 94% устройств. На более старых устройствах запустить будет нельзя. Стоит учитывать, что чем выше версия SDK, тем меньше диапазон поддерживаемых устройств.

Далее нажмем на кнопку Finish, и Android Studio создаст новый проект:

Вначале вкратце рассмотрим структуру проекта, что он уже имеет по умолчанию

Проект Android может состоять из различных модулей. По умолчанию, когда мы создаем проект, создается один модуль — app . Модуль имеет три подпапки:

• manifests : хранит файл манифеста AndroidManifest.xml , который описывает конфигурацию приложения и определяет каждый из компонентов данного приложения.
• java : хранит файлы кода на языке java, которые структурированы по отдельным пакетам. Так, в папке com.example.helloapp (название которого было указано на этапе создания проекта) имеется по умолчанию файл MainActivity.java с кодом на языке Java, который представляет класс MainActivity, запускаемый по умолчанию при старте приложения
• res : содержит используемые в приложении ресурсы. Все ресурсы разбиты на подпапки.
  • папка drawable предназначена для хранения изображений, используемых в приложении
  • папка layout предназначена для хранения файлов, определяющих графический интерфейс. По умолчанию здесь есть файл activity_main.xml , который определяет интерфейс для класса MainActivity в виде xml
  • папки mipmap содержат файлы изображений, которые предназначены для создания иконки приложения при различных разрешениях экрана.
  • папка values хранит различные xml-файлы, содержащие коллекции ресурсов — различных данных, которые применяются в приложении. По умолчанию здесь есть два файла и одна папка:
    • файл colors.xml хранит описание цветов, используемых в приложении
    • файл strings.xml содержит строковые ресурсы, используемые в приложении
    • папки themes хранит две темы приложения — для светлую (дневную) и темную (ночную)

    Отдельный элемент Gradle Scripts содержит ряд скриптов, которые используются при построении приложения.

    Во всей этой структуре следует выделить файл MainActivity.java, который открыт в Android Studio и который содержит логику приложения и собственно с него начинается выполнение приложения. И также выделим файл activity_main.xml , который определяет графический интерфейс — по сути то, что увидит пользователь на своем смартфоне после загрузки приложения.

    Возможные проблемы

    Для создания приложения используется Java. А для построения приложения применяется инфраструктура Gradle. Однако текущая используемая версия Gradle может быть несовместима с выбранной по умолчанию версией JDK. И в этом случае Android Studio может отображать ошибки, например, ошибку Unsupported class file major version 61 :

    

    Эта ошибка говорит о том, что версия JDK 17 несовместима с текущей версией Gradle. И надо использовать меньшую версию.

    Для решения этой проблемы перейдем в студии к меню File ->Settings (на MacOS это пункт Android Studio -> Preferences )

    

    Затем в открывшемся окне настроек перейдем к пункту меню Build, Execution, Deployment -> Build Tools -> Gradle и далее найдем поле Gradle JDK , где изменим версию JDK. Она должна иметь версию 11 и выше. Как правило, вместе с Android Studio устанавливается и поддерживаемая версия JDK — на данный момент это JDK 11. И ее можно выбрать в списке JDK:

    

    Наиболее оптимальный пункт для выбора версий JDK, которая идет вместе с Android Studio, называется Embedded JDK version. . Как видно на скриншоте, это версия 11, но при последующих обновлениях Android Studio эта версия может измениться.

    После сделанных изменений сначала нажмем на кнопку Apply , а затем на кнопку OK . И повторим запуск проекта.

    Запуск проекта

    Созданный выше проект уже содержит некоторый примитивный функционал. Правда, этот функционал почти ничего не делает, только выводит на экран строку «Hello world!». Тем не менее это уже фактически приложение, которое мы можем запустить.

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

    Режим разработчика на телефоне

    По умолчанию опции разработчика на смартфонах скрыты. Чтобы сделать их доступными, надо зайти в Settings > About phone (Настройки > О телефоне) (в Android 8 это в Settings > System > About phone (Настройки > Система > О телефоне) ) и семь раз нажать Build Number (Номер сборки) .

    

    Теперь необходимо включить отладку по USB. Для этого перейдем в Settings > System > Advanced > Developer options или Настройки > Система > Дополнительно > Для разработчиков (в Android 8 это в Settings > System > Developer options или Настройки > Система > Для разработчиков ).

    

    И включим возможность отладки по USB:

    

    Запуск приложения

    Подключим устройство с ОС Android (если мы тестируем на реальном устройстве) и запустим проект, нажав на зеленую стрелочку на панели инструментов.

    

    Выберем устройство и нажмем на кнопку OK. И после запуска мы увидим наше приложение на экране устройства:

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

     .gradle /local.properties /.idea/workspace.xml /.idea/libraries .DS_Store /build /captures 

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

    Инструкция по установке

    Видеоинструкция по интеграции VPS SDK в проект для Android:

    Запуск Example Project 

    Для запуска примера приложения необходим смартфон с поддержкой ARCore.

    1. Клонировать репозиторий по ссылке

    https://github.com/naviar-io/naviar-sdk-android.git 

    1. Открыть проект в Android Studio(также можно клонировать проект при помощи Android Studio: File → New → Project From Version Control и в поле URL указать ссылку из пункта 1)
    2. Дождаться окончания синхронизации проекта и запустить проект

    По умолчанию приложение запускается для работы с реальными данными и с использованием GPS. Чтобы проверить работу приложения на фото надо выполнить следующие шаги:

    После запуска приложения и предоставления всех разрешений, нужно сделать долгое нажатие по экрану, появится следующее меню

    • Autofocus — выбран
    • GPS — не выбран

    Интеграция в собственный проект 

    1. В build.gradle модуля добавить зависимость. Для этого в блок dependencies добавить следующую строчку

    dependencies  implementation("io.naviar:vps-sdk:0.7.0")  . > 

    1. Выполнить синхронизацию проекта с gradle.
    1. Добавить VpsArFragment на экран. Это можно сделать в xml или через код

    androidx.fragment.app.FragmentContainerView android:id="@+id/vFragmentContainer" android:name="io.naviar.vps_sdk.ui.VpsArFragment" android:layout_width="match_parent" android:layout_height="match_parent" /> 

    supportFragmentManager.beginTransaction() .replace(R.id.vFragmentContainer, VpsArFragment()) .commit() 

    1. Создать конфигурацию для VpsService . Для этого можно вызвать

    // конфигурация для локализации внутри зданий val vpsConfig = VpsConfig.getIndoorConfig(locationIds>) // или конфигурации для локализации вне зданий val vpsConfig = VpsConfig.getOutdoorConfig(locationIds>) // или создать свою конфигурацию val vpsConfig = VpsConfig(locationIds>) 

    Название параметра	Описание	Значение по умолчанию
    locationIds	Идентификатор(ы) локации(й) для локализации.	не задано
    intervalLocalizationMS	Интервал между локализациями. Задается в миллисекундах.	2500
    useGps	Использовать GPS при локализации или нет.	false
    localizationType	Способ локализации. Можно установить локализацию по фото(Photo) или при помощи нейронных сетей(MobileVps).	MobileVps
    failsCountToResetSession	Количество неудачных попыток для сброса текущей сессии VPS (количество попыток исправить положение с учетом результата предыдущей локализации)	5
    updateWorldDurationMS	Продолжительность обновления позиции модели между локализациями. Задается в миллисекундах.	500
    updateWorldDistanceLimit	Если разница позиций моделей между двумя локализациями будет больше заданного значения, то позиция модели будет установлена немедленно, а иначе будет плавное перемещение модели до нужной позиции.	2f
    updateWorldAngleLimit	Если разница поворота моделей между двумя локализациями будет больше заданного значения, то поворот модели будет установлен немедленно, а иначе будет плавный поворот модели до нужного значения.	10f

    После установить конфигурацию в VpsService

    val vpsService = vpsArFragment.vpsService vpsService.setVpsConfig(vpsConfig) 

    Синхронизация кода на разных машинах

    Такой вопросец! Веду разработку приложения(Андроид) в эклипсе на домашнем пк. Задумываюсь взять ещё ноут, чтобы кодить вне домаю. Каким образом можно было бы синхронизировать проект, чтобы я мог работать над одним и тем же кодом и домашнем пк и на ноуте и код бы автоматом обновлялся и там и там? Быть может есть удобные сервисы для этого или в самом эклипсе есть что-то подобное?

    �� Подобається Сподобалось 0

    До обраного В обраному 0

    Найкращі коментарі пропустити

    Не слушай никого кто будет тебе парить github или bitbucket и прочую фигню. Надо архивировать исходники zip или rar и синхронизировать между машинами посредством электронной почты. Самый надежный и проверенный способ.

    Это называется системы контроля версий. Гугли и да прибудет с тобою сила

    малчык сюда хады тут рэпозыторый прыватный безплатно дам bitbucket.org

    

    Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
    Ctrl + Enter

    117 коментарів

    

    Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
    Ctrl + Enter
    ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 14.11.2014 18:13

    Якщо git здається занадто складним для такої задачі.

    GitHub или Assembla

    Dmitriy Levin Android developer 08.11.2014 13:01

    Один аккаунт на dropbox на ПК и на нотике с маркой Projects решает данный вопрос весьма успешно, больше года пользуюсь такой фичей.
    Это удобно, можно продолжить работу с того же места, допустим на ноутбуке (не забыв в эклипсе обновить папку проекта по F5)
    P.S. Ну и конечно для надежности систему контроля версий никто не отменял, не забудьте завести Git в Ваш проект.

    GitHub, Bitbucket.
    Если все плохо — воркспейс в дропбокс

    Я собі завів хостинг для цієї потреби. git + redmine

    Олександр Зайцев Android Engineer 07.11.2014 17:11

    Хочешь, чтобы другие видели твой проект — Github. Если «моя прелесть» — Bitbucket. В последнем бесплатно в одной команде может быть 5 человек.

    Кстати, Bitbucket good еще и потому, что там можно Mercurial использовать, а не только Git.

    Gennady Dogaev full-stack web developer (freelance) 07.11.2014 15:54

    Git (кажется, можно внутри сети клонировать ветку напрямую, но я не пробовал), GitHub, GitLab (если есть какой-нибудь сервер дома или желание купить VPS)

    Это называется системы контроля версий. Гугли и да прибудет с тобою сила

    Volodymyr Spodaryk Software Engineer в Djinni.co 07.11.2014 14:50

    Якщо працюєш сам: Google Drive, Dropbox
    Якщо в команді: Bitbucket, GitHub
    Все решта, на власний смак)

    Якщо працюєш сам: Google Drive, Dropbox

    Месье знает толк в извращениях
    Євген Козлов Front-end developer в SoftServe 08.11.2014 00:26

    ну-ну. а коммитить и пушить заведомо нерабочий код, бо «пора домой, так и закончу» — это как называется?
    а закидывать файл настроек и файл с историей выполнения команд в репозиторий ради удобной синхронизации — это норм?

    ну-ну. а коммитить и пушить заведомо нерабочий код, бо «пора домой, так и закончу» — это как называется?

    Євген Козлов Front-end developer в SoftServe 08.11.2014 00:51

    причем тут CI? вот, недописал я код. хочу продолжить дома.
    коммичу неполноценный код, запускается билд, который валится — об этом речь? и как это помогает?
    а как же история изменений — с «половинными» коммитами? или amend/rebase наше всё?
    я как-то краем глаза слышал про «атомарность изменений» и «работоспособность кода», как требования к коммитам. по-моему, довольно здраво.

    Євген Козлов Front-end developer в SoftServe 08.11.2014 01:56

    спецбранча «а тут обкусанные коммиты»? 🙂

    Створюй свій власний бранч із блекджеком і дамами і вперед. Крім того, я маю сумніви щодо того, що замовник буде радий факту заливки коду на дропбокс чи будь-куди (навіть синхронізація через VCS на домашній комп/ноут сумнівна). На додачу, наскільки великий репозиторій? Репозиторій може бути дуже великим, і твій код не буде працювати без залежностей. Їх також заливати?

    Як на мене, то варіант «залий на Дропбокс код із роботи щоб попрацювати» дуже малоймовірний. От для персонального проекту — можливо. Але я все одно віддаю перевагу GitHub, Visual Studio Online or Bitbucket

    Євген Козлов Front-end developer в SoftServe 08.11.2014 08:48

    Крім того, я маю сумніви щодо того, що замовник буде радий факту заливки коду на дропбокс чи будь-куди (навіть синхронізація через VCS на домашній комп/ноут сумнівна)

    в таком случае, чем github секьюрнее? только VPN + remote control на рабочую станцию.

    На додачу, наскільки великий репозиторій? Репозиторій може бути дуже великим, і твій код не буде працювати без залежностей. Їх також заливати?

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

    депенденси меняются, ну, оооочень редко

    Только бывает выходят новые версии зависимойстей. И довольно часто.
    Євген Козлов Front-end developer в SoftServe 08.11.2014 14:03

    если вы не глядя запускаете обновление депенденси, без объемного(из-за основательности) регрешна(автоматического или ручного, а лучше — и того, и того), каждый раз, как выходит новая версия — у меня для вас плохие новости.
    и да, под «изменениями» я имел в виду именно апдейты, а не «выкинем все библиотеки и возьмем за основу другие»

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

    Євген Козлов Front-end developer в SoftServe 09.11.2014 11:55

    ну? зачем в таком случае включать депенденси в репозиторий? 🙂
    включается только конфиг, так же?

    включается только конфиг, так же?

    Да, все верно. Я не пытался сказать, что зависимости нужно включать в репозиторий, наоборот. Возможно был неправильно понят :).

    Ivan M Software Engineer в Лідер ринку 08.11.2014 03:31

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

    RDP спасет отца русской демократии 🙂 Нечего чужой код на домашний комп копировать)
    Євген Козлов Front-end developer в SoftServe 08.11.2014 08:50

    Нечего чужой код на домашний комп копировать)

    it depends.
    кое-где даже RDP запрещено(ну, заблокировано) по причине паранойи. обоснованной или дутой — то уже отдельный вопрос.
    если охота обсудить вопросы безопасности применительно к абстрактному проекту с неизвестными policy — это без меня.

    Нечего чужой код на домашний комп копировать)

    Кому интересны фиксы индийских удобрений?
    Ivan M Software Engineer в Лідер ринку 11.11.2014 01:33

    Очень жаль что вам приходится работать с «фиксами индийских удобрений» 🙂

    Valentin Nechayev архімаггриб в Дарницькі печери 08.11.2014 09:46

    я как-то краем глаза слышал про «атомарность изменений» и «работоспособность кода», как требования к коммитам. по-моему, довольно здраво.

    Реально это не так, особенно в случае рабочих веток git, ибо
    1) в некоторых случаях он заставляет коммитить временное — когда из stash’а идут изменения на тот же файл, что уже локально изменён — соответственно, git add $file; git commit -m tmp
    2) за счёт переформатирования коммитов через interactive rebase в своих ветках можно коммитить любую ерунду, главное, чтобы потом оформить её уже _публично_ в виде аккуратной связной цепочки

    Євген Козлов Front-end developer в SoftServe 08.11.2014 11:18

    2) за счёт переформатирования коммитов через interactive rebase

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

    1) в некоторых случаях он заставляет коммитить временное — когда из stash’а идут изменения на тот же файл, что уже локально изменён — соответственно, git add $file; git commit -m tmp

    опять же, после этого вы этот коммит пушите? или откатываете, чтоб в коммит не попало что-то полурабочее?

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

    чтобы потом оформить её уже _публично_ в виде аккуратной связной цепочки

    речь о push и локальных коммитах, верно?
    а теперь, скажите, к теме топика: если мы используем github для синхронизации кода между разными машинами, придется ли нам пушить(т.е. «публиковать») полурабочий коммит с частью изменений? или локальный коммит на одной машине магическим образом перетечет на другую, где мы сможем доработать его и запушить?

    Valentin Nechayev архімаггриб в Дарницькі печери 10.11.2014 15:47

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

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

    опять же, после этого вы этот коммит пушите?

    или откатываете, чтоб в коммит не попало что-то полурабочее?

    Обычно удобнее всего откатить. Но во многих случаях удобнее, наоборот, докатить (добавить нужные файлы и сделать commit —amend с доведением сообщения коммита до пригодного публично).

    вы сейчас выдаете исключительные ситуации за правило.

    Ничего подобного. Можно делать так, что это будет только исключительной ситуацией. А можно автоматически коммитить каждую минуту и потом объединять сделанное во внятные цепочки. Сила инструмента не в том, как он сам работает, а в том, что он позволяет.

    придется ли нам пушить(т.е. «публиковать») полурабочий коммит с частью изменений?

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

    Євген Козлов Front-end developer в SoftServe 10.11.2014 16:40

    Можно пушить, а можно и нет

    и как без пуша это будет доступно на другой машине?
    Valentin Nechayev архімаггриб в Дарницькі печери 10.11.2014 16:53

    и как без пуша это будет доступно на другой машине?

    Любыми другими методами:) Но push в свою ветку — один из простых удобных методов.

    милом патч відправляти 😉
    git під це добре теж заточений 🙂

    Євген Козлов Front-end developer в SoftServe 14.11.2014 13:41

    ставим git
    недорабочий код формируем в патч
    высылаем себе на мыло
    на другой машине накатываем патч
    результат доработки опять формируем в патч
    и высылаем себе на мыло

    я ничего не пропустил?

    все правильно, тільки то все ж я пошуткував 🙂
    до речі, кількість пунктів можна скоротити/автомазитувати (за допомогою тих же bash/git alias, mail forward, etc)
    + є ще така штука як git bundle 😉

    але якщо серейозно, то я наприклад користуюсь (дещо вже зазначали вище):
    — окрема «своя» гілка (рідко)
    — окремий «свій» репо
    — direct push/fetch на/з потрібну машину (часто), хоча тут потрібен прямий зв’язок

    Євген Козлов Front-end developer в SoftServe 14.11.2014 15:32

    до речі, кількість пунктів можна скоротити/автомазитувати (за допомогою тих же bash/git alias, mail forward, etc)

    или дропбокс 🙂
    правда, там все же есть один недостаток — нет ничего типа .gitignore, и будет синкаться все подряд 🙁

    BTW спробуйте syncthing AKA pulse (now)
    вже на стадії “можна юзати”
    там є .stignore 😉
    да і backup/history

    Gennady Dogaev full-stack web developer (freelance) 08.11.2014 14:10

    Ветки отдельные для каждого разработчика + merge requests. Не уверен, но кажется что merge даже одним коммитом будет выглядеть

    Євген Козлов Front-end developer в SoftServe 08.11.2014 14:40

    к чему это вы написали?
    merge будет выглядеть либо коммитом, либо вообще никак не будет выглядеть, если fast-forward. но это технические детали.
    вы предлагаете использовать бранчи как именованный per-developer stash.
    и что это даст? какие достоинства в сравнении с синхронизацией незавершенных изменений через dropbox или bittorrent sync?

    Gennady Dogaev full-stack web developer (freelance) 08.11.2014 15:00

    к чему это вы написали?

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

    и что это даст? какие достоинства в сравнении с синхронизацией незавершенных изменений через dropbox или bittorrent sync?

    Нет особой разницы, кому что нравится.

    Для этих ситуаций и были придуманы бранчи. В чём проблема?

    Євген Козлов Front-end developer в SoftServe 09.11.2014 11:57

    локально — да.
    пролистайте выше: речь о синхронизации состояния проекта между разными компами. так что без push’a не реализуемо просто созданием веток.
    конечно, разве что вы предлагаете бросить в дропбокс сугубо папку .git, что совсем уже сурово

    rsync или ssh agent forwarding

    Vladislav Povedyuk Java Developer 07.11.2014 14:22
    Andriy Kuba Астронавт в Ciklum 07.11.2014 12:32

    я особисто працюю на двох машинах — робота\дім

    Документи:
    google drive, jira, confluens

    Різні дрібниці, пісочниці і т.д:
    drupbox, google drive

    Спеціальне середовище, наприклад приватний сервер для розробки з відповідними програмами:
    vagrant, скрипт якого в bitbucket\github

    Nickolay Kondratenko Developer в Svitla 07.11.2014 13:49

    я бы ещё добавил evernote

    только не гитхаб, а просто гит.

    Не слушай никого кто будет тебе парить github или bitbucket и прочую фигню. Надо архивировать исходники zip или rar и синхронизировать между машинами посредством электронной почты. Самый надежный и проверенный способ.

    5″ дюймовими дискетами, а архіватор arj краще.

    rar жмет лучше arj
    а дискеты лучше брать тогда уже 3.5 — они гораздо практичнее

    7z жмет еще лучше

    Во времена дискет 7z не было. Ты просто юмора не понял.

    Євген Козлов Front-end developer в SoftServe 14.11.2014 18:10

    это в 1999 не было-то? 🙂
    я как-то даже работающий дисковод на 5.25″ застал

    в только первая бета вышла. Так что, да, можно сказать что не было. А причем тут работающий дисковод?

    Євген Козлов Front-end developer в SoftServe 15.11.2014 18:31

    А причем тут работающий дисковод?

    в налоговую реально приносили отчеты на 5.25″ дискетах. чему и был свидетелем.
    UPD: ага, понял нюанс. «работающий» — не в смысле «рабочий, работоспособный», а в смысле «используемый»

    Тут явно какой-то misunderstanding. Я не утверждал что в не было дискет. Я сказал, что в то время, когда дискеты были в ходу — тогда еще не было 7z (это архиватор такой, если что), вышла только его первая бета.

    Євген Козлов Front-end developer в SoftServe 15.11.2014 19:00

    это я понял. и согласен. плохо помню.
    а комментирую только вопрос насчет дисковода на 5.25″

    Nickolay Kondratenko Developer в Svitla 07.11.2014 13:38

    Хотел предложить флешку, но дискета лучше
    Кстати, помню студенческие годы: project project_old project_new project_last project_final.. Кстати, может, именно этот опыт заставляет полюбить системы управления версиями?

    Vladislav Povedyuk Java Developer 07.11.2014 14:22

    !КУРСОВОЙ
    !!КУРСОВОЙ
    . ЗАПИСКА — ПЕЧАТЬ

    Oleg Kariakin Senior Java Developer 07.11.2014 12:44

    Есть еще лучше способ — копировать весь проект, а лучше всю эклипсу сразу между машинами. Также как при переключении на бранчу клонировать репозиторий еще раз в новую папку. 🙂

    Вот, тоже отличный метод. Спасибо, товарищ!

    Пам’ятаю колись всі лабораторні по Паскалю носилися на дискеті в одному каталозі з TP7.EXE. «Ставь класс єслі тоже так дєлал!»

    Maksym Leonidov Front-end developer в CreatorIQ 07.11.2014 12:45

    А чем это удобнее и надежнее использования github или bitbucket ?

    Это быстрее, проще и понятнее.

    Прям девиз из «а-ну-ка, мальчики!»

    Тем что ваш драгоценный код всегда с вами, а не где-то у проклятых пиндосов с их АНБ. Вы Сноудена читали? Вот почитайте.

    Да и, опять же: пушить, контрибутить и вот это всё — это совершенно чуждые понятия, насаждаемые нам госдепом.

    Valentin Nechayev архімаггриб в Дарницькі печери 15.11.2014 12:03

    электронной почты

    email дико неэффективен для дискет, правильно использовать FTN.

    малчык сюда хады тут рэпозыторый прыватный безплатно дам bitbucket.org

    Static IP + Remote desktop

    сударь знает толк ©

    у него все так по ходу, не перестает радовать парень

    Ты прикалываешся ? Это самый удобный способ. На одной тачке один раз всё скачал, установил, настроил. Потом если надо, допустим, поработать с работы, щелк щелк зашел работаешь. Уехал кудато далеко, в гостях у друга, в компьютерном клубе в другой стране, надо поработать. Щелк щелк на чужой машине, зашел работаешь. Не установив не единой левой тулзы на чужой машине, все стандартными средствами. Нужно по внутренней сеточке полазить, чтото кудато переписать. Раз два и готово. Да даже я ехал недавно в поезде, на мобиле установил Remote Desktop, зашел с мобилы на свой комп и тоже посмотрел результаты тестов, поклацал, сервиса кое какие перезапустил.

    Постоянно синхронизироваться это изврат. Многие конторы уже давно на облачных хостингах работают.

    У VCS історія коду зберігається. Легко відкочуватись до попередньої версії, якщо щось поламалось. А ви як цю проблему вирішуєте? FooBar2014-10-07.cpp.backup, а в ньому

    /* // Uncomment if something went wrong void foo() < . >*/

    Хоча це звісно теми прямо не стосується. Але після того, як звикнеш до Git, складно казати, що RDP може бути краще за нього навіть суто для синхронізації.

    git, svn, mercury, vss и прочьи приблуды в основном нужны, когда над проектом работает команда разработчиков. Им нужно синхронизировать исходники, отслеживать кто что менял и тд. Если разработчик один работает над одним проектом, то его польза стремится к нулю. Проще раз настроить ремоут дексктоп и работать с любой точки земного шара где есть интернет. Вплоть до мобильных устройств.
    Если работаешь с сложным проектом, то ремоут десктоп просто необходимость. Поскольку кроме исходников, чтобы запустить и чтото протестировать нужно быть внутри удаленной сети, где разные сервера взаимодействуют друг с другом. Настроить это все повторно на домашнем компе это мазохизм высшей степени.

    Ви кого зараз у цьому хочете переконати? Тих, хто ніколи не використовував системи контролю версій?

    Повторюся, я відхилився від теми, бо якщо питання тільки у роботі над одним кодом із різних пристроїв, то можливо ваше рішення і зручніше. Але з git’ом приходять такі можливості, від яких потім не захочеш відмовлятись. Хоча ніхто не заважає й поєднувати. Можна мати локальний git-репозиторій на RDP суто для контролю версій, а не синхронізації.

    Навіть якщо розробник один, йому все одно потрібно відстежувати зміни в своєму коді. Без VCS це зазвичай виливається у купу сміттєвих бекап-файлів та простирадла закоментованого коду «про всяк випадок». Був там, знаю. Чи у вас не так?

    Да многие проекты вы просто не запустите без ремоут десктоп. Я приведу пример. У нас был очень слабый канал с заказчиком, чтобы стянуть коследний код через vss, последнюю версию к себе на компьютер, нужно было час курить. Вместе с тем, ремоут десктоп ест реально копейки. Он даже вполне себе сносно работает на мобильных gprs каналах. А такими интернетом покрыта вся Украина, по тарифу гривна в день.

    Valentin Nechayev архімаггриб в Дарницькі печери 08.11.2014 09:48

    Самое смешное тут — слово vss. Это такое чудо, что даже CVS по сравнению с ним — вершина прогресса.

    С полезностью RDP в принципе согласен, но если этот RDP называется ssh+screen 🙂

    Я би у вашій формулі замінив screen на tmux. А для нестабільного grps можна використовувати Mosh (так вони пишуть, сам не користував).

    Але логіка пана Booben Com, судячи з усього, прив’язана до OS Windows.

    Valentin Nechayev архімаггриб в Дарницькі печери 08.11.2014 10:22

    Я би у вашій формулі замінив screen на tmux.

    Я попробовал tmux, расплевался и больше не хочу. У него единственное преимущество — более ясный код, функционально же он хуже почти во всём. Может, лет через 5 он будет приличным.

    Про Mosh не слышал, посмотрю на досуге.

    Але логіка пана Booben Com, судячи з усього, прив’язана до OS Windows.

    Ну, часто заказчика и платформу не выбирают. При этом заказчик может и выдвигать требования типа “код в VSS”. Собственную логику таки надо смотреть на собственных проектах.

    функционально же он хуже почти во всём.

    — хочу знати більше, тому що, наприклад, вертикальний split у screen досі робиться тільки патчем.
    Valentin Nechayev архімаггриб в Дарницькі печери 09.11.2014 15:57

    Поставил, посмотрел на свежий. Да, за два года продвинулось — уже есть почти всё, что нужно:) Но вот ряд принципиальных ляпов убивает возможности его использования. У меня местами до 3 уровней вложенности сессий, с разными переключателями. В screen это тривиально — сказал “screen -e^oa” на нужном уровне, и поехал работать. В tmux этот переключатель числится как глобальная опция на уровне сервера (а нахрена. ), и начинается дикий изврат.
    Не видно force detach, и особенно комбинаций типа -Dr. Для attach нет режима “подцепиться к первой попавшейся сессии данного юзера, или обломиться, если свободных нет”, который очень удобен и который в screen по умолчанию.
    Не видно варианта “вместо status line на экране использовать xterm caption”, по умолчанию эта status line включена и жрёт дорогое место.

    тому що, наприклад, вертикальний split у screen досі робиться тільки патчем.

    Ни разу такое не было нужно.:) Но если нужно — патч легко ищется и доступен.

    У меня местами до 3 уровней вложенности сессий, с разными переключателями.

    — да, згоден, я не знаю рішення, яке б дозволяло не клацати Ctrl-B кожен раз потрібну кількість разів.

    Не видно force detach

    — а що таке force detach?

    Для attach нет режима “подцепиться к первой попавшейся сессии данного юзера, или обломиться, если свободных нет”

    — what? Якщо просто робити `tmux attach`, то буде підключатись перша незаттачена сесія, інакше команда обломиться і заявить про “no tmux server”.

    status line включена и жрёт дорогое место

    — залежить від розміру термінала; я стараюсь використовувати побільше екранного простору, тому навіть у screen включав status line автоматично, щоб знати, чи я у screen без зайвих команд (а місця мені не жаль).

    Ни разу такое не было нужно.:)

    — не знаю, не знаю, коли у мене великий термінал (на робочому $x$ доходить до 450×60), це життєво важлива фіча. Крім того, я більше люблю panes (ділянки, видимі одночасно), ніж “вкладки”: так видно одразу все без перемикання.

    Коротше, я зрозумів, що кожному свої юзкейси, і що tmux краще для великих екранів, а screen на класичному 80×25.

    Мені ще в tmux не подобаються дефолтні клавіші, і я також люблю перемикання по Ctrl-A і h/j/k/l між panes, але це лікується елементарно.

    Valentin Nechayev архімаггриб в Дарницькі печери 09.11.2014 21:10

    — а що таке force detach?

    Это с попыткой завершения родителя для клиентского процесса.

    — what? Якщо просто робити `tmux attach`, то буде підключатись перша незаттачена сесія, інакше команда обломиться і заявить про “no tmux server”.

    1. В мане этого не описано, или описано как-то невнятно. 2. А почему “no tmux server”, что за нелепая диагностика?

    і що tmux краще для великих екранів, а screen на класичному 80×25.

    Вполне возможно. Хотя я и на больших, если бывают, предпочитаю screen:)

    і я також люблю перемикання по Ctrl-A і h/j/k/l між panes, але це лікується елементарно.

    Ctrl+A это диверсия, а насчёт “элементарно” сами выше признались, что это в удобном варианте невозможно.

    Євген Козлов Front-end developer в SoftServe 08.11.2014 08:54

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

    одно другому не мешает.
    репозиторий делать доступным через интернет, действительно, не обязательно в таком случае. но он, репозиторий, все равно несет офигенную пользу.
    1. создает историю — и позволяет вернуться к коду на какую-то дату.
    2. структурирует историю — правки сгруппированны по смыслу(а не как в бекапе), в идеале сопровождаются датой правки и комментом.
    3. добавляет возможностей по мониторингу проекта — и поддержанию его здоровья. всякие там хуки с проверками на закоммиченные дебаг-конструкции сэкономят время и нервы. например.
    4. ветки позволять переключаться между кодом по незавершенным задачам(вот, здесь, без репо вообще не разрулиться)

    Valentin Nechayev архімаггриб в Дарницькі печери 08.11.2014 10:00

    Если разработчик один работает над одним проектом, то его польза стремится к нулю.

    Вы, видимо, никогда ещё не сидели над собственным кодом годовой давности с вопросом «а какой $удак это написал и почему?» Или же Вы гений (я не из лести, просто судя по тому же поисковику, есть действительно высочайший уровень в некоторых направлениях) — но гению очень часто сложно понять «простых» коллег и их сложности. «Узок их круг, страшно далеки они от народа» ©.

    Я для себя ещё с первых доступных SCM средств (RCS, CVS) нашёл, что даже для персональной разработки они очень полезны. При длительной истории сложно вспомнить, какой фактор и почему способствовал конкретному изменению и особенно результату — можно считать, что это вариант коллективной работы себя текущего с себя прошлым (причём, таких прошлых обычно несколько, каждые полгода, считай, уже заметно другой человек). Это уж не говоря про то, что эти средства существенно помогают операциям типа перетащить правильный фикс из одного бранча/трейна в десяток других (тоже нормально даже при персональной разработке — представьте себе программу, которая стоит у десятка клиентов, но у каждого подхачена по-своему).

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

    Ещё крайне полезно не лениться и тратить на каждый коммит всего несколько минут на подробное объяснение, что в нём делается и особенно почему (отличнейшим примером тут является LKML, можно прямо на курсах разработки заставлять подписаться на него и внимательно читать хотя бы пару десятков писем каждый день). Уже через год видна польза, а через 5 неиспользование такого начинает быть фатальным.

    Давайте взглянем на проблему с другой стороны. Человек завел свой пет проджект, у него нет десятка клиентов. У него просто есть маленькая проблема, он когда приходит на работу хочет работать над тем, что у него было дома. Вот и вся его проблема. Именно так топикстартер описывает проблему. И вы ему советуете, установи джит, устани дропбокс, настрой. Сколько он потратит на это времени ? Не глупо будет если в приложении чуть сложнее хелоуворда, которое через неделю возможно вообще будет заброшено, с одним разработчиком, человек будет тратить время на все эти шорохи, на ведение документации, истории изменений ? Если нужно зафиксировать версию ничего не мешает скопировать папочку в архив, написать дату. Если чтото не получилось, у тебя есть версия куда ты можешь откатиться. Это в разы проще чем тратить время постоянно на чекины и синхронизацию. И только когда в проете два и более человек, причем которые чекинят в одно и тоже место, есть очень серьезная потребность в контроле версий.

    Valentin Nechayev архімаггриб в Дарницькі печери 09.11.2014 16:36

    И вы ему советуете, установи джит, устани дропбокс, настрой. Сколько он потратит на это времени ?

    Про дропбокс я ничего не говорил, достаточно банального локального git. (Ну, а бэкапы нужны везде и всегда.) А установить git это даже на Windows сейчас не особо сложно, а на любом Unix (включая Apple системы) вообще делается вполпинка.
    (Заодно хочу заметить, что произносится «гит», а не «джит», даже на английском. Хотя это минимальная из поднятых проблем.)

    Я вот сегодня на винде codelite поставил, тот в себе подтянул сразу clang, mingw (4.8.1), git клиента и ещё несколько вкусностей — сам, из коробки.

    Не глупо будет если в приложении чуть сложнее хелоуворда, которое через неделю возможно вообще будет заброшено, с одним разработчиком, человек будет тратить время на все эти шорохи, на ведение документации, истории изменений ?

    Простите, какая такая документация и особенная история? «git commit -a -m current» на каждый поход на перекур в юниксовом шелле или виндовом IDE не просто, а безнадёжно просто.

    Если нужно зафиксировать версию ничего не мешает скопировать папочку в архив, написать дату.

    А это уже сложнее того, что я описываю.

    Это в разы проще чем тратить время постоянно на чекины и синхронизацию.

    Для описанного тривиального юзкейса нет никаких затрат времени, особенно «на синхронизацию».

    Про дропбокс я ничего не говорил, достаточно банального локального git.

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

    Я вот сегодня на винде codelite поставил, тот в себе подтянул сразу clang, mingw (4.8.1), git клиента и ещё несколько вкусностей — сам, из коробки.

    А с ними и новых багов натянул.

    Простите, какая такая документация и особенная история? «git commit -a -m current» на каждый поход на перекур в юниксовом шелле или виндовом IDE не просто, а безнадёжно просто.

    Зашел на stackoverflow, забил слово git.
    47,824 вопросов. Люди спрашивают поди от безнадежной простоты git.
    Причем заметьте, я не против контроля версий, это стандарт. Но стандарт в многопользовательских проектах. Не глупо будет потом постить очередной вопрос на stackoverflow, вместо того чтобы работать над сутью проекта ?

    Для описанного тривиального юзкейса нет никаких затрат времени, особенно «на синхронизацию».

    Ну как нет если есть.
    Get last version. И по сети потянул последнюю версию которая была у тебя дома.

    Valentin Nechayev архімаггриб в Дарницькі печери 09.11.2014 17:44

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

    git хорош тем, что если это всё не использовать, а ограничиться простейшими add/commit/log, можно никогда в эту сложность не лезть, и всё равно получать от него необходимую функциональность.

    Зашел на stackoverflow, забил слово git.
    47,824 вопросов. Люди спрашивают поди от безнадежной простоты git.

    Не глупо будет потом постить очередной вопрос на stackoverflow, вместо того чтобы работать над сутью проекта ?

    Глупо. Потому что постить вопрос будет не за чем — всё будет работать безо всяких вопросов. Хотя если кто захочет при наличии свободного времени и настроения попробовать что-то новое за пределами основных потребностей, почему бы и нет?

    Ну как нет если есть.
    Get last version. И по сети потянул последнюю версию которая была у тебя дома.

    Так что не так в данном случае? Возможность потянуть не просто каталог с исходниками, а такой же каталог, где ещё и история, не даёт никакого усложения, но даёт историю.

    Похожие публикации:

    1. Pragma hdrstop c что это
    2. Как написать скрипт для windows
    3. Как настроить cloudflare warp
    4. Что сильнее воздух или вода