Що робити, коли я вже занадто довго чекав між комітами?

100

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

Що краще?

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

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

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

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

— дуррон597
джерело

2

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

— alexis

6

Принаймні, зареєструйте це у відділенні, щоб ви не втратили своїх змін.

— Мисливець Рорі

2

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

— haylem

40

№1, моліться про прощення, а потім ідіть і не грішіть більше :)

— Петрис,

5

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

— Док Браун

52

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

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

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

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

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

— Карл Білефельдт
джерело

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

— durron597

1

Інша річ, що стосується 3 та 5, - це те, що будь-яку роботу, яку ви робите зараз, щоб дозволити їм відбутися, ви могли зачекати, поки вам це справді потрібно, а потім виконати ту саму роботу. Напевно, у майбутньому це буде дещо складніше, тому що пам’ять про те, що ти робив, вже не було. Але знову ж таки, напевно, вам це ніколи не знадобиться.

— Стів Джессоп

На мій досвід, клопітно і крихко покладатися на коментарі контролю версій, щоб розповісти історію, чому код існує (тобто причини 1 і 2). Якщо ви використовуєте SVN з гілкою, так чи інакше, історія фіксування втрачається на злиття (вам краще буде працювати з більш сучасними матеріалами, такими як git). Тож ці ІМХО найкраще подаються з коментарями.

— Ганс-Пітер Штерр

1

@hstoerr - якщо ви перебуваєте на Subversion 1.5 або пізнішої версії, ви можете зберегти історію за допомогою параметра --reintegrate після об'єднання.

— Дастін Кендалл

1

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

— Spidey

39

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

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

— FrustratedWithFormsDesigner
джерело

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

— durron597

3

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

— Кенні Евітт

3

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

— Стівен C

3

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

— Maciej Piechotka

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

— Стівен C

19

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

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

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

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

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

Прототипування та переписування

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

Коли ви розробляєте прототип нового коду, виконайте вказівки, коли ви хочете зберегти свої зміни, майже напевно, у відділенні, але, можливо, в окремому проекті. А може навіть взагалі просто працювати поза контролем версій. Ви можете замість цього зосередитись на зборі доказів щодо доцільності різних гіпотез чи проектів, які ви розглядаєте. Я часто пишу невеликі прототипи, використовуючи різні інструменти, наприклад LINQPad замість Visual Studio для коду C #.

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

— Кенні Евітт
джерело

1

Хороша відповідь; Кенні, ти маєш хорошу статтю чи іншу базу знань, щоб зв’язати більш конкретні деталі щодо складання прототипів? Моя версія прототипування - "ескіз у зошиті чи на дошці"

— durron597

@ durron597, я не можу придумати жодних посилань (навіть шукати) у верхній частині голови. Я розігрував достатньо інтерпретованих (і динамічно складених) мов програмування, що навіть не думав, що ідея «прототипування» може бути новою! І я переписав стільки програм C, C ++ та Java (знову і знову), що я не думав, що це теж може бути нечасто, або, принаймні, новим для деяких.

— Кенні Евітт

12

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

Тому я б пішов на варіант 1. Якщо це неможливо, то варіант 2.

Варіант 3 вимагає великих зусиль, і цього просто не варто.

— БЈович
джерело

1

або позначте некомпілюючі версії як "НЕ КОМПЛІКУЙТЕ"

— храповик виродка

2

@ratchetfreak: Я думаю, що "тег" у SVN не дуже допоможе, оскільки теги не працюють як "коментарі" на магістралі.

— Док Браун

@DocBrown Я мав на увазі додати його до повідомлення про скоєння

— храповика виродка

5

@ratchetfreak Я зробив би це як "ЧАСТИНА Х / Н: перевірка в ABC - НЕ КОМПІЛЮЄ"

— BЈович

Варіант 3 не вимагає великих зусиль. Інша відповідь пояснює, як це зробити швидко та легко за допомогою git add --patchта git stash. Ситуація здається лише складною через застарілі засоби управління джерелами та знання.

— Рон Макнейл

7

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

Коли я опинився в подібній ситуації, я застосував таку техніку:

Додайте лише той код, який стосується певної функції: git add --patch
Закрийте всі інші зміни: git stash save --keep-index
Запустіть тести / спробуйте скласти
Внесіть зміни, якщо все добре, якщо не перейти до 1

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

— Мілош
джерело

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

— durron597

1

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

— joeytwiddle

За допомогою git ви також можете додавати інтерактивно (add -i) перед фіксацією та відгалужувати згодом, щоб перевірити ваші зобов’язання незалежно.

— riezebosch

3

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

Це повинно бути простіше, адже ви вже написали код, це лише трохи з'ясувати, які частини скопіювати та вставити з вашої тимчасової резервної копії.

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

— Супербест
джерело

Це лише спосіб зробити варіант №3. Напевно, найкращий спосіб, правда, але все-таки досить трудомісткий.

— durron597

Коли я зробив одну велику обробку, було 149 рядків Додавання / Видалення / Надсилання повідомлень. Ось хоча б півдня на це.

— durron597

@ durron597 Я не згоден, я думаю, це відрізняється від №3. Щодо 149 рядків, наскільки ви цінуєте чисту історію фіксації? На що варто витрачати півдня? У будь-якому випадку, це не так, як для інших методів не потрібно буде з'ясувати, яка лінія повинна бути в якій комісії, тому вам доведеться пройти через 149 рядків у будь-якому випадку. Різниця в часі буде невеликою.

— Супербест

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

— durron597

Вам не потрібно робити резервну копію всього репо . Ви можете зробити "резервне копіювання", а потім відкатати ГОЛОВУ за допомогою git reset HEAD~. git reflogЯкщо ви вирішите, що вам потрібно, пізніше ви виконуватимете зобов'язання . Ви навіть можете відключити гілку (а потім перейти до робочої гілки) перед тим, як виконати скидання, щоб дати вашому "резервному копію" ввести ім'я. Пізніше видаліть гілку, якщо вона вам не потрібна. Редагувати: Вибачте, не зрозумів, що OP на SVN!

— joeytwiddle

3

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

Ви, швидше за все, відкочуєте "частини" того, що зробили? Якщо ні, то абсолютно приступайте до варіанту 1.

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

Програміст, який потрапляє в проект пізніше, навряд чи захоче повернутись до версії, яка не компілюється. Отже, ІМХО, варіант 2 - це безумство.

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

Ітерація: перевіривши свій код, ви прикриваєте / зберігаєте задник у разі виходу з ладу на вашій машині. Все інше, в команді одного чоловіка, - оформлення вікон.

— Не я
джерело

1

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

— Aaronaught

Між іншим, саме тому команди, які використовують Git, як правило, ненавидять об'єднання об'єднань і вимагають / вимагають повторних баз; злиття здійснює перерву bisectта інші методи, які зазвичай використовуються для ізоляції проблем, оскільки так багато змін вкладаються в один величезний комітет.

— Aaronaught

1

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

— NotMe

1

@Aaronaught Я додам, що ти сам через 3 місяці можеш стати «іншим програмістом».

— Мацей П'єхотка

1

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

— Aaronaught

2

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

Кожне абсолютно непорушне правило: ніколи не перевіряйте код, який навіть не складається, і серйозно уникайте перевірки коду, який не працює.

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

Це також хороший спосіб навчити себе хорошим навичкам програмування.

— gnasher729
джерело

Це логічно те саме, що відповідь на основі Git вище ( git add --patchі git stash) і хороший приклад сценарію, з яким сучасні DVCS можуть легко впоратися, але старі системи не можуть.

— Рон Макнейл

1

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

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

— Рой
джерело

1

це , здається, не додає нічого суттєвого за те , що вже писав в раніше 12 відповідей

— комара

-1

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

Насправді не має значення - що важливо, ви втратили контроль над своїм кодом, і ваш код став некерованим. Це нормально, це просто означає, що у вас є технологічна заборгованість і настав час подумати про рефакторинг. Отже, ви розчаровані? Ваш код не компілюється, у вас навіть немає одиничних тестів? Як ви можете думати про рефакторинг в цьому випадку? Не хвилюйтесь. Закінчіть «ковбойське кодування» і починайте його чистити. В ідеалі спробуйте написати кілька тестів. У вас немає часу на це? Гаразд, почніть з невеликих удосконалень.

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

Після цього ви побачите, що наступна зміна не займе вас «занадто довго» (що б це не означало).

— AlexT
джерело

2

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

— Idan Arye

@IdanArye З оригінального запитання ...Try to break it into smaller commits that likely won't compile...Якщо щось заважає вам ввести код, ніж це вже добре заспівати, цим кодом важко керувати. «Звернутись» - це лише один із способів наполегливо працювати. Можна подумати про більш крайній випадок - "якщо щось заважає мені зберегти вихідний файл". То що це могло бути? Я думаю, це страх перед вашими власними змінами. Чому це може бути? ... Я здогадуюсь, що ти отримав бал

— AlexT

2

Мені здається, більше схоже на те, що заважало йому чинити лише лінь.

— Ідан Ар'є

@IdanArye Ви праві в усіх аспектах. Це плюс недостатня кількість TDD, що є окремим питанням.

— durron597

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

— durron597