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

[metaclass]

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

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

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

Comments

[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 - это ещё лучше!