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

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

Тем не менее, это приводит к тому, что git push --forceпосле перезагрузки мне часто приходится делать удаленный репозиторий - действие, которое обычно не одобряется. Или, как сказано на связанной странице github:

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

Существует ли (общепринятая) политика, которая разрешает этот конфликт?

Почему это не дубликат. Так ли важен мерзавец "Золотое правило перебазирования"?

Мой вопрос здесь требует политики для разрешения конфликта между желанием сделать резервную копию вашей работы в удаленном репозитории и перебазированием вашей работы , в то время как другой вопрос пытается отрицать, что существует конфликт, и спрашивает, почему некоторые люди думают, что конфликт существует вообще, и, таким образом, спрашивает, почему «важно», чтобы не подталкивать силы перезагрузки?

Ключевой вопрос, который нужно задать себе:

• Сохраняете ли вы удаленную ветку после слияния с мастером?

Если вы удалите ветку удаленного компонента после слияния с мастером, вы уже потеряете историю. Предполагая, что вы раздавили / перебазировали ветку до того, как сделали слияние / PR, вы потеряете эту историю. В этом случае все, что вы делаете принудительно, позволяет вам использовать github в качестве резервной копии.

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

Я полагаю, вы спрашиваете, оставлю ли мне ветку без поддержки? Нет, AFAIC. Тем не менее, принудительное принудительное использование может теоретически привести к потере коммитов от других пользователей, которые отправили в ту же ветку.

Похоже, у вас есть несколько человек, которые толкают к этой ветви одновременно. Это означает, что вы заботитесь об истории на ветке.

Что вы могли бы сделать вместо этого для своей промежуточной работы, так это создать ветвь этой ветки. Вы можете нажать на это, а затем повторно объединить все свои коммиты в один коммит до слияния, поэтому, когда вы объединяете их в свою функциональную ветвь, у вас есть только 1 коммит (с перебазированной историей всей вашей ветки).

Я перечисляю некоторые возможности, которые приходят мне в голову.

Всегда ребаз на новую ветку

Если у вас грязная ветка some-feature, перебазируйте ее на новую ветку. Например

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Затем some-feature-rebaseпересмотрели и интегрировали.

Проблема: большой недостаток в том, что, строго говоря, вам нужна новая ветвь для каждой перебазировки. (Например, вы можете сделать несколько перебаз, если внесете изменения после проверки кода)

использование git push --force-with-lease

Я только что узнал об git push --force-with-leaseальтернативеgit push --force , которая

отказывается обновлять ветку, если мы не ожидаем того состояния; т.е. никто не обновил ветку вверх по течению.

Проблема : Это, кажется, улучшается непосредственно в ситуации, когда мы используем just --force, но все еще есть некоторые предостережения, особенно когда я делаю git fetchвместо a git pull, который обновляет наши локальные ветки upstream, обманывая себя, --force-with-leaseдумая, что на удаленном сервере не было внесено никаких необъявленных изменений. филиал.