А вот как у вас модно

[metaclass]

работать с системами контроля версий? Конкретно, с subversion, потому что в меркуриале и прочих DVCS можно хоть обкоммитится до одури - пока в другой репозиторий не закинешь, этого никто не увидит.

Я как-то склоняюсь к "сделал независимый мелкий кусок - тут же закомитил", даже если там пару букв всего поменялось. Т.е. билд стараться не ломать принципиально, но накапливать изменения на "один огромный коммит на всю фичу" не хочу.

PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.

Comments

[metaclass.livejournal.com]

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

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

[dmzlj.livejournal.com]

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

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

[aamonster.livejournal.com]

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

[aamonster.livejournal.com]

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

[dmzlj.livejournal.com]

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

[aamonster.livejournal.com]

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

[dmzlj.livejournal.com]

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

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

[aamonster.livejournal.com]

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

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

[anatoly borodin (from livejournal.com)]

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

[blacklion.livejournal.com]

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

[blacklion.livejournal.com]

сделай клон

[dmzlj.livejournal.com]

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

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

[blacklion.livejournal.com]

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

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

[dmzlj.livejournal.com]

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

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

[blacklion.livejournal.com]

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

[dmzlj.livejournal.com]

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

[blacklion.livejournal.com]

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

[dmzlj.livejournal.com]

А для себя можно rebase-ом и слиянием коммитов и не заморачиваться вообще. Как бы не особо зачем.