Чи добре, що порушено проміжні зобов’язання, поки остаточне виконання в будь-яких натисканнях?

Пов’язано: Чи повинен кожен git-зобов'язання залишити проект у робочому стані?

Припустимо, я здійснюю наступні зобов’язання на місцях:

• Змініть схему бази даних, порушивши додаток.

• Оновіть програму, щоб вона знову була сумісною зі схемою бази даних.

Поки я наполягаю на обох зобов'язаннях, masterзалишаюсь у робочому стані. Однак історична версія зламана.

Я усвідомлюю, що можу використати git rebase -iдля того, щоб разом збивати коміти. Однак отриманий комітет буде великим і менш описовим. Якщо мені потрібно шукати історію комісій, щоб дізнатися, чому я щось змінив, я краще знайду оригінальний документ, який показує, що я робив і чому.

Мої запитання:

• Хтось стикався з труднощами через порушені історичні зобов'язання у майстра?

• Якщо так, то чи є простий спосіб уникнути таких труднощів, не відкидаючи повідомлення про окремі повідомлення та зміни?

Багато в чому залежить від стратегії розгалуження вашого вбрання, але я думаю, що розбиття комісій на галузях розвитку має загальний сенс - справді велика «виграш» у використанні керування джерелами полягає в тому, щоб мати змогу повернути невеликі зміни, а іноді і ти зробивши купу їх, і ви повинні розбити яйця, щоб зробити омлети.

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

Порушені зобов’язання - це те, що "просто відбувається", не повинно означати кінець світу. У мене в голові трохи набридлий голос, який говорить мені, що я не повинен свідомо перевіряти порушений код, як правило, і тому включаючи історичні версії, проте це не те, на чому я б ішов на війну.

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

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

Ні, це не нормально.

Якщо ви коли-небудь робили git bisect(і хто не любить цю рису вбивці), ви знаєте цінність історії, в якій будується кожен вчинок.

Якщо у вас є багато комісій під час bisectпобудови, яка не будується, у вас буде багато git bisect skips, які ускладнюють пошук останнього доброго комітету.

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

Хтось стикався з труднощами через порушені історичні зобов'язання у майстра?

Так. Повернення, реверти та бісектриси складніше. Так само читання історії (див. Нижче).

Якщо так, то чи є простий спосіб уникнути таких труднощів, не відкидаючи повідомлення про окремі повідомлення та зміни?

Не те, що я знаю, хоча гілки - гідне рішення.

Однак я вважаю, що відкидання (або, скоріше, подрібнення) окремих осіб - це правильно зробити.

Під час розвитку, особливо коли робиш TDD, робиш рано і часто це добре. Ви хочете, щоб простежити все, що ви робите, щоб ви могли відступити, або зрозуміти, коли саме справи почалися не так (або, можливо, ви потрапили в рефакторинг, більший, ніж можете жувати). Звернутись.

Однак, як тільки функція / зміна готова бути відхиленою, фіксація - це упакована зміна - в ідеалі атомна, тому її можна [переглянути, переосмислити, об'єднати, вишневим, повернутим, переглянути в примітці] якомога незалежно від інших можливих змін .

Дивлячись на історію проекту, зміну програмного забезпечення слід оцінювати самостійно. Він будує? Це йде з тестами? Це працює? Що це робить? Які файли потрібно змінити, щоб надати цю функцію?

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

Коротка відповідь: Так

Тестування:

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

Розробка:

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

Caveat:

Це не означає

1) Ви перевіряєте зламаний код у master.
2) Вам потрібно підштовхнути всі мікрокомітети, щоб кожен переглянувся.

Використовуйте гілки для своєї роботи. Потенційно стискати мікрокомісії для процесів огляду, щоб вони знаходилися в логічно виокремлених підрозділах з відповідними коментарями. Якщо ви використовуєте git, ви не втратите оригінальний набір комітетів, ви можете просто створити новий, більш логічний набір комітетів для процесів перегляду, які будуть об'єднані в головний.

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