Я хотел бы использовать git rebase
чтобы чисто объединить функцию в основном ответвлении (в меньшем количестве фиксаций или по крайней мере наверху журнала изменений). Обратите внимание, что я - единственный, работающий над репозиторием.
После того, чтобы читать рабочий процесс Мерзавца и переоснову по сравнению с вопросами о слиянии, я нашел git rebase
было бы довольно хорошо, и как Micah я хотел бы git push
переоснованные изменения просто, потому что я работаю над ними от различных мест (исключая: мой ноутбук, мой дом, другой ПК где-нибудь...)
Таким образом, вот два решения (к двунаправленному ужасному слиянию):
git push -f
продвигать, и затем надевание другой машины, но как чисто получить последнюю версию на других машинах?(2) был бы похож ниже:
git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a
То, какое решение делают Вы думаете, работало бы? Я не судил ни одного из них до сих пор (главным образом страхом перед созданием моего более грязного журнала).
Помните, что git rebase
повторяет изменения и создает новые коммиты. Выполняя ребазинг и принудительно проталкивая всё подряд, вы идёте против сути инструмента. Обратите внимание на то, как начинается раздел "Восстановление после пересохранения" документации git rebase
(выделено автором):
Пересогласование (или любая другая форма переписывания) ветки, на которой работали другие, - плохая идея: все, кто находится ниже по течению от неё, вынуждены вручную исправлять свою историю. В этом разделе объясняется, как сделать исправление с точки зрения нижестоящих. Настоящим исправлением, однако, было бы избегать пересборки апстрима в первую очередь.
Даже если вы единственный разработчик, вы все равно будете другим (с точки зрения одного репозитория) при работе в других клонах. Как вы видели, такой рабочий процесс доставляет много хлопот.
Пусть ваши изменения готовятся в ветках. Когда ветка будет готова к работе, затем сделайте ребазинг, объедините её с master и удалите её тематическую ветку. Ваша жизнь будет проще, если вы сделаете время жизни веток коротким, а их область применения узкой.
Я всегда проверяю, что фиксирую и нажимаю (-f) все с любой машины, которую я оставляю.
Когда я прихожу к какой-то другой машине:
git fetch -v
git checkout mybranch # Already checked out with old HEAD
git reset --hard origin/mybranch
Это хорошо работает, потому что я знаю, что другое «я» на разных компьютерах постоянно фиксирует и подталкивает, прежде чем я уйду (и, следовательно, на машине, к которой я приезжаю, нет неопубликованных изменений)