Git ветвление состояния для функциональных ветвей и общего кода - PullRequest
Новая
       27

Git ветвление состояния для функциональных ветвей и общего кода

9 голосов
/ 01 марта 2011

Я использовал описанную здесь стратегию ветвления git http://nvie.com/posts/a-successful-git-branching-model/

До сих пор она работала очень хорошо для меня.

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

a) Изучите основную ветку разработки, зафиксируйте изменения и перебазируйте функциональную ветку от разработки.

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

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

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

1 Ответ

4 голосов
/ 01 марта 2011

Мне нравится опция a /, но реальность такова, что когда вы делаете коммиты после коммитов, вы только понимаете, что некоторые из них на самом деле общий код гораздо позже в процессе.

Когда это происходит в ветке feature (которая обычно еще не передана и не передана), я предпочитаю делать interactive rebase, сначала переупорядочивать коммиты для общего кода, а затем объединять ветку masterв ветку feature для тех n первых коммитов (ускоренное слияние).
Оттуда я могу перебазировать в master любую другую ветвь, которая должна воспользоваться этими новыми общими функциями.

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

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

, тогда я предпочитаю объединить feature ветку позже.

...