Блог

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

Я рассматриваю предложение этого довольно простого рабочего процесса: скажем, у меня есть ветка master (release), ветка development и ответвления темы от нее. Разные разработчики работают над своими отдельными тематическими ветвями, извлекая и перенося эти тематические ветви в центральное репозиторий так часто, как они чувствуют, что у них есть рабочий код. Периодически, по просьбе разработчика, сопровождающий (в нашей организации этот человек носит звание «технический руководитель») выполняет слияние из своей ветви функций в ветку разработки, которая размещается на промежуточном сервере и тестируется, а по завершении тестирования функции она объединяется с master и запускается в производство.

Вот мой вопрос. Должны ли разработчики периодически объединять свои тематические ветви? Это гарантировало бы, что ВСЕ они будут сливаться обратно в dev довольно чисто (или, по крайней мере, устранять конфликты на ранней стадии, прежде чем они смогут выйти из-под контроля). Единственное, что, я знаю, не понравится моему менеджеру в этом, это то, что им приходится выполнять такую работу, чтобы успокоить свой инструмент, а не доставлять код в проект. Мысли?

Мы все знаем, что конфликты будут. На самом деле вопрос в том, кто должен разрешать конфликты?

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

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

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

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

Немного чтения:

http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/

Приветствия