Как успешно синхронизировать ветви master и development? МЕРЗАВЕЦ

Мне нравится делать разработку на моей ветке разработки, а затем сливаться в master, когда я готов нажать на производство. Пока я ничего не поручаю главной ветви, все идет гладко.

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

Я слышал, что перебазирование обычно плохо, особенно для вещей, которые вы выталкиваете публично.

есть ли лучший способ управлять этим типом настройки?

6
branch git merge

5 ответов

Я бы сделал это наоборот:

  1. слияние master to dev
  2. merge dev освоить сразу после этого

разрешение всех конфликтов при слиянии.

хотя git превосходен, когда дело доходит до слияния и обработки ветвей, я не думаю, что есть быстрый способ решения конфликтов, кроме ручной, утомительной работы с использованием инструментов 3-way diff/merge.

кроме того, это помогает сделать то, что @cHao сказал в своем ответе ниже-слияние часто, слияние маленькое, и у вас едва ли будут большие конфликтные ситуации слияния.

2

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

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

5

Я думаю, что у вас может быть несколько неправильных представлений, которые влияют на вас больше, чем что-либо технически неправильное.

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

Если вы обнаружите, что что-то не может быть чисто объединено с мастером, вы не должны пытаться исправить проблему на самом мастере. Вместо этого, вы должны устранить проблему в отдельную ветку. Как только вы исправили проблему, вы можете полностью слиться с мастером.

Что касается rebase, то совершенно нормально использовать rebase, пока вы не нажмете на удаленный репозиторий. Как только вы подтолкнули что-то к удаленному РЕПО, вы не хотите перебазироваться, так как тогда вы испортите историю для кого-то другого, и git не может действительно решить это для вас. Поэтому не бойтесь rebase, просто знайте, когда его использовать, а когда нет.

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

есть много учебники доступны для git там, и у них будут некоторые хорошие примеры кода, чтобы помочь тоже. Вот один из самых "классических", я считаю, что рабочий процесс, описанный здесь, работает хорошо. http://nvie.com/posts/a-successful-git-branching-model/

обратите внимание, что я не одобряю набор сценариев bash с именем "git flow", который пытается полуавтоматизировать рабочий процесс (эти сценарии не очень хорошо работали для нас, когда мы их пробовали), но сам рабочий процесс описан там хорошо работать.

5

из того, что я могу сказать, развитие-это то, где происходит все новое. Итак, если это так, ветвь разработки (ветвь функции). работайте над этой веткой. когда вы закончите, просто объедините разработку в свою ветку функций, чтобы убедиться, что она обновлена. затем проверьте ветвь разработки и объедините в нее ветвь функции. поскольку люди в вашей команде продолжают добавлять функции в ветку разработки, в какой-то момент менеджер будет похож на okay, we're releasing, поэтому в этот момент вы объедините master в разработайте (просто incase кто-то сделал rogue commit на master), а затем checkout master и объединитесь в него.

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

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

0

Я

git checkout master
git reset --hard dev

таким образом, мастер становится точно dev. Просто не забудьте перебазировать dev, если вы хотите отправить исправление на master.

0