Чому, здається, у всіх DVCS є нераціональна фобія невмілих змін?

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

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

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

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

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

version-control dvcs

— Мейсон Вілер
джерело

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

— Теластин

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

— MetaFight

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

— Мейсон Уілер

Дійсно? "Стабілізований XYZ для злиття з основним" є чимось тягарем, чи збираєтесь надмірно ввічливу історію?

— Теластин

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

— jthill

Відповіді:

У світі DVCS комісії дешеві, а історія змінюється. WIP може бути настільки "брудним", як ви хочете: і я не бачу причин проти "скидання мого поточного стану в наборі змін для зберігання"
Історія SVN лінійна, отже, ви повинні об'єднати чернетки зі змінами нових версій. Використання DVCS (практично) DAG та додаткова головка (фіксація + підтягування + вгору) для розбіжної історії є безпечнішою, ніж об’єднання на ходу модифікованого робочого режиму з отриманими зовнішніми змінами
При переключенні (на якийсь вузол ) модифікований туалет в Subversion ви позбавляєтесь від одного потенційного додаткового злиття (всупереч "привласнення до старого" - "перемикання" - "об'єднання діапазону 1 об.") ... і ми знаємо: зливається у SVN не є ідеальною стороною інструменту, хоча це не є проблемою для DVCSes

Резюме

Це не фобія, це (іноді суворе) примусове дотримування гарних манер "здійснювати часто" (SVN-користувачі іноді бояться цього стилю)

І, нарешті, hg qnew|qpop|qpushневелика справедлива ціна за охайність і порядок

— Ледачий борсук
джерело

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

Тепер, що трапиться, якби gitдозволити вам заздалегідь побачити незавдані зміни у вашому робочому каталозі? У вас буде (більш-менш) важкий час для розмежування між конфліктами змін / злиття, про які вам потрібно подбати про злиття / вишневий вибір, та змінами, які ви представили. Крім того, вам було б неможливо перевірити, що ви насправді здійснюєте.

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

git stash
git pull
git stash pop

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

— cmaster - відновлення моніки
джерело