Не могу сказать, что полностью понимаю рабочий процесс, для которого вы снимаете.График, который вы нарисовали, не является типичным для графа git commit, что само по себе нормально, но этот график, кажется, не представляет отношения между коммитами и ветвями таким образом, который может быть точным в git.Поэтому мне, в основном, придется поверить на слово, что вы нашли более или менее подходящий рабочий процесс, и ограничить мой ответ прямыми вопросами, которые вы задали:
1) Поскольку ветвь - это просто указатель накоммит, вы можете легко переименовать master в develop и затем воссоздать master где бы вы ни хотели.
git checkout master
git checkout -b develop
git branch -d master
Имейте в виду, что как только вы создадите master где-то в другом месте, оно, вероятно, появитсячтобы двигаться непредвиденным образом.Таким образом, если master было отправлено на удаленный компьютер, следующая попытка нажать master завершится неудачей, если вы не используете push -f (или, лучше, push --force-with-lease).Это приведет к принудительному принудительному запуску, но принудительное принудительное переключение переведет всех, кто совместно использует пульт, в «сломанное» состояние, поэтому некоторая очистка должна быть согласована с ними.(Невозможность скоординировать это может привести к отмене принудительного толчка.) См. Документы git rebae в разделе «восстановление после исходной перебазировки».https://git -scm.com / docs / git-rebase
2) Слияние не «закрывает» ветвь.Исходная ветвь не затронута слиянием.Целевая ветвь либо (a) перемещается к коммиту, указанному в исходной ветке (в случае ускоренной перемотки вперед), либо (b) получает новый «коммит слияния», который включает изменения из исходной ветки.
3) Возможно.Опять же, я не знаю, чтобы правила вашего рабочего процесса были полностью объяснены, чтобы мы могли это прокомментировать.
4) После того, как работа зафиксирована, ее очень трудно потерять, даже если она зафиксирована только «локально»;в этом смысл git
5) Опять же, эти диаграммы не отражают то, как коммиты и ветви связаны в git.Вы можете получить что-то вроде
O ----------- MC ----------------- MH <--(master)
\ / /
A -- B -- C -- D -- E -- F -- H <--(develop)
, где MC и MH - это слияния develop в master.Обратите внимание, что в этом случае отдельные коммиты все еще являются частью истории master.Иногда вы можете «сфокусироваться» только на коммитах в «верхней строке» этой диаграммы - т.е. git log --first-parent master;но если вы поделитесь master с другим репо, он получит все.Избежать этого сложнее, чем просто «создать правильные ветви».
Существует несколько подходов к обмену текущими обновлениями с ограниченной историей.
Один из способов - сохранить ветку клиента, о которой думает gitкак "не связанные" с историей развития.Это может работать так:
У вас есть какая-либо структура веток, которая используется в вашем локальном репо, и вы в конечном итоге объединяетесь, чтобы освоить «версию 1.0», которой вы хотите поделиться.Таким образом, вы создаете ветку client следующим образом:
git checkout master
git checkout --orphan client
git commit -m "Version 1.0"
Теперь у вас есть
C1 <--(client)
... V1 <--(master)
Теперь некоторые вещи происходят локально, пока у вас не появится Версия 2.0
C1 <--(client)
... V1 -- V2 <--(master)
/
... X
В прошлом я разработал все виды схем для отслеживания того, что уже находится в клиентской ветви, и / или расчета изменения от V1 и V2, чтобы его можно было применить к клиентской ветви.... но правда в том, что если V1 и C1 совпадают, то все, что вас действительно волнует, это как создать новый коммит C2, чей родитель C1 и чей контент (TREE объект) совпадения V2? "
git checkout client
git merge $(git commit-tree -p client -m "Version 2.0" master^{tree})
Теперь у вас есть
C1 -- C2 <--(client)
... V1 -- V2 <--(master)
/
... X
Если вы когда-нибудь добавите патчи от клиента, это может потребовать дополнительных размышлений.