HoBTIDНахлобучНу вот есть у нас задача, под нее ветка, и в эту ветку коммитят дизайнер и девелопер. Получаем ровно ту же ситуацию: я не могу сделать локальный Update не рискуя потерять свои изменения. По логике тех, кто знает только SVN, вы должны были сделать 2 ветки: для себя и для дизайнера, и иметь счастье мерджиться чтобы проверить любое изменение дизайна.Вообще-то, "по логике" надо бы на каждое изменение дизайна (или реалиации функции) делать отдельную ветку, а в конце все ветки должны быть слиты в финальную... И при этом следует не забывать, что часть из этих веток в "финал" никогда не пойдет...

HoBTIDsphinx_mvВообще-то, "по логике" надо бы на каждое изменение дизайна (или реалиации функции) делать отдельную ветку, а в конце все ветки должны быть слиты в финальную...
И при этом следует не забывать, что часть из этих веток в "финал" никогда не пойдет...Прекрасный совет, как не надо делать. Впрочем так никто и не делает, из-за слишком большой трудоемкости данного метода."Проблемы индейцев шерифа не волнуют" (с)
Невменяемые трудности подобной методики на SVN - это к Git'у совершенно никаким боком не относится.
Потому что нет никакой трудоемкости в этом при работе с Git. То есть - ВООБЩЕ! :)

Три-четыре варианта реализации некоторого нетривиального функционала - вполне реальная ситуация.
И иметь ветки под каждый из вариантов - очень неплохо рулится. С использованием Git.
Переключение с ветки на ветку - пальцы даже не надо мочить. Даже коммитить текущую работу перед этим нет необходимости.

"Увлекательное чтиво", например, тут ...

HoBTIDКонечно же, нет проблем с такой методикой, если вы используете Git , здесь она как раз является основной :-)
На самом деле это не зависит от того, каким средством контроля версий пользуется разработчик.
Просто одни средства контроля и управления версиями позволяют это делать легко, а в других это весьма геморройно...

ИМХО (банально): минимальное количество веток при разработке - количество активных разработчиков/дизайнеров. Команда в 50-100 человек - это не много. Плюс ветки для тестов, релизные и т.п. И всем этим "хозяйством" нужно как-то управлять.
HoBTIDНу единственное, что в случае тривиальных изменений все равно проще вносить их в одну ветку.Критерий "тривиальности" - в студию! :)
Особенно в свете того, что логически, одна ветка - набор последовательных изменений кода.
Если изменения должны некоторое время "жить" параллельно - вот вам и выделение ветки...

nolockyТем не менее, эта проблема больше надумана, ибо в реальной жизни (после запуска в продакшин) переименовывание уже почти не встречается, и всякие backmerge проходят на ура.К вопросу о "надуманности"... В реальной жизни...
Сколько версий проходит, пока проект попадает в продакшн? :)

nolockysphinx_mvпропущено...
К вопросу о "надуманности"... В реальной жизни...
Сколько версий проходит, пока проект попадает в продакшн? :)

Пока проект не в продакшине, ему тонкие материи вроде бренчевания и (бек)мержинга нафиг не впились.
Можно веселиться просто как хочется, используя VCS просто как эдакую разновидность сетевой шары для бекапов.
Грустный подход...
Еще на этапе согласования техзадания на разработку вылезает не один десяток версий документов - составная часть проекта, однако, к котрой должны иметь доступ все участники разработки.... И правку учиняет много больше одного человека... И расстояние между местами внесения изменений бывает очень не одна тысяча км...
Но контроль версий не нужен... Совсем... Сто пудов...
nolockyПо большому счету любая VCS - это ограничение, как и тесты. Потому прототип обычно делается одним-двумя мегамонстрами, без тесной кооперации, без тестирования - все для того, лишь бы получить что-то хоть как-то работающее на ранней стадии.
Откройте для себя TDD - разработка через тестирование. И тесты начинают писать на этапе, когда до работающего прототипа еще весьма не близко... Не говоря уже о релизах...
nolockyИ уже потом, на стадиях стабилизации перед релизом - оно обрастает и тестами, а после релиза - вот тогда VCS становится уже обязательной - чтоб просто саппортить зарелизенное, чиня там баги в предыдущих версиях, и не терять эти починки в текущей девелоперской версии.А от работающего прототипа до релиза сотня разработчиков будут все писать в одно и то же место?
nolockyНо пока в продакшине нет ничего - VCS и нафиг не нужна, ни для чего иного, как по сути, средство backup-аНе смешно. И крайне несерьезно.

nolockysphinx_mvГрустный подход...
Еще на этапе согласования техзадания на разработку вылезает не один десяток версий документов - составная часть проекта, однако, к котрой должны иметь доступ все участники разработки.... И правку учиняет много больше одного человека... И расстояние между местами внесения изменений бывает очень не одна тысяча км...
И о чем твой грустный спич? Вот об этом:
nolockyМожно веселиться просто как хочется, используя VCS просто как эдакую разновидность сетевой шары для бекапов.
Системы управления версиями - не банальный бэкап на сетевую шару.
Но если кто-то "дорос" только до такого ее использования... ну... в начале такое бывает... Потом у большинства проходит...

Почти цитата: программисты делятся на тех, кто не пользуется системами управления версиями, и тех, кто уже пользуется.
nolockyMicrosoft Word и SVN/GIT вообще не совместимы, а если ты мне расскажешь, что ТЗ делаются в других форматах - я буду долго и зычно смеяться.Ну, если Вы этого не умеете (или не понимаете), то это таки Ваши проблемы.
Версия файла никакого отношения к формату файла не имеет. То есть вообще. Хоть 3-х часовое видео храни в "разных ракурсах" - если нужно и есть где.
Все что нужно - видеть правильный дифф в удобочитаемом формате. И для его получения необходимо и достаточно немного мозгов и более/менее прямые руки.
Ну, хотя бы для того, чтобы поиском воспользоваться. Если до чтения документации руки не дошли:
7.2 Customizing Git - Git AttributesDiffing Binary Files
...
MS Word files
(...и так далее...)
nolockysphinx_mvОткройте для себя TDD - разработка через тестирование. И тесты начинают писать на этапе, когда до работающего прототипа еще весьма не близко... Не говоря уже о релизах...
Я тебе только что сказал, что TDD и написание прототипа - нахрен на совместимые понятия. Чужой бред я не лечу.
Прототип без известной функциональности - дерьмо.
Известная функциональность - повод к началу написания тестов для нее.
Написание тестов "за два дня до релиза" - фтопку!
nolockyТе, кто считает, что TDD и прототип - это вещи совместимые - или просто дурак, или реально нигде никогда не работал.
Дурак тот, кто не понимает, что TDD никак не мешает написанию прототипа, и написание прототипа никак не противоречит использованию TDD.

Кстати...
Те, кто считают, что процесс написания прототипа несовместим с использованием систем контроля версий, не дотягивает даже до уровня дурака...
nolockysphinx_mvНе смешно. И крайне несерьезно.
И что с того? Выдай пример серьезного - мы хоть посмеемся вдоволь.Ну, с Вас уже достаточно посмеялись... Вас можно "выносить".

Диезnolockyпропущено...


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

А в чем проблема? TortoiseGIT прекрасно умеет открывать Word в режиме сравнения версий.
А если "аналитики и пр." не могут освоить пункт меню "Сравнить с предущей версией"... что ж, сочувствую такому Заказчику."Не кормите тролля" (с)

nolockyДиезНо я правильно понимаю суть вашего ответа? Он о том, что ваша фраза:
пропущено...

более не актуальна?

Конечно актуальна. SVN/GIT - это в первую очередь про управление текстовыми файлами, и пример разумного файла для документов - это docbook, с последующей генерацией (компиляцией) в .doc, .pdf, .htmlНу, и почему это вордовский документ не текстовый? Только из-за наличия форматирования, разметки и "картинок"? "Нэ оргумэнт" (с)

Про работу с бинарными файлами в Git ссылка на документацию Вам уже приводилась...
И про использование плагинов упоминалось...
nolockyНо хранить в VCS .DOC, .DOCX файлы - это верх идиотизма, с т.з. интеграции со всякими JIRA и прочими системами трекинга и т.п., нотификацией об изменениях по емейлу, blame и т.п.К.О. на проводе: Вы имеете очень слабое представление о возможностях работы с версиями при использовании одного только ворда, не говоря уже о прочих SVNах/GITах/JIRAх и т.п. Соответственно, а не пройти ли Вам базовый курс по MSOffice?
nolockyНет, ну вы, конечно, господа божьи одуванчики, которые никогда не согласовывали ТЗ (и никогда не работали с трекингом), можете рассказать, как клево вы получите svn diff на .doc файл по почте или отмочите там blame, но зачем столько нездорового смеха на сегодня, верно?Ну, посмейтесь "нездоровым (что, как бы, весьма намекает) смехом" над командой математиков, которая за полгода написала 600-страничную книгу, используя GitHub ...
И где такие "согласователи техзаданий 80 lvl" берутся?...