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

Працюючи над виправленням або функцією, я іноді натрапляю на інші крихітні проблеми, які за лічені секунди можна вдосконалити. Коли я роблю їх негайно, а потім здійснюю готову функцію / виправлення, комісія включає більше ніж одне. Наприклад "add feature X and code clean up"або "fix bug X and improved logging". Було б краще розділити це на два коміти. У випадку, якщо дві зміни відбулися в одному файлі, я не можу просто додати один файл, зробити фіксацію, додати інший і знову зробити знову. Тому я бачу такі три варіанти:

1. Навмисно забувайте про непов'язані речі, працюючи над чимось.

2. Скопіюйте файл з двома змінами, відновіть його, включіть одну зміну, введіть, включіть іншу зміну, повторіть.

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

Мені не дуже подобаються всі три варіанти з наступних причин:

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

2. Це збільшує ручну роботу та схильне до помилок.

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

Як ви справляєтеся з такими ситуаціями?

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

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

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

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

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

Мій редактор має плагін, який робить постановку окремих частин файлу надзвичайно простим. Я думаю, що інші редактори програмістів можуть мати подібні плагіни, хоча ви завжди можете це зробити вручну git add --patch | -p. Тоді я використовую git stash, щоб врятувати інші зміни, щоб перевірити свою маленьку комісію в ізоляції. Потім, коли я вчиню, я просто виконую git stash popта продовжую там, де я зупинився. Саме для цього були розроблені ці функції.

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

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

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

Варіант, який я досить TODOчасто використовую, - це додавати коментарі, а потім робити багато частих "часткових" комісій, використовуючи git add --patchдля вибору відповідних частин файлу. Потім використовуйте git rebase --interactiveдля впорядкування та об'єднання часткових комісій у остаточну функцію, а фіксація фіксує, перш ніж натискати на них.

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

У git rebaseцьому контексті немає нічого поганого, оскільки ви лише переписуєте місцеві комітети.

Іншим варіантом може бути "приховування" поточних змін. Робочий процес виглядатиме так:

1. Почніть вносити зміни, пов’язані з функцією A
2. Відкрийте помилку B і вирішіть її негайно виправити
3. З командного рядка вашого репо виконайте git stash (Після цього ваш код повернеться до стану, в якому він був, перш ніж ви почали працювати над функцією A )
4. На цей момент ваші невідомі зміни для Feature A зберігаються у "сховці"
5. Зробіть зміни в коді, необхідні для виправлення помилки B, і виконайте зобов'язання назад у репо
6. З командного рядка запустіть git stash pop
7. Ваші незапущені зміни для Feature A тепер вискочують з кошика та відновлюються до вашого коду, що триває, поруч із (уже здійсненим) виправленням для помилки B

Окремо поетапно (і виконайте) зміни, пов’язані з виправленням помилок. У розширеннях Git це зробити надзвичайно просто. З командного рядка, я думаю, що вам потрібно зробити git add -p.