Як писати повідомлення про фіксацію як соло-розробник?

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

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

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

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

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

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

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

Чи чесно ви вірите, що накладні витрати на друку від 40 до 80 символів простою англійською мовою є значними накладними витратами, або ви шукаєте привід бути лінивим?

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

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

• Ви не завжди будете розробником соло.

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

• Ви не можете згадати, над чим працювали три тижні тому, правда?

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

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

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

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

Я був єдиним комітетом проекту TXR і досить рано зберігав детальний ChangeLog. Це близько 11000 рядків і зростає: http://www.kylheku.com/cgit/txr/tree/ChangeLog

(Повідомлення про фіксацію в РЕПО - це лише копія того, що відбувається в ChangeLog.)

[2016 редагувати: станом на середину 2015 року я більше не підтримую файл ChangeLog; однак повідомлення комісії написані у форматі, який одночасно відповідає умовам Git та ChangeLog. Такий самий рівень деталізації є, таким чином, що не викликає проблем з об'єднанням. Файл ChangeLog можна механічно реконструювати з цих коментарів.]

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

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

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

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

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

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

Я іноді вносив зміни, коли в середині написання запису ChangeLog я зрозумів, що це буде git reset --hardшвидше (відкинути ці непотрібні зміни) git commit -a.

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

Ось пов'язане питання щодо мети введення повідомлень: Чому я повинен написати повідомлення про прихильність

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

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

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