![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
А вот как у вас модно
работать с системами контроля версий? Конкретно, с subversion, потому что в меркуриале и прочих DVCS можно хоть обкоммитится до одури - пока в другой репозиторий не закинешь, этого никто не увидит.
Я как-то склоняюсь к "сделал независимый мелкий кусок - тут же закомитил", даже если там пару букв всего поменялось. Т.е. билд стараться не ломать принципиально, но накапливать изменения на "один огромный коммит на всю фичу" не хочу.
PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.
Я как-то склоняюсь к "сделал независимый мелкий кусок - тут же закомитил", даже если там пару букв всего поменялось. Т.е. билд стараться не ломать принципиально, но накапливать изменения на "один огромный коммит на всю фичу" не хочу.
PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.
no subject
Далее. Сделал таск - опубликовал свой бранч. Ответственный за интеграцию берет бранч с выполненным таском и мержит изменения на релизный бранч.
В роли ответственного могут выступать все, но суть ме меняется --- берешь бранчи с изменениями, мержишь на основной бранч, убеждаешься, что все работает и публикуешь. Или нет, если что-то сломано.
Таким образом, у себя локально - разработчик коммитит как ему удобно часто (с целями бэкапа и отката изменений), в основной девелоперский бранч релиза --- коммитится большими осмысленными аннотированными кусками работы, желательно со ссылкой на соответствующий таск/тикет.
Для целей бэкапа так же в конце рабочего дня приветствуется сделать push со своей локальной ветки в центральный реп, что бы если что (винт посыпался, компютер сгорел, канализацию прорвало и все затопило) изменения не пропали.
UPD. Ответственного за интеграцию можно назначать по-разному: например, сидишь на этой роли как на раздаче на распасах в префе, пока билд не пройдет.
no subject
Кстати, разделить релизный и центральный реп для бэкапов - до этого я не додумался с hg, это хорошая идея. Не додумался, потому как в svn у нас центральный и релизный это общий реп на сервере.
no subject
Средства, естественно, есть. Т.е. нормальный воркфлоу: отбранчевался, делаешь задачу с множеством промежуточных коммитов (откат и бэкап), перед публикацией делаешь rebase на текущий mainline, и сливаешь все коммиты в один, что бы не морочить голову людям 9000 коммитами с исправлением опечаток в комментариях.
no subject
(по мне, вмерживание ветки логичнее: в основной ветке будет ровно один коммит, а при необходимости можно просмотреть, как он устроен)
no subject
no subject
no subject
Я для себя в hg выработал сценарий: юзерам можно делать push в центральный репозиторий, но не в ветку default - туда мержит майнтейнер.
В принципе, альтернатива - персональная репа на сервере для каждого разработчика (куда он делает push, pull оттуда в центральную делается мейнтейнером вручную, из центрального туда - автоматом). Но по сути это то же самое, только разделение физическое, а не административное.
no subject
rebase полезно сделать (и делать регулярно), что бы публикуемые изменения были относительно текущего HEAD-а основного бранча по возможности, что бы смержилось максимально гладко (и вообще автоматически).
no subject
Впрочем, я именно спрашивал - для себя я ещё не решил, что же лучше - сплющить ветку или нет.
Насчёт rebase - дело хорошее, но я привык просто мержить в свою ветку главную.
no subject
no subject
Но как? И какой смысл в бранчах в DVCS? Они же там даже не сразу появились потому что нас учили,ч то нужен бранч — сделай колн.
no subject
no subject
По поводу "но как". Для гит --- rebase и cherry-pick для сложных случаев.
no subject
ребейз сливает чанджсеты локального репозитория в один?
no subject
rebase в двух словах не объяснить, но в том числе он позволяет сливать несколько коммитов в один. А также позволяет взять свои изменения относительно некоей точки там, откуда мы отбранчевались, оторвать их, подвинуть HEAD текущего бранча так, что бы он синхронизировался с HEAD исходного бранча, а потом наложить свои изменения поверх, для того, что бы они сделались относительно наиболее свежей версии удаленного репозитария, что бы было удобнее их туда потом запушить, когда придет время... Кажется у меня не получилось...
no subject
no subject
no subject
no subject