Вы хотите git-flow. Например описана тут: https://habr.com/ru/post/106912/
Моё мнение- штука не слишком удобная. Лучше использовать gitlab-flow, например вот описание: https://habr.com/ru/company/softmart/blog/316686/



Не стоит. Совсем не стоит. Это запутывает.
Вы хотите что-то сделать. Создаётелокальную ветку на основе DEV, пишите туда коммиты, пушите а потом делаете pull request (github) или merge request (gitlab) - суть почти так же.



Например создать локально, а потом сделать push



Двое меняют одну строку локально- никак.
Двое сделали push веток, создали merge/pull request - никак.
Один из request'ов замержили - второй видит, что есть конфликт- правит его.



https://git-scm.com/download/win
Он даже SSH настраивает (хотя в целом с ssh в винде плохо всё).




Вообще git сейчас используется не так, как задумывался.
Изначально предполагалось, что "главного" сервера нет, есть только некоторый выделенный компьютер, а все обмениваются кодом делая pull-request - предлождение забрать с твоего компьютера код и вмержить его в репозиторий на компьютере "владельца".

Но сейчас все используют сервера для хранения информации - https://github.com/ https://gitlab.com/ https://bitbucket.org/
Первый теперь принадлежит Микрософту и поддерживает сборку кода в том числе для windows (и хорошо поддерживает- и java кучи версий есть, и innosetup и msys2).
Причём на всех есть бесплатные планы, а есть платные на разных вкус (а можно и локально сервер поставить- у гитлаба бесплатно даже).
Без сервера нынче никто не работает, а там настройка прав широкая- кто owner, кто master, и прочее.

Создать pull/merge-request с галочкой "удалить ветку после мержа" и после ревью нажать кнопочку "merge"

Вам надо читать основы git - про pull/push/fetch/merge и прочее.

Я ревью смотрю либо в UI gitlab/github, либо в IDEA. Вот настолько к галочкам привык.



Я вообще mcedit использую

Это github-flow



Дело, собственно, не в упрощении.
Если посмотреть реальные отличия gitlab-glow от gitflow, то аналогом ветки develop - фичивая ветка.
Аналог release - master
Аналог master - v1.0 и прочие ветки конкретных версий.

Я сейчас вот в основном своём проекте работаю по gitflow, а в "побочных" - gitlab-flow и github-flow, так что сравнить могу. Раньше был на основном, где gitlab-flow.
В чём лично мне видится минус gitflow и плюс gitlab-flow?
1. Непонятно как тестировать большую фичу без пересечением с другими фичами.
2. Если надо поправить "позапрошлый" релиз то это сделать проще в gitlab-flow. Там всегда релиз имеет свою ветку.

В чём плюс gitflow?
1. Когда развернуть серверную часть дорого, то наличие 3х веток и не больше- это намного дешевле.
2. Когда клиентских приложений 5 разных - то это позволяет синхронизировать весь это зоопарк.
Собственно эти оба пункта про текущий проект, так что gitflow оправдан.

В чём плюс github-flow? Хорошо на старте разработки, пока все постоянно рефакторинг фигачат - с мержем проблем нет.



Уровень бардака определяется квалификацией участников, а не процессом.
Попытки заменить квалифицированных разработчиков процессами всегда приводит к провалу.

Речь про то, что когда тестирование идёт с общей ветки, то и ногда сложно понять "чей туфля", т.е. чья бага.
Так что первое тестирование лучше делать с "именно" ветки.

Замечательно, когда всё можно выполнить автоматически.
А бывают случаи разные - например нужно проверить взаимодействие с внешним API, которое одно и ставит блокировку на количество одновременных запросов- кроме продакшна можно выделить время на тестирование ровно одного экземпляра сервера и в строго определённое время. И тестировать надо долго- API неспешное, а данных много.
Второй вариант- некоторые вещи приходится тестировать на копии данных клиента, а данных- очень много, тоже надо стоять в очереди :)
Ну и изменения UI требуют ручного просмотра- выявить некрасивость иначе нельзя- значит надо разворачивать нужную версию сервера, брать JSник нужный и смотреть всё.




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




Да, когда большинство файлов бинарные- то надо блокировать их. Или не работать с такими средствами разработки, которые не способны хранить всё в текстовых файлах.

Вот сейчас у нас только файлик лицензионного соглашения (для виндовых/макосевых дистрибутивов) и иконки/картинки всякие в бинарниках- и хорошо, и нет проблем.

Но внутри этой темы.



И что? Перед отправкой не ревью надо всё слить и разбить на логические коммиты.
Некоторые так не делают- ну так уровень у всех разных, не всех можно подпускать к разработке.