как пользоваться гитом?

Пользуюсь и не знаю, что есть какие-то flow, которым обязательно нужно следовать.

P.S. В своих проектах, разумеется, ни с кем патчами по почте не обмениваюсь.

Как договоритесь в команде. Есть несколько простых базовых правил, типа новая фича в отдельной ветке, разделение master/develop веток и пр., остальное на усмотрение.

есть еще?

Бесконечное количество. Перечисленное - это просто формализации паттернов работы с ветками и релизами, а ты можешь с ними работать абсолютно любым образом как тебе удобно и про эти flow’ы знать не ведать. По умолчанию живёшь с линейной историей в master, потом по вкусу добавляешь feature веток, а к flow можешь обратиться только когда понадобился разделение стабильной/devel веток или релизные ветки. При современном и правильном подходе к разработке первое никогда не понадобился, а второе удобнее делать cherry-picking’ом.

разделение master/develop веток и пр

а зачем их делить? :)

чем плохо иметь теги в мастере?

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

develop - это твоя разработка, сюда попадают новые фичи, которые еще только ждут тестирования, могут быть вообще недоделаны и откровенно не работать. Когда все новые фичи доделаны, протестированы и QA сказал, что всё ОК, develop сливается в master.

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

Два чая этому хиппи :-)

https://trunkbaseddevelopment.com/

чем плохо иметь теги в мастере?

Представь, что у тебя CI/CD который автоматом деплоит master в продакшен, а develop на бету.

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

Разработчики разного рода *BSD с тобой категорически не согласны

Разработчики разного рода *BSD с тобой категорически не согласны

Они с svn хоть слезли уже или так и продолжают жрать кактус?

Они с svn хоть слезли уже или так и продолжают жрать кактус?

Некоторые еще на svn и не залазили %)

https://cvsweb.openbsd.org/

автоматом деплоит master в продакшен

тег мастера деплоит в прод, да. как жить без тегов?

На гите. Pull, push, commit, вот это все, без смузей

Затем, что мастер - это релиз, туда идут только фиксы багов.

В сферическом вакууме это так, в реальности в большинстве случаев забивают на master и использует develop как master. При этом если кому-то об этом скажешь вслух - придумавший это лезет в бычку, типа master нужен - он стабильный. Ага. Делаешь git clone - получаешь ветку по умолчанию (master) в которой ничего нет (код либо с начала проекта, либо 2-х летней давности), потому что все используют только develop и feature ветки, про master забыли и при этом рассказывают, что это у них gitflow (даже не рядом, потому что gitflow - это четко описанная стратегия git workflow, однако, в большинстве случаев используют нечно похожее на gitflow, адаптированное для своего проекта, только это не gitflow).

Довольно действенный метод, кстати, чтобы распознать техлида упертого мудака и раздолбайский подход к организации разработки. В нормальной команде в master действительно будет стабильный код (более стабильный, чем в develop). В develop, кстати, тоже будет работающий код, потому что вся разработка ведется в feature ветках. Однако, develop ветка может быть хуже протестирована.

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

Согласно gitflow (https://datasift.github.io/gitflow/IntroducingGitFlow.html) master почти не нужен, в него идут только теги из release ветки и развертывание при появлении тега (если release ветка одна, т.е. нет деления на несколько поддерживаемых веток v1.x.x, v2.x.x, например, если у тебя корпоративное приложение, которое ты тут же внедряешь и не делишь на ветки). Если же есть деление (библиотека с несколькими поддерживаемыми мажорными версиями), то master вообще не нужен (не получится туда пихать теги из разных веток).

develop - используется для разработки, от него делают feature ветки. А так как стратегия разделения софта на нестабильный и стабильный используется только адептами *BSD, то в ветке develop будет код, который собирается и работает (вся разработка ведется в feature ветке и вливается в develop, когда фича готова).

Таков gitflow (один из возможных вариантов git workflow). Однако, могут быть и другие (как вариации gitflow, так и разделение на неработающий develop и, таки, доведенный до работоспособного состояния master, ну, и другие варианты). В общем, нет единой стратегии работы с git, каждый кулик хвалит свое болото (и зачем-то называет свой подход gitflow).

В сферическом вакууме это так, в реальности в большинстве случаев забивают на master и использует develop как master. При этом если кому-то об этом скажешь вслух - придумавший это лезет в бычку, типа master нужен - он стабильный

Это зависит от принятого в конторе workflow, все может быть автоматизированно, допустим в конторе где я работал в master был код который публиковался на prodction (сервисы для конечных потребителей), не поместив код в master нельзя было опубликовать новую версию, скрипты были заточены на взятие кода с master ветки. Помимо продакшена был еще preprod, где тестировал фичи бизнес (продукт овнеры) и был девелопмент где девелоперы тестировали применения изменений и вообще работу с полной интеграцией со всей инфраструктурой.

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

кто на чем сидит?

В основном все сидят на бухле. Некоторые сидят на кислоте.

А если серьёзно, часто забивают, так что чаще его нет.

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

как пользоваться гитом?

Rastafarra

Что в последнее время с пользователями ЛОРа?

man gitworkflows

На примере гентушного зеркала и отправки туда пул-реквестов для ebuild'ов (обновлений существующих или совсем новых пакетов: коммиты должны быть атомарными (одна фича - один коммит); после каждого внесённого изменения или добавления патча ebuild должен оставаться полностью рабочим, т.е. удаление любого коммита для ebuild'а из пул-реквеста не должно ломать сборку пакета.

чем плохо иметь теги в мастере?

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

master - тут девелопишь фича бранчами

v1.x - ветка для версии v1.x (создаётся из мастера в момент T1*), тут фиксишь баги для версии v1.x багфикс бранчами

v2.x - ветка для версии v2.x (создаётся из мастера в момент T2*), тут фиксишь баги для версии v2.x багфикс бранчами

и так далее

* - момент наступает, когда ты хочешь перестать писать фичи и хочешь только исправлять баги

если у тебя веб приложение и актуальна только одна версия, хватит одного мастера с фича/багфикс бранчами

Лично я пользуюсь консольным. Но меня долго склоняли к воровству смартгита. Я считаю что это ложный путь...

Мастер должен быть всегда в работоспособном состоянии (ну по крайней мере должен собираться и деплоиться).

Слушайте я не знаю. Я вот столкнулся с «А у нас НИКТО из мастера не собирает ничего». Может вы и я больные? Лично я после этой фразы неделю был в шоке...

Я работал в разных командах, где был разный подход к организации гита. Где-то есть мастер, develop и пр., а кое-где было так:

release/1.0 - текущий прод;
release/1.1 - тестируемая ветка;
release/1.2 - разработка;  

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

Да. Я тоже за такой подход. Мастер у нас это текущий релиз который может быть и не всегда рабочим (но нерабочим он быть не может постоянно). А есть бранчи релиз 1 релиз 2. А если есть еще и заказчики разные, то веток будет больше.

Но МАСТЕР не может быть нерабочим 99% времени. А я наблюдал когда он не мог быть рабочим. Мне чисто психологически видеть такое тяжко.

Есть еще интересный спор с Большими репозиториями и с микро репозиториями. У вас есть фронт на JS у вас есть бэк на Го или на PHP не важно. А может и три или 4 бэка. А может у вас 5 библиотек на JS для Фронта.

Ну смотрите. Вы ведь используете npm да? Реакт у вас весь в вашей репе? Нет. Скорее всего.

В итоге для сборки вы получаете pip install 1000 раз и npm. Так какого черта не держать это все в разных репах? Есть билд репа которая дернет определенные репы для сборки и получаем релиз.

Ну и потом начинается цирк с черрипиком и сквошами...