Является ли возврат к исходной ветви функций, добавление здесь новых изменений, а затем объединение их снова в Dev, используя новый запрос на извлечение, лучший способ добавить новые изменения?
Исходя из моих собственных, полностью согласен с мнением, о котором упоминалось выше. Как то, что вы хотите достичь, я не думаю, что использование revert
хорошая идея. Потому что это на самом деле сделает беспорядок в вашем хранилище.
Как вы сказали в комментарии, после revert
вы должны заново выполнить все изменения в ветке feature
, которая включает в себя ветку, слитую ранее, но позже отмененную. Его преимущества в том, что он может обеспечить целостность истории ваших репозиториев. Но я не думаю, что это был бы лучший способ в вашем сценарии.
Что еще более полезно для объяснения, первоначально запрос на объединение был объединен feature
ответвлением в dev
ответвление, а затем вы обнаружил, что вам нужно добавить другие изменения в один из файлов.
Итак, почему бы сразу не внести это новое изменение в ветку feature
, а затем снова сделать pu sh в ветке dev
?
Что касается вас, то, если вы создадите новую ветку, чтобы применить новое изменение, это вызовет проблемы, когда их нужно объединить с другой веткой, потому что вы должны синхронизировать их c друг с другом, или это легко вызовет конфликт.
Другой вариант, если вам нужно создать новую ветку. Вы можете создать эту новую ветку на основе feature
ветви. После того, как новое изменение применяется к файлу, объедините новую ветку с веткой feature
с помощью запроса на извлечение. Затем объедините ветку feature
с веткой dev
.
В настоящее время новую ветвь можно удалить, поскольку все изменения синхронизируются c с ветвью feature
. Также вы можете продолжить работу над веткой feature
позже.
Что это значит и как я могу проверить конфликты?
Есть еще одна ветка , объясняющая это очень подробно. Вы можете проверить это.
Чтобы решить эту проблему, вы можете попробовать с помощью приведенного ниже сценария:
# Unstage conflicts
git reset HEAD ./
# Unstage deletions and reset everything back to master
git checkout -- ./
# Cancel the pending revert operation
git revert --abort
$ git checkout 8a750f
# Make use of tag feature, it can help for this kind of issue in the future.
$ git tag mark
$ git push origin mark