Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 9736 из 10753 ===================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           25 May 20 00:11:45
Кому : Victor Sudakov                                      25 May 20 00:11:45
Тема : Re: git workflow
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+5bee7e81
На   : area://RU.UNIX.BSD?msgid=2:5005/49+5eca3b1e
= Кодировка сообщения определена как: IBM866 =================================
==============================================================================
24 мая 2020, воскресенье, в 16:08 NOVT, Victor Sudakov написал(а):

VS>>> И как всё-таки лучше, коммитить в мастер и стягивать в него же,
VS>>> или стягивать в мастер, а свои изменения делать в своей ветке и
VS>>> сливать в неё из мастера? Какие плюсы-минусы у обоих подходов?
EG>> Я не знаю, какой там workflow в git и вообще git'ом для разработки
EG>> не пользуюсь, но для меня всегда естественным было отделять мух от
EG>> котлет: есть "vendor branch", пусть он будет master или отдельная
EG>> ветка, не суть важно и мы его не трогаем, а только вливаем в него
EG>> изменения из апстрима; а есть наша собственная ветка, которую мы
EG>> меняем своими изменениями.
EG>> После очередного обновления "vendor branch" ты можешь получить
EG>> новый "релиз" со своими патчами, приложив накопленные свои изменения
EG>> к новой "базе", но не изменяя собственно "vendor branch".
VS> Я помню этот workflow ещё со времен, когда исходники FreeBSD были в CVS! Только
VS> сейчас предлагается не *свои* изменения прикладывать к "новой базе", а наоборот
VS> изменения из мастера (который у нас выступает в роли vendor branch) мержить в
VS> свою ветку:

То есть, смешивать мух с котлетами. Ради чего? Hиоткуда не следует,
что новый апстримовский код смержится с твоей веткой, но он он
точно вольётся в нетронутый vendor branch.

EG>> Если они всё ещё прикладываются гладко, то и ладушки,
EG>> а если нет - разрешаешь конфликт и, при желании, можешь создать новую
EG>> собственную ветку на основе текущего состояния "vendor branch"
EG>> и разрешенных конфликтов.

VS> И потом все эти ветки расплодятся и перестанешь понимать, что где.

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

А если кто-то не в состоянии разобраться со своими собственными
ветками, то может быть, ему не стоит вообще заниматься этим всем.
Профессий много.

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.092951 секунды