Чи слід тимчасовий код ставити під контроль версій і як?

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

1. Файли проекту. Шляхи, можливо, потрібно буде відредагувати, щоб відобразити макет на поточному ПК.
2. Makefiles. Наприклад, оптимізацію може знадобитися вимкнути під час налагодження, але не для сервера CI.
3. Брудні некрасиві хаки. Наприклад, return 7в середині функції, щоб тестувати щось, залежно від функції, і підозрюється, що він зламається при значенні 7. Або 7 - код ще не реалізованої кнопки, який я впроваджую і потрібно перевірити протягом усієї життя моєї галузі.

Я спробував утримувати тих, хто перебуває в русі, який я завжди переношу на вершину, перш ніж натиснути на репо, а потім натиснути HEAD~. Це дуже незручно і не працює зі svn. Сташинг мене ще більше лякає - "я пам'ятав, щоб попнути після натискання ??".

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

Що було б розумним рішенням такого викидного коду?

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

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

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

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

Файли проекту. Шляхи, можливо, потрібно буде відредагувати, щоб відобразити макет на поточному ПК.

Для файлів проекту найкраща стратегія - це коли ви можете генерувати файл проекту за допомогою сценарію. Додайте фактичний файл проекту до своїх ігнорів та просто заново створіть файл проекту за необхідності. Наприклад, в проектах Java я використовую gradle, який може генерувати проект затемнення.

Makefiles. Наприклад, оптимізацію може знадобитися вимкнути під час налагодження, але не для сервера CI.

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

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

Ви не можете написати тест, який викликає випадок підозри на відмову?

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

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

Це означає що:

• Тимчасові матеріали, які були введені за короткий проміжок часу (час, необхідний для визначення місця помилки або експерименту з особливістю мови, наприклад), не повинні знаходитись у контролі версій: зберігайте його, поки вам не потрібно його, а потім просто видаліть, виконуючи фіксацію .

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

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

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

  Слідкуйте за можливістю усунути особливості між машинами. Це може означати:

  • Надаючи доступ до розробленого SQL-сервера для заміни локальних примірників на машинах розробників,

  • Використовуючи послуги розповсюдження пакетів, такі як Pypi або npm, для публічних пакетів та їх приватних аналогів для внутрішніх пакетів,

  • Попросіть членів команди встановити однакові версії програмного забезпечення,

  • Зробіть оновлення програм максимально прозорими,

  • Або дозволити розгортання ОС та необхідного програмного забезпечення на машині за один клік (плюс час для кожного розробника встановити бажані Vim vs. Emacs, Chrome проти Firefox тощо)

Так:

Файли проекту. Шляхи, можливо, потрібно буде відредагувати, щоб відобразити макет на поточному ПК.

Чому б не використовувати однаковий макет на кожному ПК? Шляхи в межах проекту повинні бути відносно файлу проекту, а це означає, що не має значення, де знаходиться проект. Версії програмного забезпечення та бібліотек краще бути однаковими, щоб уникнути криптованих помилок, які з’являються лише на деяких машинах і неможливо відтворити для інших членів команди.

Приклад:

У проекті, створеному за допомогою Visual Studio, ви можете знайти:

• Самі файли. Шляхи відносні, не має значення, чи є на моїй машині проект, H:\Development\Hello World Project\а інші члени команди перевіряли проект C:\Work\HelloWorld\.

• Залежності, тобто сторонні та власні бібліотеки. Обидва типи повинні вирішуватися NuGet, що робить усі дискусії, пов'язані з конфліктами, застарілими. Якщо у вас немає тієї самої версії бібліотеки, яку я, попросіть NuGet оновити залежності. Настільки ж просто (коли це працює добре, що не завжди так).

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

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

• Налаштування, пов'язані з утилітами. Вони складні, адже деякі члени команди, можливо, встановили деякі утиліти, а інші - ні.

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

Makefiles. Наприклад, оптимізацію може знадобитися вимкнути під час налагодження, але не для сервера CI.

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

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

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

Описуючи це, ви повинні написати тест. Наприклад, якщо ви хочете бути впевнені, що:

class TemperatureConverter
{
    public int CelsiusToFahrenheit(int temperature)
    {
        ...
    }
}

кидає виняток, коли temperatureвін поступається AbsoluteZeroпостійному, не слід грати з самим кодом. Натомість створіть одиничний тест, який буде:

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

Ми використовуємо @@коментарі в коді, щоб вказати на те, що все не зовсім готове, для тестування тощо.

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

Ми робимо глобальний пошук, @@щоб запобігти «залишкам» перед тим, як вступити на завершальні етапи бета-тестування тощо.

Використовуючи цю дисципліну, я не бачу причин не просто вчинятися. Таким чином, у нас немає окремих гілок і лише один додатковий «протокол», який слід наслідувати.

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

Я навіть використовую @@nameдля позначення питань, які мені потрібно обговорити з "ім'ям".

2 рішення HAMSTER:

• Ви можете скористатися гачком, який попередньо здійснить, щоб перевірити код на предмет незвичайного ключового слова, наприклад HAMSTER. Просто не дозволяйте людям вчинити код, який був НАДЗВИЧАНО, і використовуйте його, коли ви робите брудні хаки.

• Іншим варіантом, наприклад, в C, є використання #ifdef HAMSTER, тоді код буде працювати лише на вашій машині, де у вас є прапор компілятора HAMSTER.

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

Це навіть стосується шипів http://www.extremeprogramming.org/rules/spike.html , як ті, які ви описали; ми просто розміщуємо їх у іншому під-дереві.

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

1. Легкі гілки, які можна обрізати.

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

2. Скористайтеся чергою виправлень зверху SCM.

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

3. Використовуйте RCS як "позадіапазонний" SCM для невеликих експериментів.

   Іноді просто хочеться одноразово перевірити файл, який працює, без необхідності очищати історію. Зазвичай я використовую RCS для цього всередині Git або SVN. Я кажу Git ігнорувати артефакти RCS, перевіряю мою роботу в RCS, і коли мені подобаються результати, я просто кидаю *,vфайли або весь каталог RCS. Просто не бігайте git clean -fdxабо подібне, поки ви не присвоїли свою роботу своєму "справжньому" SCM, або ви пошкодуєте про це.

4. Названі стаси.

   Ще один Git-ism, але зручний: git stash save --include-untracked <some-cool-title>може бути корисним за дрібку. Ви можете зберігати, випускати та застосовувати незавершені роботи таким чином, а також переглядати різні контрольно-пропускні пункти через git stash listабо git reflog --all. Інші SCM можуть мати подібні функції, але ваш пробіг може сильно відрізнятися від цього.

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

Принаймні, ви маєте змогу возитися з будь-якою кількістю функціональних гілок, поки вони не будуть готові бути об'єднані в головний / стовбур.

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

Я вважаю, що деякі системи будуть кидати попередження про те, що вони бачать TODO в коментарі, так

// TODO: remove this hack.

може бути все, що потрібно, якщо ви можете знайти відповідний варіант у якійсь частині свого середовища розробки, або просто дотримуватися якусь команду grep у вашому збірному файлі. Можливо, також можна домовитись про // HACKпідбір будь-якої довільної рядки.

Це простіше, ніж організувати свій код певним чином і сподіватися, що люди запам’ятають, що його не використовують. Це також безпечніше дотримуватися порад @gbjbaanb (якщо ви можете переконатися, що всі бачать попередження!).

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

Ніколи не шкідливо ставити код у керування джерелами.

Кожен з названих вами предметів повинен знаходитись у контролі джерел.