Чи справді історія версій священна чи її краще перезавантажити?

Я завжди погоджувався з мантрою ¹ Меркуріала ¹ , однак тепер, коли Mercurial поставляється в комплекті з розширенням бази даних, і це популярна практика в git, мені цікаво, чи дійсно це можна розглядати як "погану практику", або принаймні досить погано, щоб уникнути використання. У будь-якому випадку, я знаю, що відмовити небезпечно після натискання.

ОТО, я бачу сенс намагатися упакувати 5 фільмів в один, щоб зробити його схожішим (особливо у виробничій галузі), проте особисто я думаю, що було б краще бачити часткові зобов’язання для функції, де деякі експеримент робиться, навіть якщо він не такий витончений, але бачити щось на кшталт "Спробував це зробити X, але це не так оптимально, як Y врешті-решт, робити це Z, беручи Y за основу", IMHO матиме хороше значення для тих, хто навчається кодову базу та слідкуйте за думкою розробників.

Моя дуже впевнена (як і німа, вісцеральна, упереджена) точка зору полягає в тому, що програмістам подобається переглядати, щоб приховати помилки ... і я не думаю, що це взагалі добре для проекту.

Отже, моє запитання: чи справді ви вважаєте цінним існувати на практиці такі "органічні зобов'язання" (тобто незашкоджена історія), або, навпаки, чи не вважаєте за краще набігати на вишукані добре упаковані комісії та ігнорувати процес експериментів програмістів ?; який би ви вибрали, чому це працює для вас? (маючи інших членів команди, щоб зберігати історію або, як альтернативу, перезавантажувати її).

¹ за аналіз DVCS Google , у Mercurial "Історія є священною".

Історія священна, то Present немає. Ви можете розділити "дерево" DVCS на дві частини:

• Минула / історія , яка містить точне уявлення про те, як ви досягли поточного стану коду. Ця частина історії зростає з часом

• Присутній яку частину ви зараз працюєте, щоб зробити вам код еволюціонувати. Ця порада більшу частину історії має приблизно однаковий розмір.

Кожен код, який ви випустили чи якось використали, є частиною минулого . Минуле є священним, оскільки вам потрібно вміти відтворити налаштування або зрозуміти, що призвело до регресії. Ви ніколи не переписуєте минуле . У git ви зазвичай ніколи нічого не переписуєте, як тільки це є master: master - це минула частина історії. У Mercurial у вас є ця концепція публічної фази, яка відслідковує минулу частину вашого «дерева» та забезпечує його незмінність.

Присутній частина коду є ревізією ви зараз працюєте. Функціональна галузь, яку ви намагаєтеся зробити корисною, непрацездатною та належним чином відновленою. Це зовсім чудово переписати, це навіть гарна ідея, оскільки це робить минулу частину більш красивою, простою та зручною. Меркуріал відстежує це у фазі проекту .

Так що так, будь ласка, перезавантажте, якщо це покращить вашу історію. Mercurial заважатиме вам стріляти собі в ногу, якщо ви відпускаєте речі, які не повинні.

Не всі помилки є тими, які вам потрібно приховати - наприклад, я одного разу випадково скористався бінарним файлом у мою репо. Зловживання історією погано лише тоді, коли помилка полягає не лише в самій історії, як у файлах, вчинених яких не повинно бути.

Перегляд коду набагато простіше, коли є одна велика згуртована зміна на відміну від багатьох малих залежних.

Коли я працюю над новою функцією, я люблю вносити багато невеликих змін у свою галузь. Коли я готовий надіслати патч, я згортаю ці маленькі коміти в одну велику комісію, яка представляє весь новий код, необхідний для цієї функції. Ось тут корисна база.

З іншого боку, перегляд даних є недоцільним, якщо комісії не мають нічого спільного. Додатки для кількох функцій повинні бути окремими комітами (а в ідеалі - з окремих гілок).

Ваше запитання описує історію як набір впорядкованих змін коду, а також запитує, чи органічні зобов’язання чинити майбутніх читачів у процесі розробки. Але як інженер випуску / інтеграції я часто не вважаю історію кодом. Мене більше захоплює історія, яку розповідає моя історія, інституційні знання, які вона зберігає, і чи дозволяє мені це швидко налагоджувати проблеми.

Я не думаю, що органічні робочі процеси це роблять добре, навіть моє власне. Якості, які я ціную щодо DVCS, коли я кодую - дешеві відділення, швидкі комунальні послуги, економить на віддаленому рівні рано та часто - не те, що я ціную як менеджер з інтеграції моєї компанії . Я питання git rebase, git merge, git diffі git applyнабагато частіше в цій ролі , ніж git addабо git commit. Такі інструменти rebaseдозволяють мені перетворити код, який я отримую, з чогось, що функціонує, у те, що можна підтримувати.

Нелогічні чи розпливчасті комісії не є корисними, але їх гріховно легко органічно записати, коли головна проблема полягає в тому, щоб код працював, а не поширював його на інші. Здійснює подобається Case 15: Fixed a problemабо Refactored <cranky legacy feature>робить моє самоврядування, навіть коли я їх автор. Однак жодна з них не викликає гнів затемнення, як "поступовий" вчинок. Розглянемо цю галузь теми розробник передав мені днями:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Ці речі - Зло. Це як DVCS, призначений для доктора Фаустуса. Я дам вам швидке та просте управління джерелом. Ви даєте мені душу супровідника вашого коду. Усі ліниві вчинки - це егоїстичні вчинки. Багато хто з нас пише їх, але ми також зобов'язані своїм майбутнім логічною, повторюваною, налагоджуваною історією. Ми не можемо зробити це без певного способу rebase.

Що стосується невдалих експериментів, то чому б не описати їх у наших (щойно незайманих) повідомленнях про вчинення? Через рік мені не потрібен напівфабрикат. Я просто хочу записати про перервану спробу і, можливо, коротке пояснення, якщо я вважаю, що я досить дурний, щоб спробувати його ще раз. У світі дуже багато успішних робочих процесів, але я намагаюся придумати будь-яку причину, яку б я свідомо вчинив зламаний код у виробничій кодовій базі.

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

Особисто мені здається дуже корисним перевстановити локальну гілку функції на магістраль (або головну гілку розробки) перед запуском остаточних тестів та об'єднанням функції в основну гілку. Таким чином я можу вирішити будь-які конфлікти злиття тощо, перш ніж насправді об'єднатись.

ІМХО, експерименти зазвичай належать до полиць або тимчасових гілок, а не базових. Якщо ви дотримуєтесь цього, не повинно виникнути проблем, оскільки всі комісії будуть логічно обгрунтованими та додадуть певної цінності.