Git-стратегия слияния / перебазирования для однопользовательской разработки

Question

Git-стратегия слияния / перебазирования для однопользовательской разработки

Я использую Git для проекта C ++, и я единственный разработчик. В дополнение к ведению истории кода я использую git, потому что я хочу иметь возможность тестировать новую функцию без изменения исходного кода, пока я не буду готов включить новую функцию в исходный код. Я использую Github, но я единственный разработчик.

Итак, вот как я представляю свою историю коммитов (стрелки обозначают дочерние коммиты, а стрелки между ветвями подразумеваются):

         A1 ---> A2 ---> A3        B1 ---> B2
/                \        /        \
X1 ---> X2  ----------->  X3 ---> X4 -----> X5 ---> (...)

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

В этом контексте у меня есть два связанных вопроса. Я считаю целесообразным объединить оба вопроса в один пост SO.

(1) Имеет ли смысл создавать только 1 ветку «новая функция» (например, тестирование) для запуска вместе с мастером, который будет использоваться для разработки обоих A а также B (и последующие новые функции)? (Если так, как бы я управлял этим процессом переключения между мастером и тестированием, слиянием или перебазированием тестирования обратно в мастер, а затем снова переключением на тестирование для работы над другой новой функцией?)

(2) Учитывая, что я единственный разработчик, имеет ли смысл объединять или перебазировать при добавлении новой функции в мастер? Я новичок в Git, поэтому, пожалуйста, объясните, почему. Если ответ «это зависит», пожалуйста, объясните, как выбрать между ними.

1

branching-and-merging c++git git-merge git-rebase

Решение

Другие решения

Сделайте новые ветви для каждой функции. В Git ветки чрезвычайно дешевы (буквально просто записывают 41 байт в файл) и ими легко управлять.
Это зависит, но не так, как вы думаете. В любом случае, вы получите один и тот же код. Вопрос в том, как вы хотите, чтобы график вашей истории выглядел. Перебазирование все время приводит к линейной истории; об этом легко рассуждать. Ветвление с фиксацией слияния сохраняет информацию о том, когда именно вы начали функцию и когда вы слили ее относительно других ветвей. Иногда эта информация полезна, иногда это просто шум. Чтобы сделать вещи более запутанными, по умолчанию git merge только иногда создает коммиты слияния (если возможно, выполняется слияние в ускоренном режиме).

Если вам нужен график истории, который выглядит как ваш график выше, вам нужно сделать оба:
```
git checkout feature/foo
git rebase master
git checkout master
git merge --no-ff feature/foo
```
Единственный конкретный совет, который я имею здесь, заключается в том, что вы не должны переписывать (перебазировать) историю, которой вы поделились с другими.

3

Источник

Accepted Answer

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

Итак, вот некоторые предположения из этой ссылки:

Мастер всегда на 100 процентов стабилен всегда.

Мастер получает слияние от разработки, когда развитие стабильно и завершено.

Для каждой функции вы делаете ветку из Develop.

Когда функция стабильна, вы объединяете ветвь функции для разработки.

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

Затем вернитесь к мастеру, когда все будет на 100 процентов.

1:
Учитывая, что «особенности» A и B значительно перекрываются или сильно зависят друг от друга, может быть целесообразным развивать оба в одной и той же ветви.
Если это не так, и у вас возникают проблемы в тесте разработки, вы можете отключить функции во время отладки в качестве метода диагностики. Это ваш вызов.
Однако вам может потребоваться объединить разработку с вашими ветвями функций, если это будет продвигаться дальше, чем вы думаете, главным образом потому, что другие люди будут совершать вещи, которые могут конфликтовать с вашей текущей веткой, если вы пригласите кого-то еще в нее.

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

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

2:
Мы не можем использовать rebase в указанном вами контексте, так как мы делимся своими ветками с другими людьми. Я бы сказал, просто используйте слияние, так что если вы действительно привели кого-то еще в микс, и вуаля, никаких проблем.
Также это:

http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

Я надеюсь, что это полезно.

2