Как пересинхронизировать две ветви git?

Question

У меня есть две ветки, master и test. Когда я пытаюсь слить мастера в тест, git считает, что все в актуальном состоянии, но если я запустил git diff master test, я получаю разницу, которую я не ожидаю. В этот конкретный момент времени я ожидаю, что они будут полностью идентичны.

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

Есть ли более чистый способ пересинхронизации двух ветвей, или я должен просто укусить пулю и вручную повторно протестировать тестовый сервер здесь?

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

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

Answer 1

Является ли тест основанным на разветвленном мастерстве?

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

Если вы используете github или gitlab, вы можете проверить свой сетевой график, чтобы узнать, что с ними связано.

Кроме того, убедитесь, что вы не изменили свой gitignore в какой-то момент.

Если мастер стоит за тестом, единственный разумный способ, я могу думать о том, что вы его синхронизируете, - это слияние теста с мастером, но это было бы, когда вы хотите взять это на производство.

Answer 2

Не полный ответ, потому что это не достаточно информации для полного ответа, только несколько предложений:

1. запустить git log test --not master. Таким образом, вы получаете список коммитов, которые находятся в test, но не в master.
2. Обратные аргументы (... master --not test). Вероятно, вы получили бы пустой список здесь
3. Конечно, вы не должны добровольно удалять опубликованные ветви, таким образом, вы можете создавать различные проблемы для вас и/или ваших сотрудников. Но если вы четко понимаете, что такое состояние вашего репозитория, вы можете использовать git push -f. Но подумайте дважды, прежде чем принудительно переопределить состояние удаленного remository.
4. Хороший способ понять текущее состояние репо - это визуализировать его, например. с локальным инструментом, например, gitk --all или удаленным сервисом (для каждого популярного хостинга, такого как github или gitlab, для этого есть свои собственные webtools).
5. Я бы предложил использовать git blame <file> (или даже git gui blame <file>), чтобы понять, от чего зависит конкретная линия. В качестве альтернативы вы можете сделать git log -p, чтобы получить список фиксаций со своими изменениями.
6. В любом случае я бы оценил необходимость ручного восстановления репо как чрезвычайно низкого.Вероятно, у вас есть относительно простая проблема, и просто не хватает информации, чтобы полностью ее понять.