Як часто здійснювати зміни в контролі джерела? [зачинено]

Як часто слід вносити зміни до контролю джерела? Після кожної невеликої функції чи лише для великих функцій?

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

Однак мене турбує ця закономірність. У продуктивний день роботи я можу зробити 10 прихильників. Зважаючи на те, що я використовую Subversion, ці комірати впливають на весь сховище, тому мені цікаво, чи дійсно є так багато практики зробити так багато?

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

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

Коли ви говорите, що ви стурбовані тим, що ваші "комітети впливають на весь сховище" --- ви посилаєтесь на те, що кількість ревізійних репозиторіїв усього сховища збільшується? Я не знаю, скільки біт Subversion використовує для її зберігання, але я впевнений, що у вас не вичерпаються номери редакції! Багато комітетів не є проблемою. Ви можете скористатися в десять разів частіше, ніж хлопець у сусідньому будинку, і зовсім не збільшите свій вуглецевий слід.

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

Мені подобається ця невеличка стаття від Jeff Atwood: Check In Early, Check In често

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

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

Я беру на себе зобов’язання щоразу, коли закінчую завдання. Зазвичай це займає від 30 хвилин до 1 години.

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

Я слідую за мантрою з відкритим кодом (перефразовано) - здійснюю рано, здійснюю часто.

В основному, коли я думаю, я додав корисну функціональність (хоч і невелику), не створюючи проблем для інших членів команди.

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

Не вводите код, який насправді не працює. Не використовуйте ваш сховище як резервне рішення.

Натомість, резервне копіювання вашого неповного коду на локальному рівні автоматично. Time Machine піклується про мене, і для інших платформ є безліч безкоштовних програм.

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

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

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

Я не думаю, що ти повинен так сильно турбуватися про те, як часто. Тут важливо, що, коли і чому. Говорити про те, що доводиться виконувати кожні 3 години або кожні 24 години, насправді немає сенсу. Покладіть на себе зобов’язання, коли у вас є що зробити, але не зробите.

Ось витяг із моїх рекомендованих найкращих практик щодо контролю версій :

[...] Якщо ви вносите багато змін у проект одночасно, розділіть їх на логічні частини та виконайте їх у декількох сесіях. Це набагато простіше відстежувати історію окремих змін, що заощадить вам багато часу при спробі пошуку та виправлення помилок. Наприклад, якщо ви реалізуєте функції A, B і C і виправляєте помилки 1, 2 і 3, це повинно призвести до щонайменше шести комітів, по одному для кожної функції та по одному для кожної помилки. Якщо ви працюєте над великою функцією або займаєтесь широким рефакторингом, подумайте про те, щоб розділити свою роботу на ще менші частини та взяти на себе зобов’язання після завершення кожної деталі. Також, застосовуючи незалежні зміни до декількох логічних модулів, виконайте зміни кожного модуля окремо, навіть якщо вони є частиною більшої зміни.

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

Ваш поточний зразок має сенс. Майте на увазі, як ви використовуєте цей елемент керування джерелом: що робити, якщо вам доведеться відкинути, або якщо ви хочете зробити різний? Описи, які ви описуєте, здаються точно правильним диференціалом у тих випадках: diff покаже вам саме те, що змінилося під час впровадження помилки № (вказано в журналі реєстрації), або саме те, що новий код був для реалізації функції. Подібний відкат, як і раніше, торкнеться лише однієї речі.

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

Ось пов’язана публікація в блозі: Кодування жахів: заходьте рано, заходьте часто

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

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

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

Мить, коли ти задумаєшся.

(поки те, що ви зареєструвались, є безпечним)

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

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

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

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

Я також люблю регулярно заїжджати. Це кожен раз, коли я роблю крок до своєї мети.

Це , як правило , кожні кілька годин .

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

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

1. Більше роботи за реєстрацію; менше реєстрацій == менше оглядів.
2. Змініть політику перевірки компанії. Якщо я щойно зробив рефакторинг і всі тести блоку працюють зеленими, можливо, я можу послабити правило?
3. Зберігайте зміни, поки хтось не зможе виконати огляд і продовжити роботу. Це може бути проблематично, якщо рецензент не любить ваш код і вам доведеться переробити дизайн. Жонглювання різними етапами завдання шляхом "приховування" змін може стати безладним.

Мені подобається вносити зміни кожні 30-60 хвилин, до тих пір, поки вона складеться чисто і не буде регресу в одиничних тестах.

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

Щодо частоти Commits, я думаю про це таким чином, як сильно болітиме мені, якби мій жорсткий диск вийшов з ладу, і я чогось не зробив - квант цього чогось для мене становить близько 2 годин роботи.

Звичайно, я ніколи не вчиняю те, що не збирається.

Хоча б раз на день.

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

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

Найкраща схема, яку я використав, мала два відповіді на це питання.

Ми використовували 2 повністю відокремлених сховища: одне було сховищем проекту, а інше - власним персональним сховищем (тоді ми використовували rcs).

Ми перевірятимемо наше особисте сховище дуже регулярно, майже кожного разу, коли ви зберігаєте відкриті файли. Таким чином, особистий сховище був в основному великим, довгомірним буфером для скасування.

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

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

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

Якщо ви працюєте у відділенні, яке не буде випущено, зобов'язання завжди безпечні.

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

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

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

Це дійсно поширене питання, але справжнє питання: Чи можете ви зробити незакінчений код?

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

І будь ласка, переконайтесь, що ви коментуєте належним чином.