В первый раз отсоединенный коммит (особенно, когда его не ожидаешь) — это страшно )
Но это от непонимания что к чему.
На самом деле, ничего страшного в нем нет.
Почему же нет веток? У меня есть.
У меня по процессу 4 постоянных ветки и я в любой момент могу делать сколько угодно новых — под конкретные фичи. И все это элементарно и беспроблемно таскается из ветки в ветку, меняется местами и сводится. Я в любой момент могу решить, что войдет в апдейт, что отложить, что выложить частично, например. Не представляю, что может быть гибче.
Мерджи я по процессу совсем исключил. Они слишком мусорят историю. Все делаю ребэйсом. Даже пулл — с опцией ребэйса. Так же удобно собирать коммиты (если случилось, что по одной задаче их получилось несколько) в один интерактивным ребэйсом.
А что из какой ветки пришло сохраняется при слиянии функционала после ребэйса уже мерджем с --no-ff.
История всегда идеальна и прозрачна.
Распределенность же есть не просит.
Можете просто ее не использовать. По опыту работы 90% пользуются одним центральным репозиторием.
Но на самом деле, это удобно — у вас один репозиторий, у клиента — свой и вы можете обмениваться правками работая каждый со своей логикой и своим процессом. Мне лично очень нравится эта гибкость.
SVN была ужасной системой. Медленной, с плохой работой веток,… (tree-конфликты как вспомню, так вздрогну).
Пока не переехали на Git было очень много сложностей с командной работой над большим проектом с длинными параллельными разработками.
Wordpress на момент появления был лучшим движком. Чему удивляться.
Хотя, если честно, я его всегда недолюбливал.
Все претензии к нему от того, что новостной движок пытаются использовать для разработки сайтов и магазинов. Просто не надо этого делать и он будет вполне сносен.
А какие опенсорсные движки сейчас лучше? Просто интересно.
По моему, все недовольство git'ом вызвано как раз использованием GUI-оболочек.
Оболочки еще больше запутывают и без того «странноватый» синтаксис git'а. А понимание логики работы приходит только когда работаешь с git'ом напрямую через консоль.
если пользоваться черепахой, то конечно, гит покажется недружелюбным. Git идеален а консоли — только так понимаешь, как именно он работает, и почему это правильно.
Знаю, что есть, но не возникает желания или необходимости мигрировать. Зачем, если все отлично работает?
И то, что именно git стал на сегодняшний день мэйнстримом, только подтверждает, что большинство придерживается того же мнения.
Git настолько восхитителен, когда его понимаешь, что не представляю, что может быть лучше.
Если вы не умеете его готовить, то это не означает, что он не вкусный.
в «большой команде» — 10.
Проектов — крупных 4, но есть еще мелкие, они пока вне скрама. Проекты не пересекаются. По каждому проекту свой бэклог и свои спринты.
Часть разработчиков (тестировщики, верстальщики) работают по разным проектам (либо целый спринт, либо полспринта тут, полспринта там).
Программисты выделенные под проект.
Есть ощущение, что команды по проектам должны вырасти и тогда уже каждая команда сама по себе + скрам над скрамом.
У нас одна user story включает полный цикл — от проектирование — дизайн — верстка — программирование — тестирование.
Пока разбиваем на подзадачи, выставляем зависимости и оцениваем каждую.
Очень знакомо. Практически 1 в 1.
Тоже вводится не все сразу, а постепенно. Проходим по тем же граблям.
У нас проблемное место — несколько разных проектов и с этим реально головная боль. Одной большой командой работать не получается.
Человек одним из первых (и первым из сколько-нибудь популярных) музыкантов в этой стране раздает свою музыку бесплатно. А зарабатывает на концертах, причем не чесом по стадионам, а в большей части камерными, практически квартирниками.
При этом привлекает к работе известнейших мировых музыкантов и продюсеров и записывает альбомы в отличных студиях.
Давно пора было собирать средства. Рад, что и там это поняли.
Это лучший пример «пускания своего хлеба по воде».
Но это от непонимания что к чему.
На самом деле, ничего страшного в нем нет.
У меня по процессу 4 постоянных ветки и я в любой момент могу делать сколько угодно новых — под конкретные фичи. И все это элементарно и беспроблемно таскается из ветки в ветку, меняется местами и сводится. Я в любой момент могу решить, что войдет в апдейт, что отложить, что выложить частично, например. Не представляю, что может быть гибче.
Мерджи я по процессу совсем исключил. Они слишком мусорят историю. Все делаю ребэйсом. Даже пулл — с опцией ребэйса. Так же удобно собирать коммиты (если случилось, что по одной задаче их получилось несколько) в один интерактивным ребэйсом.
А что из какой ветки пришло сохраняется при слиянии функционала после ребэйса уже мерджем с --no-ff.
История всегда идеальна и прозрачна.
Можете просто ее не использовать. По опыту работы 90% пользуются одним центральным репозиторием.
Но на самом деле, это удобно — у вас один репозиторий, у клиента — свой и вы можете обмениваться правками работая каждый со своей логикой и своим процессом. Мне лично очень нравится эта гибкость.
Пока не переехали на Git было очень много сложностей с командной работой над большим проектом с длинными параллельными разработками.
Хотя, если честно, я его всегда недолюбливал.
Все претензии к нему от того, что новостной движок пытаются использовать для разработки сайтов и магазинов. Просто не надо этого делать и он будет вполне сносен.
А какие опенсорсные движки сейчас лучше? Просто интересно.
Оболочки еще больше запутывают и без того «странноватый» синтаксис git'а. А понимание логики работы приходит только когда работаешь с git'ом напрямую через консоль.
И то, что именно git стал на сегодняшний день мэйнстримом, только подтверждает, что большинство придерживается того же мнения.
Если вы не умеете его готовить, то это не означает, что он не вкусный.
Но по ощущениям — более продуктивно с утра — в самом начале рабочего дня — настраивает разработчиков на работу.
Проектов — крупных 4, но есть еще мелкие, они пока вне скрама. Проекты не пересекаются. По каждому проекту свой бэклог и свои спринты.
Часть разработчиков (тестировщики, верстальщики) работают по разным проектам (либо целый спринт, либо полспринта тут, полспринта там).
Программисты выделенные под проект.
Есть ощущение, что команды по проектам должны вырасти и тогда уже каждая команда сама по себе + скрам над скрамом.
Пока разбиваем на подзадачи, выставляем зависимости и оцениваем каждую.
Тоже вводится не все сразу, а постепенно. Проходим по тем же граблям.
У нас проблемное место — несколько разных проектов и с этим реально головная боль. Одной большой командой работать не получается.
При этом привлекает к работе известнейших мировых музыкантов и продюсеров и записывает альбомы в отличных студиях.
Давно пора было собирать средства. Рад, что и там это поняли.
Это лучший пример «пускания своего хлеба по воде».