Вопрос по merge, branch, git – Какой способ слиться с git?

5

Скажем, у меня есть две ветви

master -- A -   -   -   -   -  - merge
          \                    /
           \- develop -- B -- C

Теперь, если я хочу слиться, это будет ускоренная перемотка вперед, но я должен сделать

git checkout develop
git merge master

или же

git checkout master
git merge develop

А что если у меня возникнут возможные конфликты

master -- A - D -  -  -  -  -  -merge
          \                   /
           \- develop -- B -- C

Должен ли я теперь слиться в развиваться или в мастера? Это немного сбивает с толку, поэтому хорошее объяснение будет очень полезно

Вы пытаетесь сделать что-то, что основано наthis branching model? R0MANARMY
Если вы пытаетесь следовать этой модели, у вас никогда не должно быть ситуации, подобной той, которую вы описали, где находится коммит Dmaster но не вdevelop, Вся ваша работа будет идти вdevelop и исправления будут объединены в обаmaster а такжеdevelop. R0MANARMY
Да, я так думаю, по крайней мере: P Новое в git и контроль версий, вы видите chwi

Ваш Ответ

2   ответа
3

сделать второе, слить в то время как в мастере.

Я обычно перебазирую master в origin, перебазирую dev в master,then слияния. Это заставляет конфликты появляться во время перебазирования; если вы сделаете это, не будет конфликтов слияния.

Ага, большое спасибо chwi
На gitimmersion я читал, что перебазирование не было хорошей практикой при работе с публичными репозиториями, потому что это может сбить с толку других пользователей Я избегаю этого, используя вашу рутину? chwi
rebase - локальная операция, я не уверен, как это сбивает с толку ...
правильно, нормально перебазировать вашу ветку dev, вы бы никогда не перебазировали вашу ветку master
gitimmersion.com/lab_34.html : Не используйте rebase & # x2026; Если ветка общедоступна и доступна другим. Переписывание общедоступных веток приведет к провалу других членов команды. Когда важна точная история ветви фиксации (так как rebase переписывает историю фиксации). Учитывая вышеприведенные рекомендации, я склонен использовать rebase для кратковременных локальных веток и слияния для веток в публичном хранилище. chwi
6

Missing Workflow Tasks

Прежде всего, в вашем рабочем процессе отсутствуют некоторые вещи, которые затрудняют реалистичный ответ на ваш вопрос. Например:

  1. You should always pull from upstream before merging branches. Others may have changed develop or master in ways that you haven't accounted for.

  2. You haven't identified which is your long-lived line of development. One assumes develop, but that's just a guess because you haven't identified what happens to your branches after the merge.

General Best Practices for Rebasing Long-Lived Branches

Итак, при условии, что вы обновили свои ветки заранее, и чтоmaster а такжеdevelop оба долгоживущие ветви и чтоmaster является "официальным" переходите к завершенному коду, тогда вы должны что-то сделать в этом направлении.

  1. Make a temporary rebasing branch based on develop.

    git checkout -b tmp develop
    
  2. Rebase your work onto master to ensure a clean fast-forward merge. I like to make this an interactive rebase, but do it any way you want. For example:

    git rebase -i master
    
  3. Merge onto master. I prefer to force the merge to be a fast-forward, but you can do whatever suits you.

    git checkout master
    git merge --ff-only tmp
    
  4. Make sure the merged branch pushes cleanly.

    git push origin
    
  5. If all went well, dispose of your temporary branch.

    git branch -d tmp
    
  6. Re-merge master with develop as a merge commit, rather than a fast-forward. This brings your development into line with the master branch for continued work.

    git checkout develop
    git merge master
    git push origin
    

Natural Consequences

Это гарантирует, что история на вашемmaster ветвь относительно линейна и свободна от конфликтов слияния, и все же позволяет перебазировать при необходимости, не испортив опубликованные ветки. Это все положительные вещи.

Однако этот процесс может оставитьdevelop со сложной историей слияния с момента повторного слиянияmaster вdevelop не всегда может быть ускоренным слиянием. Это не является проблемой, по сути, это просто естественное следствие любого рабочего процесса, который включает в себя перебазирование. Это то, о чем нужно знать, но, на мой взгляд, это цена, которую стоит заплатить за гибкость, которую она предлагает команде.

Отличный ответ! Спасибо chwi

Похожие вопросы