IT-redneck

1) SVN в топку.

Далее. Сделал таск - опубликовал свой бранч. Ответственный за интеграцию берет бранч с выполненным таском и мержит изменения на релизный бранч.

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

Таким образом, у себя локально - разработчик коммитит как ему удобно часто (с целями бэкапа и отката изменений), в основной девелоперский бранч релиза --- коммитится большими осмысленными аннотированными кусками работы, желательно со ссылкой на соответствующий таск/тикет.

Для целей бэкапа так же в конце рабочего дня приветствуется сделать push со своей локальной ветки в центральный реп, что бы если что (винт посыпался, компютер сгорел, канализацию прорвало и все затопило) изменения не пропали.

UPD. Ответственного за интеграцию можно назначать по-разному: например, сидишь на этой роли как на раздаче на распасах в префе, пока билд не пройдет.

Edited Date: 2010-04-25 09:51 am (UTC)

From:

metaclass.livejournal.com

Насчет "коммитится большими осмысленными аннотированными кусками работы, желательно со ссылкой на соответствующий таск/тикет." - это в DVCS есть методы "объединить over 9000 коммитов из одной локальной репы в один коммит в основную"?

Кстати, разделить релизный и центральный реп для бэкапов - до этого я не додумался с hg, это хорошая идея. Не додумался, потому как в svn у нас центральный и релизный это общий реп на сервере.

From:

over 9000 - это уже бардак. Сделал задачу --- опубликовал. Сливать 100 бессмысленных коммитов в один осмысленный - задача разработчика, этикет и уважение к коллегам. Т.е. можно заставлять заниматься этим майнтенера, но я бы, на месте майнтейнера, был бы очень зол.

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

From:

Т.е. вы считаете, что надо их сливать в один коммит, а не просто вмерживать ветку с ними в основную?
(по мне, вмерживание ветки логичнее: в основной ветке будет ровно один коммит, а при необходимости можно просмотреть, как он устроен)

From:

Ну и плюс такая вещь, как неизменяемость истории, действует как-то успокаивающе...

From:

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

From:

Удобно, помимо локального репозитория, иметь что-то на сервере - это, как минимум, даст возможность спокойно работать из двух мест. Опять же, майнтейнеру надо откуда-то брать то, что кладётся в центральную репу.
Я для себя в hg выработал сценарий: юзерам можно делать push в центральный репозиторий, но не в ветку default - туда мержит майнтейнер.
В принципе, альтернатива - персональная репа на сервере для каждого разработчика (куда он делает push, pull оттуда в центральную делается мейнтейнером вручную, из центрального туда - автоматом). Но по сути это то же самое, только разделение физическое, а не административное.

From:

Возможно это специфично для используемой системы, но в git будет видно каждый коммит. В случае со мной, например, может быть куча абсолютно левых коммитов, например добавление забытых файлов и т.п. Это потом может быть очень нудно ревьювить.

rebase полезно сделать (и делать регулярно), что бы публикуемые изменения были относительно текущего HEAD-а основного бранча по возможности, что бы смержилось максимально гладко (и вообще автоматически).

From:

Должен быть метод просмотреть revision log только для одной ветки.
Впрочем, я именно спрашивал - для себя я ещё не решил, что же лучше - сплющить ветку или нет.

Насчёт rebase - дело хорошее, но я привык просто мержить в свою ветку главную.

From:

anatoly borodin (from livejournal.com)

А rebase -i - это ещё лучше!

From:

и сливаешь все коммиты в один, что бы не морочить голову людям 9000 коммитами с исправлением опечаток в комментариях.
Но как? И какой смысл в бранчах в DVCS? Они же там даже не сразу появились потому что нас учили,ч то нужен бранч — сделай колн.

From:

сделай клон

From:

Смысл в бранчах в DVCS такой же, как в не-D VCS. Только в нормальных DVCS НАКОНЕЦ-ТО бранчами можно нормально пользоваться. По поводу "сделай клон" --- это верно только для bzr, в git например, бранчи были всегда, мы всегда в бранче бранчи всегда локальны. И это довольно удобно и в этом есть смысл.

По поводу "но как". Для гит --- rebase и cherry-pick для сложных случаев.

From:

Не, а серьёзно — зачем ещё одна сущность — бранч?

ребейз сливает чанджсеты локального репозитория в один?

From:

Много бранчей в нескольких репозиториях иметь удобнее, чем много репозиториев. Каждый репозиторий --- отдельный каталог с правами, группами, организацией доступа и т.п. Бранч в git сделать очень дешево и быстро, клонировать репозиторий --- долго.

rebase в двух словах не объяснить, но в том числе он позволяет сливать несколько коммитов в один. А также позволяет взять свои изменения относительно некоей точки там, откуда мы отбранчевались, оторвать их, подвинуть HEAD текущего бранча так, что бы он синхронизировался с HEAD исходного бранча, а потом наложить свои изменения поверх, для того, что бы они сделались относительно наиболее свежей версии удаленного репозитария, что бы было удобнее их туда потом запушить, когда придет время... Кажется у меня не получилось...

From:

Да нет, получилось, всё ясно как раз. Хотя противоречит идеи неизменяемости истории.

From:

Неизменяема публичная история. Локально это неудобно, так как идея частых коммитов противоречит идее осмысленных коммитов.

From:

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

From: