Я сделал набор, соглашается на ведущее устройство и реализованный после того, что они должны были быть в ответвлении.
Я посмотрел на различные вещи о перебазировании и слиянии и сбросе ведущего устройства. Но никакие попытки управления не привели к истории, которая похожа на то, что я пытаюсь сделать.
Мои попытки приводят меня полагать, что требуется некоторая комбинация rebase --onto
и reset --hard
положить обратно ведущее устройство вовремя. Но мое понимание ветвления Мерзавца оставляет желать лучшего. Часть выполнения этого должна изучить, как я могу использовать его.
Должен быть отмечен ни одно из изменений, которые я пытаюсь переместить, были выставлены.
Текущий
* remote/trunk
--o--a--b--c--d--e--f <- master
|
o <- remote branch foo
Желаемый результат
* remote/trunk
--o <- master
|
o--a--b--c--d--e--f <- remote branch foo
Я не уверен, что переименование ветвей является правильным решением, поскольку это приведет вас с:
* remote/trunk
--M--a--b--c--d--e--f <- master
|
F <- remote branch foo
к:
--F <- master
|
M--a--b--c--d--e--f <- remote branch foo
* remote/trunk
(при условии, что вы переименуете remote / foo
, что не рекомендуется: сначала вы должны отслеживать его, а затем переименовывать, но даже если конечный результат отличается от того, что вам нужно)
, что не является желаемым «желаемым результатом» (foo должен начинаться с F, а не M):
* remote/trunk
--M <- master
|
F--a--b--c--d--e--f <- remote branch foo
Вы можете добиться этого только с помощью rebase --onto
git checkout --track -b origin/foo # create a local branch named after the remote one
git branch tmp # mark current foo HEAD to 'F'
git branch -f foo master # put foo where it should b: at 'f'
git branch -f master tmp^ # reset master to M, parent of tmp
git checkout tmp # go to where we must replay the commits
git rebase --onto tmp master foo # replay a to f on top of tmp
git svn dcommit # push the local foo in order to update remote/foo
, что даст вам:
* remote/trunk
--M <- master
|
F--a'--b'--c'--d'--e'--f' <- local foo and remote branch foo
Вариант ответа Мартина, который не обязательно будет применим к вашей ситуации, но я все равно хочу опубликовать его :)
Предположим, вы забыли создать ветка в commit o
, так что у вас есть:
x--y--z--o--a--b--c--d--e--f master
|
+
[forgot to make a branch here]
И затем вы поняли, что на самом деле вам нужно:
x--y--z--o master
|
+--a--b--c--d--e--f topic
В этом случае вы можете создать ветку в o
, используя его хэш:
git branch topic # creates new branch 'topic' - will be at commit `f`
git checkout o -b newmaster # creates new branch called newmaster pointing on commit `o` (please replace `o` with the actual hash)
git branch -M newmaster master # force rename newmaster to master (means master points on hash `o`)
Вы будете в главной ветке (commit o
), поэтому в качестве последнего шага вы можете:
git checkout topic
Хеш, конечно, может состоять только из первых 5 символов ..
Не имеет большого значения то, что вы используете git-svn
, что действительно важно, так это то, что вы не опубликовали свою основную ветку в какой-либо момент после o
Ветвь в git на самом деле не что иное, как указатель на фиксацию. Вот почему ветвление так дешево: вы просто создаете указатель, и у вас есть ветка.
Я не знаю, как отслеживать удаленные ветки, возможно, вам придется настроить это после переименования / перемещения ваших веток.