Мы новички в git в моей компании, пришли в git из Subversion, и в выходные мы столкнулись с ситуацией с веткой в нашем репозитории, когда были сделаны коммиты для публичной версии ветки, которую мы не делали 'не хочу там.У нас было:
A -> B
И затем мы получили плохие коммиты, чтобы поместить ветку в:
A -> B -> C -> D
C, и D никогда не должен был быть в этой ветке.Проблема в том, что эта ветка была «закрыта» - это была выпущенная версия нашего программного обеспечения, и в этой ветке не должно было быть никаких новых коммитов.
В Subversion единственный выход из подобной ситуациидолжен был зафиксировать! D и! C, чтобы вы получили:
A -> B -> C -> D -> !D -> !C
, который возвращает меня к B, но заставляет меня двигаться вперед по временной шкале для ветви, так что любой, кто имеет удаленный доступ к ветви, синхронизируетс главным репозиторием получал бы C и D и затем отменял их, чтобы в конечном итоге получить логически похожую версию B (но не B - назовите ее B ').
Я сталкивался с этим решениемдля возврата коммитов в git , который казался идеальным: он вернул бы наш публичный репозиторий к A -> B.Но это означало, что любой клон этой ветки на чьей-либо рабочей машине был бы очень неправильным, и каждый должен был бы повторно клонировать.Мое исправление составило:
git checkout thebranch
git reset --hard <<commit # associated with commit B>>
git push --force
Я закончил путь по вышеуказанной ссылке, и это вызвало переполох:
a) Вы можете выбросить историю коммитов в публичном хранилище.с помощью git, как это, буквально переписываем коммит-реальность;
b) Каждый должен был повторно клонировать, чтобы не рисковать повторным внедрением C -> D в ветку (или новую ветвь этой ветвичто мы хотели создать).
Я думаю, что должен сделать:
git revert HEAD~2
git commit
git push
Но это оставило бы ветвь как A -> B -> C -> D -> E, и это действительно должноУ меня нет C -> D -> E, потому что он должен быть закрыт.
У меня есть три вопроса:
- Как я мог бы справиться с уборкой лучше?Использовать
revert вместо reset?Какова лучшая практика для загрязнения веток? - Действительно ли
push --force возвращенной ветки действительно уничтожили историю в публичном хранилище?Или git откатился к B, но сохранил запись C -> D, и что в какой-то момент я сделал возврат к B?Это определенно не показывает возврат в журнале фиксации, но, возможно, запись о моих действиях хранится где-то еще? - Как вы обрабатываете «закрытые» ветки в git так, что эти изменения не могли иметьполучил там в первую очередь?У нас действительно был тег, примененный к хранилищу при коммите B, и люди должны использовать тег branch +, чтобы получить исходный текст для релиза, но это все еще страшно, чтобы изменения отображались в ветке ветки, которая не должна иметьизменения в нем после коммита B. И кто-то, переходящий из ветви для выпуска патча, мог легко пропустить тег и вытащить
C -> D в свою новую ветку.