Опять начал работать не в той ветке?

Question

[denzago]

Дано:
ветка master
ветка develop
все изменения должны проходить через develop и потом сливаться с master

Задача:
1. Как организовать себя перед началом работы всегда проверять текущую ветку?
2. Почему частенько вносишь правки, а потом понимаешь, что это master ветка, а не develop?

PS
master диплоится на продакшен сервер
develop в тестовую песочницу - смотрится и утверждается клиентом

Comments

[dollar]

То есть вы всё время путаете две разные папки на своём компьютере?

[Алексей Уколов]

dollar, при чём тут папки?

[Ankhena]

Положите на стул кнопку... Сел работать, а она так быстренько и напомнит. Думаю пары дней должно хватить. Если нет, то безнадежно.

[denzago]

Ankhena,

вам помогла? ;)

[Ankhena]

denzago, возможность накосячить или показать себя не профессионалом перед клиентом страшнее кнопки.

Answer 1

[Алексей Уколов]

Закрыть мастер для пушей, сливать только через пулреквесты.

Comments

[denzago]

Виноват, не все вводные данные дал...
master пушится на продакшен сервер
develop в тестовую песочницу.
такой вот примитивный диплой - внесли "логотипчик в список партнеров" запушили в девелоп, посмотрели с клиентом, как встало. Замерджили в мастер, запушили - наслаждаемся изменениями на проде. (пардоньте, за англицизмы)

PS
насчет пул реквестов - подумаю, в принципе, в схему впишется, и наверное, даже застрахует от случайного пуша обновлений сразу в мастер

[Алексей Уколов]

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

Answer 2

[eRKa]

1. Заканчивая работу, посреди монитора клеить стикер - Начинать работу с pull.
2. Потому что невнимательность. Но в большинстве случаев нет проблем затем перенести коммиты в нужную ветку.

Comments

[denzago]

1. Эдак у меня весь монитор будет обклеен стикерами, когда проектов несколько.
2. Согласен, невнимательность. Опять же несколько проектов если вести, внимание рассосредотачивается, вероятность ошибки возникает. Проблем с переносом то нет, вопрос как это минимизировать.

[eRKa]

denzago, ну если так ставить вопрос, то это будет из разряда "как сходить поссать, когда ссать хочется и минимизировать издержки".
Все это минимизируется постоянным повторением, привычкой. Я понимаю, что можно забыть подтянуть изменения, если это первые проекты и руки еще не в курсе что делать. Но если, как Вы говорите, несколько проектов, то тут нескольких дней хватит.
И вообще, я никого не знаю, кто бы в девелоп сразу работал. Обычно под каждую задачу создаешь ветку от девелопа, в ней работаешь, потом ее уже сливаешь в девелоп. При таком расскладе, все изменения девелопа достаточно подтянуть перед мержем своей фичи.

[denzago]

eRKa,

под каждую задачу создаешь ветку от девелопа

это учту, когда будет совместная разработка.

пока схема "в одного", еще не уверен в необходимости этого

Answer 3

[solascriptura]

Пользоваться процессами для командной работы. Даже если вы пока не работаете в команде себя нужно к этому приучить, тогда все будет намного проще, и с мерджами не будете мучаться. Есть переведенная статья с правилами: https://habr.com/post/106912/. Если хотите, обращайтесь, покажу как у меня это работает.

Да и... если вы не успели еще на мастер сделать коммит, а только изменений наделали, вы можете переключиться на девелоп без проблем, и коммитить уже в нем, никаких лишних команд при этом делать не нужно. Кстати, это тоже вариант решения - достаточно приучить себя перед любым коммитом(и вообще в каждой непонятной ситуации с git) делать git status и смотреть, на правильной ли вы ветке.

Comments

[denzago]

спасибо за ссылку, буду изучать.

не успели еще на мастер сделать коммит, а только изменений наделали, вы можете переключиться на девелоп без проблем,

это да, весьма помогает. главное во-время заметить.

Answer 4

[Decadal]

Предед началом работы над новой таской
git checkout master
git pull
git checkout -b task_number_and_task_name
Выглядит как будто это ещё сложнее запомнить, до тех пор пока вы не представите что сотня условных разработчиков могла уже напушить в мастер кучу кода, и на ветке девелоп куча кода которому уже три года но его не одобрили в мастер.

Тогда вы будете работать каждый раз над новой задачей в новой ветке. Потом будете мерджить эту ветку в develop, для демонстрации своей таски. А потом если все ок то мерджите в мастер(или кидаете мердж реквест) свою ветку (не develop)

Страх конфликтов заставит вас запомнить работу с ветками, и git status вы будете набирать уже по привычке везде и всюду)

И да, желательно три сервера. Демо, стейдж и прод.
Демо содержит мусорную develop ветку. Стейдж содержит мастер ветку. И прод тоже мастер ветку. Хорошая работа вашей таски в мусорной ветке ещё не гарантирует таковую в мастере

Comments

[denzago]

спасибо,
а это идея - "работать каждый раз над новой задачей в новой ветке"

насчет трех серверов - надо переварить. в текущий момент, проект - статика SPA. Физически сервер один, вероятность расхождения в работоспособности того же кода - минимальна (кажется)

PS
не совсем ясно, как организовать диплой между стейдж и прод

PPS
возможно демо в этой схеме есть мой локальный сервер на котором я смотрю свои правки в реальном времени.

[Decadal]

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

[Decadal]

denzago, локалка в схеме не рассматривается.
Демо нужен для тестировщиков. Это флоу для большой команды

Деплой между стейдж и прод? Ну на стейдж автодеплой, чтобы каждый пуш в мастер заливался на стейдж.
На прод ручной деплой. Вот и все

Answer 5

[dmitriy]

1. Установите develop основной веткой, в настройках репозитория
2. Используйте Soource Tree с gitflow схемой из коробки, будете работать через меню операций: начать исправление - завершить исправление, начать тематическую ветку - завершить тематическую ветку, и тд. Все проверки и рутинные операции возьмет на себя gitflow.

Comments

[denzago]

спасибо за gitflow, будем "курить"