Сделайте текущую ветку Git главной веткой
Некоторые идеи:
- Только серверная. Самый простой способ сделать это - использовать переменные сеанса (например,
$_SESSION), так что все данные, хранящиеся на стороне сервера, но управляющие им и сохраняющие отдельные вкладки, которые пользователь может иметь открытые отдельные, могут немного запутаться. Этот параметр запрещает пользователю просматривать или редактировать информацию. - Сделать клиентом перенос зашифрованного блоба. Возьмите все ваши «временные, но защищенные» данные, соедините их как-то (например, JSON), а затем зашифруйте * все это с помощью секретного ключа, известного только серверу. Результат Base64 и поместите это в значение скрытого поля. (Обратите внимание, что для приложения с высокой степенью защиты вы также захотите задействовать HMAC в этом процессе, который проверяет, что шифрованный текст не был переделан.) Этот параметр также запрещает пользователю просматривать или редактировать информацию, но упрощает обработку случаев, когда один пользователь открывает много вкладок.
- По-прежнему используйте скрытые скрытые поля ввода, но добавьте механизм защиты от несанкционированного доступа. Поэтому, когда страница сгенерирована, возьмите все существующие «защищенные» переменные, соедините их каким-то образом с секретным значением на стороне сервера и хешем [исправление: HMAC]. Храните хэш в своем скрытом поле. Затем после того, как пользователь отправит, вы повторите процесс и проверьте соответствие хэша. Если это не так, сделайте все с ошибкой на странице нарушения безопасности.
* Как и при всей криптографии, это «правильный» способ может быть сложным и сильно зависит от того, как вы шифруете / проверяете. Есть много подводных камней с точки зрения шифров и шифровых режимов и т. Д.
Наконец, помните, что предотвращение изменения людьми не означает, что пользователь не может копировать все и повторно использовать его позже или под другой учетной записи, если вы не предпримете шаги для включения «отметки времени» и т. д.
5 ответов
Проблема с двумя другими ответами заключается в том, что у нового мастера нет старого мастера в качестве предка, поэтому, когда вы его нажмете, все остальные будут сбиты с толку. Это то, что вы хотите сделать:
git checkout better_branch
git merge --strategy=ours master # keep the content of this branch, but record a merge
git checkout master
git merge better_branch # fast-forward master up to the merge
Если вы хотите, чтобы ваша история была немного яснее, я бы рекомендовал добавить некоторую информацию в сообщение фиксации слияния, чтобы прояснить, что вы сделали. Измените вторую строку на:
git merge --strategy=ours --no-commit master
git commit # add information to the template merge message
Для меня я хотел, чтобы мой devl вернулся ведущему устройству после того, как это было вперед.
, В то время как на разработайте:
git checkout master
git pull
git checkout develop
git pull
git reset --hard origin/master
git push -f
Переименуйте ветку в master по:
git branch -M branch_name master
Приведенные здесь решения (переименование ветки в 'master') не настаивают на последствиях для удаленного репозитория (GitHub):
- если вы ничего не нажимали с момента создания этой ветки, вы можете переименовать ее и отправить без каких-либо проблем.
- если у вас есть push master на GitHub, вам нужно будет 'git push -f' новую ветку: вы больше не можете нажимать в режиме быстрой перемотки вперед .
-f
--force
Обычно команда отказывается обновлять удаленную ссылку, которая не является предком локальной ссылки, использованной для ее перезаписи. Этот флаг отключает проверку. Это может привести к тому, что удаленный репозиторий потеряет коммиты; используйте его с осторожностью.
Если другие уже загрузили ваше репо, они не смогут получить эту новую основную историю без замены своего собственного мастера этой новой главной ветвью GitHub (или работы с большим количеством слияний).
Есть альтернатив git push --force для общедоступных репозиториев .
Ответ Джефроми (слияние правильных изменений с исходным мастером) является одним из них.
Edit: Вы не сказали, что выложили в публичное репо! Это имеет большое значение.
Есть два способа, "грязный" способ и "чистый" способ. Предположим, ваша ветка называется new-master. Это чистый способ:
git checkout new-master
git branch -m master old-master
git branch -m new-master master
# And don't do this part. Just don't. But if you want to...
# git branch -d --force old-master
Это заставит файлы конфигурации измениться в соответствии с переименованными ветками.
Вы также можете сделать это грязным способом, который не будет обновлять файлы конфигурации. Вот что происходит под капотом вышеописанного...
mv -i .git/refs/new-master .git/refs/master
git checkout master