Вся децентрацизация крутится вокруг обмена патчами:
— Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
— Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
— Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
— Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am
Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.
> вы пробовали пользоваться другими DVCS
Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.
> за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
Нет, думать нужно прежде чем пушиться. А со своими локальными правками, которых еще никто не видел, я буду делать все, что захочу.
> через пару часов использования git сломал нафиг и локальный
Подскажи рецепт, любопытно.
> Мучался с ребятами 2 недели
Работать полноценно я начал сразу, а вот выработать стратегию командной разработки, мерджа веток. Мы еще тогда начали работать через систему форков и пул-реквестов на гитхабе. Вот пока разобрались со всем и отказались от такого подхода и прошло это время.
> которую не пинал только ленивый
И буду пинать — до черта людей дальше SVN не видят.
> где-то месяца 4 воевал с git
А я не воевал, а радовался во всю. В чем подвох?
> Git — далеко не лучший представитель этого семейства
А почему бы не написать свой обзор? Я бы почитал с удовольствием.
Про ограничение доступа:
Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.
> Работа над несколькими проектами с общими компонентами
см. git help submodule
В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.
> И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши.
Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
Лучшее — враг хорошего. Это как раз такой случай.
Лучше оставить систему очень простой и дописать соглашение, чем неоправданно усложнять и возможно получить новые грабли.
Теоретически можно, если еще опустить вопросы очередности выполения, и сложных/множества запросов для data migration. А как тогда быть с номером версии БД. Может получится так, что написали одну миграцию, а номер скакнул на 10. А не скакать нельзя — это ролбек. Да и с ролбеком будут проблемы.
Нет, плохая идея.
Это на совести разработчика и мануала с best practice
Это уже недостатки текущей реализации. Единственную сложность, которую я вижу, это невозможность автоматом откатить сложную миграцию, если она упала.
А ваш товарищ, наверное, пришет атомарные миграции.
Все остальное есть куда допиливать, если еще не допилили во второй доктрине.
> Ей Богу, проще ручками в базе поправить, полученный SQL-код записать в отдельный sql-файл и, при случае, использовать. Меньше проблем, меньше времени, ничего не надо изучать.
Я про то и писал, что на определенном уровне разработке это намного сложнее, чем использовать миграции.
Нет. Я не уверен, надо посмотреть исходники, но доктрина оборачивает миграцию в транзакцию и это не спасает. Еще я не знаю дружат ли ALTER и CREATE TABLE с транзакциями. Надо порыться в доке к БД. Или может кто подскажет?
— Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
— Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
— Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
— Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am
Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.
Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.
> за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
Нет, думать нужно прежде чем пушиться. А со своими локальными правками, которых еще никто не видел, я буду делать все, что захочу.
> через пару часов использования git сломал нафиг и локальный
Подскажи рецепт, любопытно.
> Мучался с ребятами 2 недели
Работать полноценно я начал сразу, а вот выработать стратегию командной разработки, мерджа веток. Мы еще тогда начали работать через систему форков и пул-реквестов на гитхабе. Вот пока разобрались со всем и отказались от такого подхода и прошло это время.
> которую не пинал только ленивый
И буду пинать — до черта людей дальше SVN не видят.
> где-то месяца 4 воевал с git
А я не воевал, а радовался во всю. В чем подвох?
> Git — далеко не лучший представитель этого семейства
А почему бы не написать свой обзор? Я бы почитал с удовольствием.
Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.
> Работа над несколькими проектами с общими компонентами
см. git help submodule
В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.
Могут напрямую через ssh
Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
git add path/to/file
Не получается сейчас, можно придти в следующий раз.
Я планирую регулярно проводить встречи, поэтому всегда будет возможности придти.
Лучше оставить систему очень простой и дописать соглашение, чем неоправданно усложнять и возможно получить новые грабли.
Нет, плохая идея.
Это на совести разработчика и мануала с best practice
А ваш товарищ, наверное, пришет атомарные миграции.
Все остальное есть куда допиливать, если еще не допилили во второй доктрине.
> Ей Богу, проще ручками в базе поправить, полученный SQL-код записать в отдельный sql-файл и, при случае, использовать. Меньше проблем, меньше времени, ничего не надо изучать.
Я про то и писал, что на определенном уровне разработке это намного сложнее, чем использовать миграции.