как использовать git branch для фиксации моего кода, не влияя на основной код

Question

Я работал над текущей веткой релиза "base", которая будет выпущена довольно скоро.В последний момент моя функция была удалена, и у меня есть некоторые изменения в базовой ветви.Это большой набор, включающий огромное слияние около 400 коммитов.Так как это толкается, я не могу толкнуть его на базу.Кроме того, я не хочу повторно делать слияние.

Итак, мне было интересно, смогу ли я сделать это:

из дерева, в котором есть объединенные изменения, ответвления от новой ветви, произнесения «post-release» и затем нажмите его нахранилище без смены базы.Является ли это возможным?Я хочу предотвратить случайную фиксацию базы (иногда я видел, как несколько ссылок обновлялись одним нажатием).

Эта диаграмма может помочь визуализировать проблему.

master
------------------------------------------->
    \                           
     \---release1--->            
                     \
                      \--base (releasing soon)------>
                          (I have some changes merged on a local tree 
                           based off "base" but not pushed to base)     

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

В идеале мне следовало начать с создания ветви на основе "базовой" ветви, а затем объединить ее, но я этого не сделал.

Answer 1

Я не уверен, что понимаю ваш вопрос. Из вашей диаграммы давайте попробуем построить несколько новых диаграмм. Видимо, у вас есть в удаленном общем репо:

[master]  * --- [possibly more commits]
           \
[release1]  * --- A --- B --- C
                   \
[base]               D --- E

А в вашем личном репо:

[master]  * --- [possibly more commits]
           \
[release1]  * --- A --- B --- C
                   \
[base]               D --- E
                      \
[devel]                 F --- G --- I --- J
                         \               /
                           --- H --------

так что кончик ветви "devel" - это коммит J, который является слиянием FGI + H, все указывает назад на D (в "базе"), которая указывает на "A" (в релизе 1). Теперь кто-то планирует выпустить "release2", который они сделают, объединив ABC + DE?

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

Или, возможно, вы имеете в виду, что приведенное выше удаленное репо более или менее точно, но у вас нет вашей собственной ветви "devel". Возможно, ваше (локальное) дерево коммитов репо выглядит примерно так:

[master]  * --- [possibly more commits]
           \
[release1]  * --- A --- B --- C
                   \
[base]               D --- E --- F --- G --- I --- J
                                  \               /
                                   --- H ---------

Если вы хотите, чтобы это выглядело так:

[master]  * --- [possibly more commits]
           \
[release1]  * --- A --- B --- C
                   \
[base]               D --- E
                            \
[devel]                      F --- G --- I --- J
                              \               /
                               --- H ---------

тогда вы можете начать с создания ветки "devel", которая зависает от коммита E:

git branch devel E  # use the commit-ID for commit E

и затем повторно указать локальную ветку "base" для фиксации E:

git branch -d base; git branch base E # again you'll want the sha1
# or: git update-ref refs/heads/base E

и все готово (на данный момент, во всяком случае, в конечном итоге вам все равно придется перебазировать вашу ветку "devel").

---

ПРИМЕЧАНИЕ (которое, я думаю, может очень помочь в понимании ветвей): я поместил метки ветвей слева от каждого уровня дерева на своих диаграммах, но на самом деле метки ветвей располагаются "справа" «(как бы на« верхушке »каждой ветви). Когда вы делаете «git commit» на ветке, это добавляет новый коммит, а затем обновляет tip-tip. Я подозреваю, что большинство людей «думают» о ветвях, как будто метки устанавливаются один раз, когда вы выполняете команду «git branch», а затем остаетесь там навсегда - но это не так, как они работают. Метка ветви следует за кончиком ветви. «Горизонтальная часть» ветви, когда вы смотрите на дерево коммитов, если оно нарисовано так, как я их здесь нарисовал, - это то, что вы должны разработать на основе структуры дерева коммитов.

Answer 2

Прежде всего, если все, о чем вы беспокоитесь, это сохранение слияния, то для этого rerere.

Кроме того, что вы хотите сделать: «сохранить» ваши изменения в ветке очень просто.

Просто git branch my_new_branch, затем git reset --hard base (сначала убедитесь, что все изменения рабочей копии зафиксированы! reset --hard удаляет неиндексированные изменения!). Теперь у вас есть две ветви: текущая HEAD находится в (и после) base, а вторая ветвь (my_new_branch) все еще содержит ваши неоттолкнутые изменения и отслеживает base. Вы можете использовать git merge или git rebase столько раз, сколько хотите, чтобы my_new_branch обновлялся по отношению к base до его реинтеграции.