Як здійснити незавершене рефакторинг?

Отже, у мене є цей великий проект, який переробляється мною. Я змінюю багато речей, тому шансів змусити його скоріше скластись незабаром. Я живу в спеціальній гітці, яку я назвав cleanup(яка, звичайно, збирається об'єднатись master).

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

Як ти гадаєш? Чи є рішення, яке я не помічаю?
Чи можу я пізніше сказати git для збирання комітетів чи щось таке? Я міг би жити з невиконанням зобов'язань, поки вони залишаються у cleanupвідділенні.

Редагувати

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

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

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

git checkout master
git merge --squash cleanup
git commit -m "Merge cleanup branch"

git rebase -iКоманда може також сквош коммітов , але вимагає більше роботи.

Перезапис - це не рефакторинг

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

Мартін Фаулер визначає рефакторинг як :

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

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

Якщо ви застосовуєте цей метод, ви можете здійснювати (і натискати) на регулярній основі.

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

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

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

Ви використовуєте Git, тому виконання зобов’язань не обов'язково означає підштовхування змін ...

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

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

Редагувати

У такому випадку ви можете використовувати git cherry-pickабо грати з нимиgit rebase