Это неправильный подход к этому, и он гарантированно вызовет больше головной боли и проблем, чем любая проблема, которую вы пытаетесь решить прямо сейчас.
Давайте предположим, что вам удалось реализовать предложенныйметод, что произойдет?
Что ж, в моем локальном репозитории, который я пытаюсь отправить, у меня есть наборы изменений 1, 2 и 3 с хэшами ABC, DEF и KLM.По какой-то причине я не использовал имя пользователя apache при фиксации, поэтому они неверны, в соответствии с вашими предлагаемыми изменениями.
Я отправляю на сервер.
В полете, ваш кодизменяет мои коммиты, чтобы вместо этого иметь имя пользователя apache.Это приводит к тому, что хэши этих наборов изменений пересчитываются и становятся разными.Другими словами, мои ревизии 1, 2 и 3 теперь будут иметь хэши XYZ, DEF и JKL.
Итак, мои изменения находятся на сервере.У меня не было конфликта во время push, так как я был последним человеком, клонирующим.
Однако, если я сейчас пытаюсь тянуть, я вдруг обнаруживаю, что есть 3 набора изменений, которых у меня нет, поэтому я вытягиваю их,и обнаружил, что теперь у меня есть эти 3 набора изменений параллельно с 3, которые у меня были, с тем же содержимым, другим именем коммиттера и различными хэшами.
Вот как каждый push и pullбудет вести себя с этого момента.
Вы нажимаете, и сразу же вы можете вернуть «те же» наборы изменений обратно, с новыми хэшами, в параллельную ветвь к вашей.
И теперь начинается самое интересное.Как ваш местный клиент узнает, что нажать?Он спрашивает сервер, «что у вас есть?», А затем сравнить это.Ну, на сервере по-прежнему нет ваших 3 исходных наборов изменений, поэтому исходящая команда выяснит, что ж, эти 3 набора изменений должны быть сдвинуты.
Но если вы попытаетесь применить это, вы затем создадите заново.те же самые 3 новых наборов изменений, которые нельзя толкать, поэтому у вас возникнут проблемы с этим.
Что вам нужно сделать, это навязать своим пользователям следующий рабочий процесс:
- Выдвиньте новые наборы изменений
- Вытащите новые наборы изменений в их новую форму
- Удалите исходные наборы изменений, которые были выдвинуты
*Подход 1036 * A
лучше был бы для сервера, чтобы в первую очередь предотвратить пуш, с сообщением об использовании неправильного имени коммита.
Затем вы возлагаете бремя на пользователя, чтобыисправьте эти наборы изменений, прежде чем пытаться выдвинуть их, например, импортировав их в MQ и применив их по одному за раз.
Или ... нет.
Что если я сделаю от вас отрыв?Вы исправляете ошибку, и вы еще не готовы отправить все на сервер, поэтому вы позволяете мне извлекать у вас информацию, и теперь у меня есть исходящие наборы изменений с вашим именем на нем и сервер, который принудительно установит my Назовите их все.
Примерно сейчас вы должны понимать, что этот подход вызовет много проблем, вы в основном пытаетесь заставить распределенную систему контроля версий вести себя как централизованная система контроля версий..