Check Levi9 best QA positions to Backbase team!
×Закрыть

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

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Лучшие комментарии пропустить

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

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

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Можете спробувати ще syncthing (pulse)
github.com/...thing/syncthing

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

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

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

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

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

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

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

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

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

Якщо працюєш сам: Google Drive, Dropbox
Месье знает толк в извращениях

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

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

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

Этот комментарий удален правообладателем.

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

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

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

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

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

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

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

включается только конфиг, так же?
Да, все верно. Я не пытался сказать, что зависимости нужно включать в репозиторий, наоборот. Возможно был неправильно понят :).
вот, недописал я код. хочу продолжить дома.
RDP спасет отца русской демократии :) Нечего чужой код на домашний комп копировать)
Нечего чужой код на домашний комп копировать)
it depends.
кое-где даже RDP запрещено(ну, заблокировано) по причине паранойи. обоснованной или дутой — то уже отдельный вопрос.
если охота обсудить вопросы безопасности применительно к абстрактному проекту с неизвестными policy — это без меня.
Нечего чужой код на домашний комп копировать)
Кому интересны фиксы индийских удобрений?

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

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

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

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

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

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

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

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

к чему это вы написали?
К тому, что проблема коммита незавершенных изменений решаема, причём довольно легко.
и что это даст? какие достоинства в сравнении с синхронизацией незавершенных изменений через dropbox или bittorrent sync?
Нет особой разницы, кому что нравится.

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

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

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

Код:
bitbucket, github

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Весело было же)))

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

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

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

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

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

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

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

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

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

???

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

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

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

Ты прикалываешся ? Это самый удобный способ. На одной тачке один раз всё скачал, установил, настроил. Потом если надо, допустим, поработать с работы, щелк щелк зашел работаешь. Уехал кудато далеко, в гостях у друга, в компьютерном клубе в другой стране, надо поработать. Щелк щелк на чужой машине, зашел работаешь. Не установив не единой левой тулзы на чужой машине, все стандартными средствами. Нужно по внутренней сеточке полазить, чтото кудато переписать. Раз два и готово. Да даже я ехал недавно в поезде, на мобиле установил 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 каналах. А такими интернетом покрыта вся Украина, по тарифу гривна в день.

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

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

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

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

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

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

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

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

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

функционально же он хуже почти во всём.
— хочу знати більше, тому що, наприклад, вертикальний split у screen досі робиться тільки патчем.

Поставил, посмотрел на свежий. Да, за два года продвинулось — уже есть почти всё, что нужно:) Но вот ряд принципиальных ляпов убивает возможности его использования. У меня местами до 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 без зайвих команд (а місця мені не жаль).
Ни разу такое не было нужно.:)
 — не знаю, не знаю, коли у мене великий термінал (на робочому ${COLUMNS}x${LINES} доходить до 450×60), це життєво важлива фіча. Крім того, я більше люблю panes (ділянки, видимі одночасно), ніж “вкладки”: так видно одразу все без перемикання.

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

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

— а що таке 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 это диверсия, а насчёт “элементарно” сами выше признались, что это в удобном варианте невозможно.

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

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

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

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

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

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

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

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

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

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

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

См. выше.

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

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

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

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

Remote Desktop может быть весьма полезен (хотя на любителя, я лично не люблю держать комп включенным без присмотра), но насчёт Git только для команды — Вы неправы. Какие преимущества он даёт:
1) Ветки. Бывает такое, что сел делать задачу, на которую отведена неделя или больше, и вдруг нужно срочно переключиться на другую (баг пофиксить например). Делать это без системы контроля версий — повеситься можно.
2) Иногда забываешь когда написал «вот эту строчку» и зачем. В этом случае также помогает Git.

Мне проект в котором работает 1 (один) человек и при этом подключены разные Git, Dropbox и прочье напоминает фирму, где работает один плиточник но при этом существует отдел по оптимизации продаж, менеджер по связям, директор, три секретарши и два бухгалтера. ЗАЧЕМ топикстартеру тратить время на эту бюрократию в проекте, если он один работает над этим проектом ? Неужели не проще просто поставить галочку, разрешить уделанный доступ к компьютеру, поставить надежный пароль и забыть за весь этот гемор с синхронизациями и прочьей потерей времени. Ведение документации ради ведения документации. Для чего тратить 20% своего времени на какието бесполезные монкей чекины и раз за разом стягивание версий с сторонних серверов для синхронизации ?

1) Ветки. Бывает такое, что сел делать задачу, на которую отведена неделя или больше, и вдруг нужно срочно переключиться на другую (баг пофиксить например). Делать это без системы контроля версий — повеситься можно.
2) Иногда забываешь когда написал «вот эту строчку» и зачем. В этом случае также помогает Git.

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

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

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

На каждую строку по комментарию с описанием задачи или один комментарий с описанием задачи (или вообще ссылкой на трекер) в Git?

Для чего на каждую строчку ? Там где это требуется.
Я вообще не встречал, где комитят каждую строчку кода с очень подробными коментариями даже на рабочих многопользовательских проектах.

более старую версию установил клиент, работа пошла над новой версие, но клиенту не нужно ждать новую версию а нужно срочно чтото исправить в той старой.
А в новой баг пусть остаётся? Если он в старой есть — он и в новой есть. Как в новую переносить фикс? Руками не особо продуктивно.
Для чего на каждую строчку ? Там где это требуется.
Так вот прямо сейчас пишешь — всё понятно (такого чтобы было непонятно написанное минуту назад я не встречал). Через полгода — не помнишь зачем это тут и что оно делает.
А в новой баг пусть остаётся? Если он в старой есть — он и в новой есть. Как в новую переносить фикс? Руками не особо продуктивно.

Каждый случай индивидуален. В новой версии вообще может быть все по новому или переписано. Наивно думать что за тебя контроль версий может пофиксить в «автоматическом режиме»

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

Но в >90% случаев это так. И автоперенос патча решает эту проблему.

git, svn, mercury, vss и прочьи приблуды в основном нужны, когда над проектом работает команда разработчиков.
— я вважаю, що git, svn, hg та інші приблуди не потрібні в основному тоді, коли вашим продуктом користується тільки одна людина.

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

ну раз пошел такой разговор, то чем teamviewer плох? :)

google: git, mercurial; github, bitbucket, gitlab;
І постав android studio замість екліпса.

Github.com

Eclipse лучше заменить на Andoid Studio — там есть встроенная поддержка различных VCS, что упростит процесс синхронизации кода.

Bitbucket с бесплатными приватными репами или гитлаб с тем-же. Довольно удобные сервисы для этого, и в самом эклипсе поддерживаются )))

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

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

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

Также можно разместить на дропбоксе репозиторий. Минус остаётся — в локальную папку мы-то запушим быстро, а синхронизация занимает время. Для количества разработчиков > 1 однозначно не пойдёт. Плюсов явных не вижу. Приватный репозиторий можно и на битбакете получить

А можна git init --bare в папці на дропбоксі, потім git clone ~/Dropbox/myproject.git ~/code/myproject і поєднати таким чином одне з іншим. Сто раз так робив для проектів, де я був єдиний розробник. І код не пропаде, якщо жорсткий диск зламається, і історія комітів є, і синхронізуватись з різних машин можна. Теоретично можна і в команді так працювати, але це вже трохи збочення.

Bitbucket звісно «же», але якщо питання командної розробки взагалі не стоїть, то чом би й не дропбокс.

А чом би не мати історію та зручний бранчінг?

Так ніхто ж не боронить! Я писав про локальний remote (ха-ха, оксюморон) в папці на Dropbox. Штовхаєш в локальний каталог, а Dropbox займається синхронізацією. Коли працюєш сам, то в такій схемі відмінностей із bitbucket не так і багато. Якби хоча б у bitbucket був пошук по коду, як на github, то був би якийсь плюс. Але Atlassian не надто квапляться закривати цей feature request.

Подписаться на комментарии