Вопрос о слиянии отрасли и передовой практике

Question

Мой вопрос может go понять основы git, но у меня возникло некоторое недопонимание, и я хотел бы получить совет от самых опытных разработчиков git.

Мой сценарий выглядит следующим образом:

Для некоторых проектов у меня есть две ветви preprod и master

preprod: эта ветвь используется для получения локальных разработок от всех разработчиков, когда клиент проверяет эти разработки, я объединить эту ветку preprod с master

master: для производственной среды.

Сценарий:

Я создал новый ветвь для разработки auto-login функция,

1. git checkout preprod
2. git pull
3. git checkout -b auto_login_v1

Я разработал это Я добавил (2 файла), затем слил ветку auto_login_v1 в preprod. * Пока здесь все хорошо.

Теперь я создаю новую ветку для другой функции newsletter,

1. git checkout preprod
2. git pull
3. git checkout -b newsletter_v1

И, как и в первом шаге, я зафиксировал (1 файл), затем подтолкнул и слил ветку newsletter_v1 в preprod.

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

Проблема в том, что объединяя только 2-ю ветку newsletter_v1, которая содержит (в основном 1 файл), я также случайно слил (2 файла) первой ветки auto_login_v1, в то время как я просто хотел вторую ветку newsletter_v1 с (1 файлом).

Почему я получил это (развернуло 3 файла вместо 1)? потому что я слил первую ветку в preprod, а затем вытащил ее?

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

Answer 1

Я следовал коммитам, которые вы описали, и сделал скриншоты из программы под названием SourceTree, чтобы помочь визуализировать ветви.

Надеюсь, вы увидите это однажды вы объединяете ветку в preprod, любая ветка, извлеченная из preprod, обязательно наследует объединенные изменения.

С точки зрения передового опыта, популярная стратегия ветвления называется GitFlow, и она похожа на ту, что вы уже делают. GitFlow определяет определенные c ветви для определенных c целей:

• master: зарезервировано для версий версий
• develop: зарезервировано для объединения ветвей функций (эквивалентно вашему preprod branch)
• release ветки: Перед объединением develop в master вы должны извлечь промежуточную ветку "release". Коммит, с которого вы переходите на develop, не обязательно должен быть главой develop.

Вот углубленная статья о GitFlow, потому что это еще не все: https://docs.microsoft.com/en-us/azure/architecture/framework/devops/gitflow-branch-workflow

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

Один из способов "удалить" Изменения слияния с auto_login_v1 в preprod равны git revert.

Взгляните на Как отменить коммит слияния, уже переданный в удаленную ветвь? или посмотрите на git вернуть документацию

Answer 2

I developped this feature, I commited (2 files), pushed then I merged auto_login_v1 branch into preprod. *Until here everything is good.

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

Так что ... даже если вы включили функции sh непосредственно в разработку (я не согласен с этим рабочим процессом, но, эй! Если вам так нравится, кто я такой, чтобы судить ?), если вас попросят ввести одну функцию в мастер, вы будете не сливаться, превращаться в мастера .... вы не сливать ветвь функций в мастер ... Вы вносите исправления, относящиеся к функции only поверх master.

, так что ... хорошая практика:

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

https://datasift.github.io/gitflow/IntroducingGitFlow.html

Удачи