Почему DVCSs, кажется, все имеют иррациональную фобию незафиксированных изменений?

Исходя из опыта SVN, одна из самых сложных вещей, к которой нужно привыкнуть при работе с системами DVCS, - это то, как все они, похоже, рассматривают любое незавершенное изменение, как бомбу замедленного действия.

В Mercurial, если вы пытаетесь получить изменения и у вас есть какие-либо незафиксированные изменения в вашей рабочей копии, вам нужно перепрыгнуть через обручи, чтобы она просто объединяла входящие изменения. Попробуйте переключать ветви? Это заставит вас отложить все на полку, и тогда вам придется немедленно отложить все это на другом конце. (У SVN нет проблем ни с одним из этих сценариев.)

Git примерно так же. Я работаю бок о бок с другим разработчиком над проектом, и я просто попытался выбрать один из его коммитов в мою форк. Он отказался позволить мне, потому что у меня были незафиксированные изменения в моей рабочей копии, в совершенно других файлах, чем те, которые были изменены в его коммите. Там даже нет варианта слияния; по-видимому, я должен сначала спрятать свои изменения!

Если бы человек относился к чему-то совершенно безвредному с такой чрезвычайной осторожностью, я бы назвал это «фобией», иррациональным страхом, который следует рассматривать как психическое расстройство. Но Git и Mercurial были разработаны двумя разными командами разумных, рациональных разработчиков, поэтому мне интересно, знают ли они что-то, о чем я не знаю.

Есть ли техническая причина, которая оправдывает такое отношение к незавершенным изменениям? И если да, то почему рассматриваемая проблема существует только на DVCS?

version-control dvcs

— Мейсон Уилер
источник

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

— Теластин

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

— MetaFight

@Telastyn: Нет, вы не можете, потому что регистрация - даже в вашем местном филиале - требует причины фиксации и создает запись в истории. Поэтому, если вы отметите что-то, что еще не было готово для фиксации, в конце концов, когда вы будете готовы отправить изменения в удаленный репозиторий, эта история будет существовать, если вы не выполните дополнительные операции для перезаписи истории. Это не соответствует ни одному из определений «тривиального», которое я признаю, и мне кажется, что это очень сложная задача без каких-либо преимуществ.

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

В самом деле? «Стабилизированный XYZ для слияния с основным» - это какое-то бремя или слишком вежливая история?

— Теластин

Вы бы отправили статью для публикации, по крайней мере, для ясности? Тогда не отправляйте свой первый черновик коммитов для публикации. Сделайте всем, кто прочтет ваш код, большую услугу: вернитесь назад и создайте серию коммитов, которую вы написали бы, если бы у вас была предусмотрительность сделать это таким образом. Интерактивная перебазировка не сложная ..

— Jthill

Ответы:

В мире DVCS коммиты дешевы, а история изменчива. WIP может быть настолько «грязным», насколько вы хотите: и я не вижу никаких причин против «выбросить мое текущее состояние в набор изменений для хранения»
Таким образом, история SVN линейна - вы должны объединить свои черновики с изменениями из новых ревизий. DVCS использует (обычно) DAG, и дополнительная голова (commit + pull + up) для расхожденной истории безопаснее, чем объединение на лету модифицированного рабочего каталога с извлеченными внешними изменениями
Когда вы переключаете (на какой-то узел ) модифицированный WC в Subversion, вы избавляетесь от одного потенциального дополнительного слияния (в отличие от «commit to old» - «switch» - «merge 1 rev. Range») ... и мы знаем: merges в SVN не идеальная сторона инструмента, хотя для DVCS это совсем не проблема

Резюме

Это не фобия, это (иногда резкое) принуждение к тому, чтобы следовать хорошим манерам "совершать часто" (пользователи SVN иногда боятся этого стиля)

И, наконец, hg qnew|qpop|qpushнебольшая справедливая цена за аккуратность и порядок

— Ленивый Барсук
источник

Когда вы сливаетесь или выбираете вишню git, вы немедленно создаете коммит. Операция не завершена, пока эта фиксация не будет завершена и не станет частью истории.

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

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

git stash
git pull
git stash pop

у вас есть две (!) операции слияния. Тот, который объединяет ваш последний коммит с входящими изменениями, и тот, который объединяет ваши незафиксированные изменения с результирующим коммитом слияния. Таким образом, вам нужно всего лишь объединить две вещи в одну, чтобы избежать путаницы, которая может возникнуть в результате попытки объединить три вещи в одну за одну операцию, пытаясь игнорировать эти три вещи. git stash/ git stash popПозволяет легко и четко , что вы игнорируя ваши неподтвержденные изменения для слияния.

— cmaster - восстановить монику
источник