Ответ 1

Вы должны быть осторожны в этом, потому что он может переписать историю этой ветки - это создаст проблемы, если вы опубликовали ее, а другие люди работают над веткой. Кроме того, команда git reset --hard выкинет любые незафиксированные изменения (т.е. Только в рабочем дереве или индексе):

git checkout master
git reset --hard 1258f0d0aae

Вы также можете принудительно обновить ветвь с помощью:

git branch -f master 1258f0d0aae

... но git не позволит вам сделать это, если вы на master в то время.

Ответ 2

git reset --hard 1258f0d0aae

Но будьте осторожны, если потомок, совершающий связь между 1258f0d0aae и HEAD, не ссылается в других ветках, будет утомительно (но не невозможно) восстановить их, поэтому вам лучше создать "резервную копию", ветки на текущем HEAD, checkout master и reset на фиксацию, которую вы хотите.

Кроме того, убедитесь, что у вас нет незафиксированных изменений до reset --hard, они будут действительно потеряны (нет возможности восстановить).

Ответ 3

Если вы в настоящее время не находитесь на главном сервере, это очень просто:

git branch -f master 1258f0d0aae

Это делает именно то, что вы хотите: оно указывает master на данный коммит и ничего не делает.

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

git checkout 1258f0d0aae    #detach from master
git branch -f master HEAD   #exactly as above

#optionally reattach to master
git checkout master

Помните, однако, что любое явное манипулирование тем, где точки ветвления имеют потенциал, оставлять за собой коммиты, которые больше не доступны ни одному из ветвей и, таким образом, становятся объектом сбора мусора. Итак, подумайте, прежде чем вводить git branch -f!

Этот метод лучше, чем подход git reset --hard, поскольку он не разрушает ничего в индексе или рабочем каталоге.

Ответ 4

git branch -f <branchname> <commit>

Я соглашаюсь с решением Mark Longair и комментариями и рекомендую, чтобы кто-нибудь читал их до начала игры, но я бы сказал, что акцент должен быть сделан на

git branch -f <branchname> <commit>

Вот сценарий, где мне нужно было это сделать.

Сценарий

Разработайте на неправильной ветке и, следовательно, нужно reset it.

Начать нормально

Чисто разработайте и отпустите некоторое программное обеспечение.

Разрабатывать на неправильной ветке

Ошибка: Случайно оставайтесь на ветке выпуска, развиваясь дальше.

Понять ошибку

"ОН НЕТ! Я случайно развился в филиале релиза". Рабочее пространство, возможно, беспорядок с половинными измененными файлами, которые представляют собой незавершенное производство, и мы действительно не хотим касаться и возиться. Нам просто хотелось бы, чтобы git щелкнул несколько указателей, чтобы отслеживать текущее состояние и отбрасывать ответную ветвь, как это должно быть.

Создайте ветку для разработки, которая обновляет работу, совершенную до сих пор, и переключится на нее.

git branch development
git checkout development 

Исправить ветвь

Теперь мы находимся в проблемной ситуации и нуждаемся в ее решении! Исправьте ошибку (отнесение ветки релиза вперед с развитием) и положите ветвь освобождения назад, как она должна быть.

Исправьте ветвь релиза, чтобы вернуться к последней реальной версии.

git branch -f release release2

Отключенная ветвь теперь снова правильная, как это...