VS>> И как всё-таки лучше, коммитить в мастер и стягивать в него же, VS>> или стягивать в мастер, а свои изменения делать в своей ветке и VS>> сливать в неё из мастера? Какие плюсы-минусы у обоих подходов?
EG> Я не знаю, какой там workflow в git и вообще git'ом для разработки EG> не пользуюсь, но для меня всегда естественным было отделять мух от EG> котлет: есть "vendor branch", пусть он будет master или отдельная EG> ветка, не суть важно и мы его не трогаем, а только вливаем в него EG> изменения из апстрима; а есть наша собственная ветка, которую мы EG> меняем своими изменениями.
EG> После очередного обновления "vendor branch" ты можешь получить EG> новый "релиз" со своими патчами, приложив накопленные свои изменения EG> к новой "базе", но не изменяя собственно "vendor branch".
Я помню этот workflow ещё со времен, когда исходники FreeBSD были в CVS! Только сейчас предлагается не *свои* изменения прикладывать к "новой базе", а наоборот изменения из мастера (который у нас выступает в роли vendor branch) мержить в свою ветку:
git clone .... git checkout -b mylocal тут чего-то правим git commit -a git checkout master git pull git checkout mнlocal git merge git commit -a -m "merged recent changes from upstream"
EG> Если они всё ещё прикладываются гладко, то и ладушки, EG> а если нет - разрешаешь конфликт и, при желании, можешь создать новую EG> собственную ветку на основе текущего состояния "vendor branch" EG> и разрешенных конфликтов.
И потом все эти ветки расплодятся и перестанешь понимать, что где.
