Слияние ветки объектов на основе другой ветви функций обратно в мастер

Question

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

Так что я могу создать новую ветвь функций на основе текущей ветки и начать там работу над следующей версией. Проблема в том, что это иногда становится беспорядочным, если вы не помните, что у вас все еще есть другая ветвь функций или что-то еще, что приводит к конфликтам слияния.

Как то так. Таким образом, в этом случае Feature-1 тестируется, но по той или иной причине мы не будем выпускать отсюда, скорее работа над Feature-2 будет продолжена. Тем не менее, обратите внимание, что произошел коммит после создания Feature-2. Итак, поправьте меня, если я ошибаюсь, но один из способов справиться с этим, если на самом деле Feature-1 НЕ собирался быть выпущен, тогда ... если предположить, что голова указана на / Feature2, следующие получат изменения от Feature-1 И потом все обратно в мастера?

git merge Feature-1 
git push origin Feature-2
git checkout master
git merge Feature-2
git push origin master

Answer 1

Если у вас есть одна «ветвь функций» для каждого выпуска, они не являются ветвями функций. (Если только вы не выполняете непрерывную доставку, в этом случае вы просто отпускаете мастер.)

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

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

Если вам часто приходится разветвляться на другие ветви функций, ваши ветви функций делают слишком много.

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

---

Давайте разберемся, как Git делает ветки. В отличие от других систем контроля версий, коммиты подключаются к другим коммитам, а ветви - просто метки. Филиалы не имеют собственной жизни. Ваша ситуация выглядит следующим образом.

                    G - H - I [feature-2]
                   /
          D - E - F - K [feature-1]
         /
A - B - C [master]

Изгибы совершенно условны. Мы также можем посмотреть на это следующим образом.

                    K [feature-1]
                   /
          D - E - F - G - H - I [feature-2]
         /
A - B - C [master]

При таком взгляде должно быть более понятно, что находится в feature-2. Все master, большая часть feature-1 (что не проверено) и все feature-2. feature-2 нельзя сделать до тех пор, пока не будет сделано feature-1, и такая зависимость нежелательна.

---

Если вы работаете над веткой и хотите оставаться в курсе, самый простой что нужно сделать, это git rebase upstream-branch. Это перезапишет ваши коммиты так, как если бы они были написаны поверх upstream-branch все время. Это позволяет избежать множества запутанных условных слияний.

Before
                    G - H - I [feature-2]
                   /
          D - E - F - K [feature-1]
         /
A - B - C [master]

git checkout feature-2
git rebase feature -1

After
                        G1 - H1 - I1 [feature-2]
                       /
          D - E - F - K [feature-1]
         /
A - B - C [master]

feature-2 можно безопасно нажать с помощью git rebase --force-with-lease. Люди могут безопасно обновить свою копию feature-2, если они потянут с помощью rebase, а не слияния. git pull --rebase или установка pull.rebase = merges в вашей конфигурации Git.

Опять же, это должно быть редко .

---

Но, как указано выше, feature-2 вероятно, никогда не должен был быть построен поверх feature-1 вообще. Если бы они были небольшими и независимыми функциями, они бы выглядели следующим образом.

          D - E - F - K [feature-1]
         /
A - B - C [master]
         \
          G - H - I [feature-2]

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

git checkout master
git merge feature-2
git branch -d feature-2

          D - E - F - K [feature-1]
         /
A - B - C ---------- J [master]
         \         /
          G - H - I

Это называется "пузырем функций".

Все остальные затем обновляют свою ветку функций поверх master для обновления, имеет дело с любыми конфликтами или поломками и занимается своими делами.

git checkout master
git pull
git checkout feature-1
git rebase master

                       D1 - E1 - F1 - K1 [feature-1]
                      /
A - B - C ---------- J [master]
         \         /
          G - H - I