Стратегия Git для тех случаев, когда вам нужно работать над несколькими функциями одновременно

Question

Допустим, я одновременно работаю над несколькими интерфейсными функциями, которые все находятся в разных ветвях (например, login ветвь, reset ветвь паролей, update ветвь настроек и т. Д.).В нашем текущем рабочем процессе мне решать, в каком порядке или каким образом я завершу все эти функции, если я выполняю их в течение установленного срока (например, 2 недели).

Чтобы улучшить темп, ясоздайте ветвь для каждой из этих функций и работайте над ними одновременно, сначала интегрируя функциональные возможности (так сказать, сложные части), а затем работайте над стилями и мельчайшими деталями.(Аналогия похожа на строительство дома; на самом деле вы не завершаете каждую часть дома одну за другой. Сначала вы строите все фундаменты, леса и все, прежде чем делать все декоративные элементы до конца.)

Теперь это нормально, если все эти функции полностью изолированы друг от друга.Тем не менее, есть некоторые функции или даже общие стили, которые я сделал, например, ветка login, которые я могу использовать в ветке reset пароли.(Например, обе формы являются, следовательно, должны иметь одинаковое общее оформление формы и будут использовать одни и те же функции проверки).

Однако, поскольку все они являются WIP все сразу, я не могу сделать PR для login, прежде чем я продолжу работать над reset pw (например, login на 90% и reset pw на 80%, но мне нужно что-то от login, чтобы получить также завершение от reset pw до 90%).Даже если я завершу login, проверки PR могут занять некоторое время.

Я также не могу, например, объединить / перебазировать в login с reset pw, потому что 1. это смешало бы 2 различных функции и 2. *Функция 1023 * еще даже не одобрена.

Какова лучшая стратегия для такого сценария?Я нахожусь в дилемме, потому что лучший способ избежать этого - закончить одну функцию за другой.Но в то же время я работаю лучше, если делаю это так, как я только что упомянул (параллельно).

Answer 1

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

Давай сделаем небольшое упражнение. У вас есть ветка feature1 с 2 коммитами, а затем ваш старт feature2 сверху feature1. Вы разрабатываете пару коммитов поверх feature2. В этот момент вы понимаете, что вам нужно что-то сделать для функции 1:

git checkout feature1
# edit files
git add blah blah
git commit -m "feature 1"

Теперь, как вы включили это в feature2? Достаточно просто:

git checkout feature2
git rebase feature1

Это было просто .... В этот момент вы понимаете, что вам также нужно что-то из feature3 .. функция 3 имеет 10 коммитов, а вам нужна только функция 3 ~ 2. не поместите его поверх feature2, потому что тогда вы путаете вещи в истории. Вы бы:

git checkout HEAD~2 (go back in history 2 revisions... do not use a branch)
git cherry-pick feature3~2 # get the revision you need
# how do we move feature2 onto this?
git rebase --onto HEAD HEAD feature2 # rebase only the last 2 revisions of feature2. No need to rebase any of the revisions up to where you are standing right now

Теперь функция 3 полностью объединена с мастером, и вам предлагается переместить все поверх текущей позиции мастера. Ну ... вы не отвечаете за feature3, так что нет смысла переносить эту редакцию вместе с вами, верно?

git checkout feature1
git rebase master
git rebase --onto feature1 feature2~2 feature2

А функция 3 ушла из истории. На данный момент вы хотите отделить Feature2 от Feature1:

git checkout feature2
git rebase --onto master feature2~2 feature2

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

Answer 2

Это основано на мнении, но я бы работал над всеми этими тремя функциями в одной ветви.например, я должен быть в состоянии login.Это не требует reset pw.Как только функция входа в систему сделана, я нажимаю ее для проверки кода или чего-то еще.После этого я добавляю функцию сброса пароля в качестве другого набора коммитов и отправляю его на рассмотрение.

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

Answer 3

С моей точки зрения (и опыта), в таком сценарии выгодно объединить частичные функции в мастер. Вы должны быть в состоянии извлечь общие части, например, для сброс логина / пароля, создать для него отдельную ветку, создать пиар, объединить и двигаться дальше. По сути, вы ветвитесь на строительный блок, а не на функцию.

Если он блокирует вас, бесполезно цепляться за навязанные им ограничения, такие как «функция может быть объединена с веткой master / develodp / Integration только тогда, когда она полностью завершена». Пребывание там и откладывание PR приводит к адскому слиянию и бесконечным комментариям.

Answer 4

Сделайте вашу работу по разработке тем, что лучше всего подходит для вашей разработки, затем используйте git rebase -i s (или для более масштабной реструктуризации git reset и git add -p / git commit перестройки), чтобы создать коммиты, которые вы сделали бы в первомместо, если вы знали точно, что было лучше всего.

Никто не должен видеть ваши первые проекты ... кроме вас.Никто не должен работать с ними ... кроме вас.У вас под рукой VCS мирового класса, почему не использует Git, чтобы помочь с первым проектом?Используй это.Затем используйте Git для подготовки того, что вы сделали для публикации.