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

Мені цікаво дізнатися, що є передовою найкращою практикою. Чи слід застосовувати git-зобов’язання таким чином, що проект знаходиться в робочому стані (будується належним чином, всі тести проходять і т. Д.), Або вводиться порушений код ОК?

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

Я зазвичай дотримуюся цього правила:

• Кожне злиття у masterвідділення повинно залишати проект у робочому стані;
• Кожне злиття до магістральної developгілки повинно залишати проект у робочому стані (і він повинен будуватися як мінімум);
• Кожна інша особа має основну мету пояснити, чому зміни вносяться, і для чого вони пов'язані, і на які частини проекту це вплинуло. Усі інші цілі, такі як залишення проекту в робочому стані, необов’язкові.

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

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

git rebase -i HEAD~4

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

Тоді я можу підштовхнути це одне атомне виконання або фактично те, що я роблю, якщо моя нова функція дійсно готова - це використовувати "git cvsexportcommit", щоб перенести свою роботу в існуючий репортаж CVS.

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

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

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

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

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

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

Це git pushвпливає на інших користувачів. Політика щодо того, на що слід звернути увагу, - це вирішувати ваша команда розробників. Натискання неробочого коду на основну гілку, мабуть, ні-ні, але, ймовірно, нормально натискати неробочий код на окрему гілку (доки ніхто інший не збирається намагатися зробити збірку з цієї гілки).

На роботі ми використовуємо git flow , а також робимо незавершений або зламаний код - оскільки він розташовується лише в локальних або віддалених відділеннях, створених для цієї конкретної проблеми. Лише після того, як завдання буде виконано, воно об'єднується у гілку розробки (яка представляє поточну робочу копію у потоковій моделі). Таким чином, ми також можемо співпрацювати над кодом (деякі співробітники є в іншому місті, включаючи керівника проекту) та допомагати один одному.

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

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

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

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

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

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

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

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