Использование Git: «вставка» коммитов до HEAD

Question

Название вопроса может быть бессмысленным, но я пытался.:)

Вот моя ситуация:

У меня есть хранилище с одной веткой (master).(Из этого репозитория, когда я «отправляю» сборки, я добавляю тег к коммиту, который представляет поставленную сборку, чтобы я мог вернуться к нему.)

Если я посмотрим на график коммитов, давайтескажем, это выглядит так:

Start ----------> A --> HEAD

Где "A" - это некоторый коммит в недавнем прошлом, но до HEAD.Я бы хотел "отправить" сборку, в которой не было бы всех изменений, начиная с A. Но я также хотел бы сделать один или два изменения к этой версии дерева перед отправкой.То, что я пытаюсь сделать концептуально, это откат к точке А, зафиксировать пару изменений, а затем, после отправки этого, повторно применить все различия, которые идут от A -> HEAD, что вернет меня в актуальное состояние и включаетпара подправила и меня тоже.

Это то, что я хотел бы сделать концептуально.Я не уверен, как думать о лучшем способе достижения этого с помощью git.Может ли кто-нибудь предложить здесь вдумчивое руководство?

Спасибо!

Answer 1

Вы можете буквально делать то, что просите, с помощью git rebase -i.Зафиксируйте свои новые изменения, затем используйте rebase -i, чтобы переместить их.

Однако, если вы когда-нибудь делились этим деревом с кем-либо, было бы лучше не заменять эти промежуточные версии и вместо этого делать что-то вроде git checkout -b release_A Aа затем внесите свои изменения в этой ветви.Затем вы можете git merge или git cherry-pick вернуть их на ваш мастер.

Answer 2

git checkout -b release_A A; даст вам ветку для игры на основе этого релиза. (Предполагается, что он помечен как release_A - вы также можете использовать sha1sums для ссылки на определенные коммиты).

Взлом и git commit создание новых коммитов.

git tag release_A_2, поэтому у вас есть тег для этого выпуска.

Затем выберите точно одно из следующего:

1. git rebase A master или git checkout master; git rebase A
2. git checkout master; git merge A

В любом случае вы можете дополнительно указать git branch -d A, чтобы устранить ветку, которую вы больше не используете.

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

Вариант 2 на самом деле не изменит историю - все коммиты представляют реальную историю. Вместо этого он будет включать изменения в этой ветке в master. Слияния часто имеют репутацию болезненных, но этот мерзавец должен быть примерно таким же умным, как в случае 1. Если вы пометили или выпустили что-либо с момента release_A, я настоятельно рекомендую использовать этот метод, так как он остается воспроизводимым.