[RobFPGA 25]

52 minutes ago, dimka76 said:

А если ваш рабочий комп накроется, а вы Push два месяца не делали ?

А для этого есть бэкап,  ежедневный, недельный, ...    

[kirill70674 4]

3 часа назад, dimka76 сказал:

А если ваш рабочий комп накроется, а вы Push два месяца не делали ?

Значит Вы как второй роман «великого пятикнижия» Ф.М. Достоевского.

[amaora 6]

13 hours ago, dxp said:

если требуется гибкое и удобное версионирование, то git тут вне конкуренции.

mercurial, fossil, breezy

[dxp 29]

17 часов назад, dimka76 сказал:

А если ваш рабочий комп накроется, а вы Push два месяца не делали ?
Все заново делать ?

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

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

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

[dxp 29]

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

Про остальные две не знаю, но низкая известность и популярность говорят сами за себя: мало сообщество, качество инструмента напрямую зависит от количества использующих и т.п. Есть Bazaar, тоже одно время интенсивно развивалась/продвигалась, но на сегодняшний день по факту сдулась (она на Python реализована, как я понял, там серьёзные вопросы с производительностью, особенно на больших проектах). Т.ч. систем управления версиями много всяких, это да, и какие-то в чём-то могут безоговорочно превосходить остальные, но мы говорим о выборе рабочего инструмента, на который претендуют только хорошо проверенные в деле, сиречь популярные, системы. По совокупности гит рулит.

[amaora 6]

10 hours ago, dxp said:

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

Ну такая концепция была, что историю менять нельзя, наверно поэтому название ветки прибито к коммиту. Сейчас уже все можно менять если хочется, но я предпочитаю не делать всяких rebase, mq и подобного. А уж histedit совсем какая-то грязь. Да, есть bookmarks это перемещаемые метки, не пользуюсь, не понимаю зачем они мне.

 

10 hours ago, dxp said:

Есть Bazaar, тоже одно время интенсивно развивалась/продвигалась, но на сегодняшний день по факту сдулась

Не пользовался, теперь как я понял она называется breezy.

 

 

 

 

[dxp 29]

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

Где пригождается rebase, лучше показать на примере. У нас процесс построен так (он рекомендованный, насколько знаю): есть общая ветка разработки, она постоянная, она содержит только целостные комиты, т.е. состояние проекта таково, что он собирается и работает. Основной смысл этого в том, чтобы любой участник команды мог взять крайний комит за основу для разработки своей фичи, и у него всё будет собираться, не будет чужих ошибок, которые будут ему мешать развивать и собирать своё. Для этого создаётся временная ветка (feature branch -- FB). Сливать в общуюю ветку может только её мейнтейнер, у остальных таких прав нет (это обеспечивает целостную базу как отправную точку для всех участников проекта независимо от их дисциплинированности -- главное, чтобы ментейнер не был раздолбаем и добросовестно проверял перед слиянием -- это несложная работа, её вообще можно автоматизировать, но у нас руки пока не дошли, не обременительно запускать сборку/тесты руками).

Работа участниками проекта ведётся параллельно. Когда фича готова к слиянию, её автор создаёт pull/merge request на слияние этой FB в общую. Перед этим он делает rebase на общую ветку, чтобы объединить свою фичу с кодом общей, которая за время работы над FB могла уйти вперёд (как правило так и происходит). Мейнтейнер проверяет целостность кода, запуская сборку, тесты. Если всё успешно, FB сливается в общую с комитом слияния (git merge --no-ff). Результатом будет чётко видная в истории ветка FB со всеми своими комитами, слитая в общую через комит слияния.

Делать объединение общей ветки с FB обязательно -- на этом этапе вылезают всякие конфликты, ошибки и т.п. Объединять можно двумя способами: через merge и через rebase. Если делать через merge, то это нарушает описанную выше "красивость" истории (которая нужна далеко не только из эстетических аспектов, но является мощным подспорьем для ретроспективы кода). rebase позволяет держать локальную историю разработки фичи компактно и целостно, не смешивая с комитами других веток. Да, это изменяет историю развития проекта в смысле строгой хронологии, но для работы с кодом гораздо важнее вид с точки зрения добавления фич и фиксов, когда видны этапы работы, а не вид с точки зрения последовательных дат комитов.

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

В описанном процессе rebase пригождается не толькло при работе командой. Ровно то же самое и когда работаешь один, если приходится параллельно вести больше одной FB (например, при разработке фичи отвлекаться на правку багов, создавая для них свои ветки).

[yes 3]

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

я так понимаю, что качается весь репозиторий, со всеми ветками и т.д. 

 

[kirill70674 4]

12 часов назад, dxp сказал:

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

Где пригождается rebase, лучше показать на примере. У нас процесс построен так (он рекомендованный, насколько знаю): есть общая ветка разработки, она постоянная, она содержит только целостные комиты, т.е. состояние проекта таково, что он собирается и работает. Основной смысл этого в том, чтобы любой участник команды мог взять крайний комит за основу для разработки своей фичи, и у него всё будет собираться, не будет чужих ошибок, которые будут ему мешать развивать и собирать своё. Для этого создаётся временная ветка (feature branch -- FB). Сливать в общуюю ветку может только её мейнтейнер, у остальных таких прав нет (это обеспечивает целостную базу как отправную точку для всех участников проекта независимо от их дисциплинированности -- главное, чтобы ментейнер не был раздолбаем и добросовестно проверял перед слиянием -- это несложная работа, её вообще можно автоматизировать, но у нас руки пока не дошли, не обременительно запускать сборку/тесты руками).

Работа участниками проекта ведётся параллельно. Когда фича готова к слиянию, её автор создаёт pull/merge request на слияние этой FB в общую. Перед этим он делает rebase на общую ветку, чтобы объединить свою фичу с кодом общей, которая за время работы над FB могла уйти вперёд (как правило так и происходит). Мейнтейнер проверяет целостность кода, запуская сборку, тесты. Если всё успешно, FB сливается в общую с комитом слияния (git merge --no-ff). Результатом будет чётко видная в истории ветка FB со всеми своими комитами, слитая в общую через комит слияния.

Делать объединение общей ветки с FB обязательно -- на этом этапе вылезают всякие конфликты, ошибки и т.п. Объединять можно двумя способами: через merge и через rebase. Если делать через merge, то это нарушает описанную выше "красивость" истории (которая нужна далеко не только из эстетических аспектов, но является мощным подспорьем для ретроспективы кода). rebase позволяет держать локальную историю разработки фичи компактно и целостно, не смешивая с комитами других веток. Да, это изменяет историю развития проекта в смысле строгой хронологии, но для работы с кодом гораздо важнее вид с точки зрения добавления фич и фиксов, когда видны этапы работы, а не вид с точки зрения последовательных дат комитов.

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

В описанном процессе rebase пригождается не толькло при работе командой. Ровно то же самое и когда работаешь один, если приходится параллельно вести больше одной FB (например, при разработке фичи отвлекаться на правку багов, создавая для них свои ветки).

Добавлю, кроме веток master и feature/xxx при команде 4+ человека начинает иметь смысл ветка dev. На ней находится не проверенная, но "смёржденная" версия проекта. Далее коммит на ней посылается в регрессию тестов. После удачного прохождения регрессии, коммит мёрджится в master.

[Сергей Борщ 95]

3 часа назад, yes сказал:

я так понимаю, что качается весь репозиторий, со всеми ветками и т.д. 

Это вы с git спутали. svn, как раз, после обрыва обновления либо клонирования продолжает с места обрыва, а вот git качает все сначала.

[Moonl1ght 23]

Однозначно, git. SVN, конечно прост в использовании, но если проекты усложняются (в плане иерархии, количества разработчиков и т. д.), то рано или поздно всё-равно будет переход на git. А если у вас куча проектов была завязана на SVN долгое время - геморроя не оберетесь при переводе на гит. Проверено🙂

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