Как задним числом добавить коммиты в репозиторий Git?

Вопрос немного необычный / неясный, в основном потому, что он, похоже, не задан в «Пути Git» / контексте просмотра системы управления версиями. «Головы» в Git имеют более одного значения... это не означает то же самое, что и в SVN, например. К этому моменту я вернусь позже, но сейчас я попытаюсь решить то, что кажется проблемой добавления предыдущих версий базы кода в репозиторий Git.

Как задним числом добавлять коммиты в Git

У вас есть как минимум два варианта:

1. Добавьте предыдущие версии кодовой базы как потерянные, отдельные ветки. Это не то, что я рекомендую, потому что, по моему опыту, потерянные ветки неэффективны для переключения между ними в вашей рабочей копии, вероятно, потому, что операция checkout не имеет доступа к общим предкам и тому подобному.
2. Вы можете добавить предыдущие версии как осиротевшие ветки, но затем перебазировать новейшую ветку v10/master поверх них и добавить новые теги.

Я рекомендую вам использовать вариант № 2, так как это проблема, которая ранее решалась в Stack Overflow, и для решения этой проблемы больше подходит «Путь Git»:

1. git: как вставить коммит первым, смещая все остальные?
2. Git: как добавить коммиты перед first/initial/root совершить?)

В частности, я рекомендую вам выполнить следующие основные шаги, которые я даю подробное объяснение в этом ответе:

1. Создайте резервную копию вашего репозитория:

   git clone original-repo backup-repo
   

2. Создайте ветку-сироту (это будет ваш новый корень).

   git checkout --orphan new-master firstCommitOfOldMaster
   

3. Удалить файлы рабочего каталога из ветки-сироты.

   git rm -rf .
   

4. Повторно передать старую работу в new-master.

5. Перебазируйте старый master на new-master.

   git rebase --onto new-master --root master
   

6. Убедитесь, что окончательный коммит не изменился.

   git diff master@{1}
   

Либо до того, как вы перебазируете старый мастер на новый, либо после этого вы можете пометить свою ветку v9 тегом облегченный тег или аннотированный тег:

# Lightweight
$ git tag "v9"

# Annotated
$ git tag -a "v9" -m "Tag version 9"

Объяснение ГОЛОВЫ

Таким образом, «головы» в Git имеют несколько значений, в зависимости от контекста. В контексте, который вы используете в качестве фиксации, ссылкаHEAD просто означает фиксацию, которую вы в настоящее время извлекли в свою рабочую копию. Это не означает то же самое, что и в SVN, то есть HEAD не представляет самую последнюю глобальную фиксацию в репозитории.

Когда вы выполняете проверку между ветвями или коммиты вдоль этих ветвей, HEAD будет указывать на разные коммиты в вашей истории (иногда на предыдущие коммиты), потому что вы проверяете разные коммиты в своей рабочей копии. Видеть

1. Что такое git HEAD?.
2. HEAD и ORIG_HEAD в Git.

В Git есть еще один контекст, где используются «заголовки»: ветки, которые являются локальными по отношению к репозиторию, обычно хранятся в каталоге .git/refs/heads/. В этом контексте «головы» означают просто указатели/ссылки на ветки и являются «советами»/самой последней фиксацией для ветки. Вы можете увидеть заголовки/подсказки ветки вашего локального репо, запустив git show-ref:

git show-ref
35ec88f1c5b319b7ca08f5d3dca3cafdebddecd4 refs/heads/awesome-feature
ea112e91953e02f9c6dcc7b9470b8bdf0a69a3eb refs/heads/epic-feature
a9874fd23f67c245fadd23bef449971fa7338755 refs/heads/master

Здесь вы можете видеть, что у меня есть 3 главы/подсказки/ссылки веток: ветка master, ветка awesome-feature и ветка epic-feature. Слева от каждой ветки вы увидите полный коммит sha, на который в данный момент указывает ветка, то есть самый последний коммит для этой ветки.

Объяснение перебазирования

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

С учетом этого я не буду вдаваться в подробности о том, как работает git rebase, так как есть много онлайн-ресурсов, объясняющих это (я перечислю их), и этот ответ уже очень длинный.

Но в двух словах, rebase позволяет вам переписать вашу историю практически любым способом, которым вы можете захотеть. Он берет набор коммитов и повторно применяет копии этих коммитов к любому месту в вашей истории. Вот что делает решение, которое я предложил выше: оно берет вашу старую историю v10 и воссоздает ее поверх новой истории v9, как будто история всегда создавалась таким образом.

Перебазировать ресурсы

Вот отличные ресурсы для получения дополнительной информации о rebase. Помните, что вы всегда можете создать тестовый репозиторий Git, полный .txt файлов или чего угодно, а затем попрактиковаться в ветвлении, перемещении и слиянии с ним:

1. Инструменты Git — история перезаписи.
2. страница руководства git-rebase(1) .
3. Изучите ветвление Git, см. демонстрацию Interactive Rebase.
4. Курс Code School Git Real, урок 6.