Есть ли какие-либо недостатки с этой моделью ветвления Git?

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

(Вам не нужно отвечать на каждый вопрос, все, что вы можете, полезно)

1. Используете ли вы этот или аналогичный рабочий процесс git ветвления?

2. Считаете ли вы это продуктивным подходом?

3. Видите ли вы недостатки в этом подходе? Есть потенциальные недостатки?

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

По большей части это обычный рабочий процесс, используемый с любой VCS, которую мы использовали до сих пор. С некоторыми (CVS, SVN) это сложнее, с GIT это тривиально. Тем не менее, у меня есть два замечания:

Во-первых, есть две школы мысли, когда дело доходит до тематических ветвей:

1. Объединить их
2. Перебазировать их

(1) это то, что статья, кажется, предлагает. Проблема коммитов слияния - это так называемые злые слияния . В частности, те, которые присоединяются к путям разработки, где функция изменила семантику в одной из ветвей, но автоматическое объединение не может исправить все вхождения в коде, поступающем из другой ветви. Введенные таким образом регрессии, как известно, трудно отлаживать. Как пользователь GIT, вы, как правило, можете быть более расслаблены в отношении регрессий, потому что вам нужно git bisectавтоматически находить их причины. Однако в описанной ситуации git bisectукажет коммит слияния, который вам совсем не поможет.

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

Лично я твердо нахожусь в лагере (2), потому что я ценю достоверность git bisectрезультатов больше, чем потенциальную потерю покрытия тестами, что легко компенсируется использованием надлежащей системы CI.

Во-вторых, я решил, что продвижение между разработчиками редко бывает хорошей идеей. Существуют проблемы безопасности, связанные с тем, что каждый может зайти в ваш ящик с ssh за загрузкой или запустить git-deamon локально, и, что более важно, в командах, которые не очень малы, упущение может быть довольно быстро потеряно.

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

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

В основном это две основные ветви: masterновые функции и toolkit-conversionфилиал. Самое важное правило простое: делайте в toolkit-conversionветке только те вещи, которые имеют отношение к конверсии. Всякий раз, когда есть что-то, что может быть сделано в master(старый инструментарий GUI), я делаю это там и перебрасываю свои toolkit-conversionизменения в новую masterголову. Другое правило - держать toolkit-conversionветку довольно короткой. Поэтому я часто использую reset, cherry-pick и modify-commit и rebase, чтобы склеить принадлежащие меньшие коммиты к более крупным (которые в конце имеют ту же цель). Это также хорошо работает, когда я попробовал что-то, что не сработало, чтобы «отменить» изменение, или после того, как я переделал код с временным вспомогательным кодом.

Я решил против слияния изменений из masterв toolkit-conversionотрасль, потому что это будет сделать намного сложнее перебазироваться ранее фиксации держать ветку в чистоте и легко обзор. Кроме того, слияния могут привести к конфликтам, разрешение которых не так ясно, как при ведении чистой истории.

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

В конце моя toolkit-conversionветка остается короткой, чистой и легкой для проверки. Я не мог предположить, что делал это подобное мощно с, например, SVN.

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

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

Кроме того, это оказалось заслуживающим доверия :).

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

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

Разработчики kohana также используют этот рабочий процесс, и им, похоже, он очень нравится.

Используете ли вы этот или аналогичный рабочий процесс git ветвления?

Мы используем аналогичный рабочий процесс на работе, но чуть менее сложный. Однако этот рабочий процесс очень вдохновляет меня, так как я читал эту статью много раз. У меня даже есть PDF-файл модели разветвления рядом с моим столом :)

Считаете ли вы это продуктивным подходом?

Продуктивное. Как вы определяете производительность? Ну, на мой взгляд, очень важно иметь высокое качество, по крайней мере, постоянно пытаться достичь лучшего качества. Постоянное улучшение процесса и т. Д. Если вы можете создавать качественный код, от этого выиграет производительность. Таким образом, вопрос на самом деле: улучшает ли это качество программного обеспечения? И мой ответ на это определенно да.

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

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

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

Видите ли вы недостатки в этом подходе? Есть потенциальные недостатки?

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

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

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

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

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

Самый важный момент - начать работать с git, а все остальное будет следовать естественным образом. Начните с простого и постепенно улучшайте! Будь креативным!

ура