Как создать ветку из определенного коммита в другой ветке

Я сделал несколько коммитов в основной ветке, а затем объединил их в ветвь dev.

Я хочу создать ветку из определенной фиксации в ветки dev, которая была сначала передана в главной ветке.

Я использовал команды:

git checkout dev
git branch  <branch name> <commit id>

Однако это создает ветку из главной ветки, а не ветвь dev, которую я ожидал. Идентификатор фиксации совпадает с идентификатором ведущей ветки и ветки dev. Итак, как я могу различать один и тот же идентификатор фиксации в другой ветке?

PS: Я сделал пример в github здесь https://github.com/RolandXu/test_for_branch

Я использовал команды:

git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8

Я ожидаю, что тестовая ветвь содержит файл aa.txt bb.txt cc.txt. Однако тестовая ветвь содержит только aa.txt и cc.txt. Скорее всего, она создала ветвь из ведущей ветки.

Ответ 1

Если вы используете эту форму команды branch (с начальной точкой), не имеет значения, где находится ваш HEAD.

Что вы делаете:

git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8

Сначала вы установите HEAD в ветку dev,
Во-вторых, вы начинаете новую ветку на commit 07aeec98. В этом коммите нет bb.txt(в соответствии с вашим реестром github).

Если вы хотите запустить новую ветвь в том месте, которое вы только что проверили, вы можете запустить ветвь без начальной точки:

git branch test

или как другие ответили, ответьте и проверите там одну операцию:

git checkout -b test

Я думаю, что вас может смутить тот факт, что 07aeec98 является частью ветки dev. Верно, что это коммит является предком dev, его изменения необходимы для достижения последней фиксации в dev. Тем не менее, они представляют собой другие фиксации, необходимые для достижения последнего dev, и это не обязательно в истории 07aeec98.

8480e8ae (где вы добавили bb.txt), например, не в истории 07aeec98. Если вы отделитесь от 07aeec98, вы не получите изменений, внесенных в 8480e8ae.

Другими словами: если вы объединяете ветвь A и ветвь B в ветвь C, тогда создайте новую ветку при фиксации A, вы не получите изменений, введенных в B.

То же самое, у вас было два параллельных ветки master и dev, которые вы объединили в dev. Ветвление из фиксации мастера (старше слияния) не даст вам изменений dev.

Если вы хотите постоянно интегрировать новые изменения с мастером в свои ветки функций, вы должны объединить master в них и продолжить. Тем не менее, это приведет к фиксации слияния в ваших ветвях функций.

Если вы не опубликовали свои ветки функций, вы также можете переустановить их на обновленном хозяине: git rebase master featureA. Будьте готовы решить возможные конфликты.

Если вам нужен рабочий процесс, где вы можете работать с ветвями функций без коммитов, и все еще интегрироваться с новыми изменениями в master, я рекомендую следующее:

основывайте каждую ветвь новой функции на фиксации master
создать ветвь dev при фиксации master
когда вам нужно посмотреть, как ваша ветка функций интегрируется с новыми изменениями в master, объедините как master, так и ветвь функции в dev.

Не вступайте в dev напрямую, используйте его только для слияния других ветвей.

Например, если вы работаете с функциями A и B:

a---b---c---d---e---f---g -master
    \       \
     \       \-x -featureB
      \
       \-j---k -featureA

Объединить ветки в ветвь dev, чтобы проверить, хорошо ли они работают с новым мастером:

a---b---c---d---e---f---g -master
    \       \            \
     \       \            \--x'---k' -dev
      \       \             /    /   
       \       \-x----------    /    -featureB
        \                      /
         \-j---k--------------- -featureA

Вы можете продолжить работу с вашими ветвями функций и регулярно слияния в новых изменениях от главных и функциональных ветвей до dev.

a---b---c---d---e---f---g---h---i----- -master
    \       \            \            \
     \       \            \--x'---k'---i'---l' -dev
      \       \             /    /         /
       \       \-x----------    /         /  -featureB
        \                      /         /  
         \-j---k-----------------l------ -featureA

Когда пришло время интегрировать новые функции, объедините ветки признаков (не dev!) в master.

Ответ 2

У вас есть аргументы в неправильном порядке:

git branch <branch-name> <commit>

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

Если вы хотите проверить новую ветку при ее создании:

git checkout -b <branch> <commit>

с тем же поведением, если вы опустите аргумент commit.

Ответ 3

Вам нужно сделать:

git branch <branch_name> <commit>

(вы меняли имя ветки и фиксировали ее)

Или вы можете сделать:

git checkout -b <branch_name> <commit>

Если вместо вас используется имя ветки, вы получаете ветку из кончика ветки.

Ответ 4

Try

git checkout <commit hash>
git checkout -b new_branch

Фиксирование должно существовать только один раз в вашем дереве, а не в двух отдельных ветвях.

Это позволяет вам проверить, что конкретное коммит и назвать его, что вы будете.

Ответ 5

Вы можете сделать это локально, как все упоминали, используя

git checkout -b <branch-name> <sha1-of-commit>

Кроме того, вы можете сделать это в самом github, следуя инструкциям:

1- В хранилище, нажмите на Commits.

2- на коммите, с которого вы хотите разветкиться, нажмите <> чтобы просмотреть репозиторий на этом этапе истории.

3- Нажмите на tree: xxxxxx в левом верхнем углу. Просто введите имя новой ветки и нажмите " Create branch xxx как показано ниже.

Теперь вы можете получить изменения из этой ветки локально и продолжить оттуда.