Чому я повинен писати повідомлення про фіксацію?

Чому я повинен писати повідомлення про фіксацію? Я не хочу, і я думаю, що це дурно кожен раз.

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

Якщо я виконую кілька разів на день і не закінчив функцію, про що я пишу? Я ТІЛЬКИ коли-небудь пишу повідомлення після багатьох комісій, і я відчуваю, що настав час для міні-тегів або коли я роблю фактичний тег.

Я маю рацію чи щось мені не вистачає? також я використовую розподілену систему

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

Якщо ви використовуєте git , це я б назвав розумним робочим процесом:

1. Виконуйте так часто, як вам подобається . Напишіть там будь-яке старе швидке повідомлення. Ніхто цього не побачить.
2. Скажімо, 10 комісій, ви закінчили цю функцію, над якою працювали. Тепер пишіть тести і виконайте ці тести. Або все, що ви хочете. Якщо вам подобається TDD, спершу пишіть тести, мені все одно, а також не git.
3. git rebase -iвід першого "безладного" доручення, яке ви додали, і виправити свою краєзнавчу історію, видаляючи, редагуючи, опускаючи та іншим чином очищаючи свою недавню історію в логічні, чисті записи з приємними повідомленнями .
4. Після прибирання попросіть когось зняти з вас.
5. Промийте і повторіть.

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

Також зауважте, що будь-де між кроками 1 і 3 ви можете git pushвнести зміни до свого приватного дзеркала репо на сервері, щоб отримати безкоштовні резервні копії, якщо ваш жорсткий диск ноутбука помер.

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

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

Ви пишете найкращі коментарі, ті, що кажуть, чому як код говорять тільки як ?

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

Для будь-якого активного програмного забезпечення цей конкретний коментар виявиться в чомусь подібному

(знайдено на веб-сайті http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Це дозволяє переглядати, хто працював над програмним забезпеченням, коли і що вони робили.

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

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

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

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

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

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

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

Не робіть з них великої справи. Бути чесним:

• "Відредаговані об'єкти просторового індексу, даоси та інтерфейси користувача для обробки функції X"
• "Поступова реєстрація для запиту на функції # 1234 та помилки № 5678"
• "Я зламав останню збірку. Це файли, які я пропустив."

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

Це зменшує кількість WTF / хвилину;)

що перетворюється на щасливішу команду (яка вас не ненавидить), а краща команда потенційно за менших витрат

Тож решта вашої команди знає, що WTF ви проводите перевірку змін у проектному дереві.

тому що якщо ви не практикуєте введення пристойних повідомлень про прихильність, ви опинитесь як мій колега, який вводить такі повідомлення

no changes

або

testing

для комісій із понад сотнею змінених файлів (тут не жартую !!).

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

Чому ви берете на себе зобов’язання, якщо зміни не мають сенсу?

Просто здійснюйте зміни, які мають значення. Наприклад, я зробив досить великий рефакторинг на другому тижні, який зайняв у мене близько 3 днів. Я мав би тонни комісій за цей час. Деякі були досить невеликими змінами ("перейменований клас X у Y, щоб відобразити нову відповідальність" або "метод Z () перейшов у клас Q"), а інші були дуже великими. Коли я закінчую функцією / рефакторингом, я перевіряю, чи можуть бути скасовані деякі коміти (принаймні, це підтримує git, не знаю про інші інструменти), але зазвичай я залишаю їх так, як це допомагає пізніше.

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

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

Але, на жаль, номер редакції не говорить вам про те, коли ви змінили X чи Y. Тож його вибір вибирав або читати всі коди, вчинені протягом останніх N днів, або просто читати детальні повідомлення про фіксацію, які ви написали (набагато читабельніше, ніж код).

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

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

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

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

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

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

Все, що вам потрібно зробити в коментарі, - це викласти причину словами, навіть якщо вона є тільки wip: adding new state objects

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

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

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

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

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

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

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

Отож, що керівник цього коду через 1 рік знає, на кого шукати цей жорстокий код. :)