ой да ладно ты принижать свои знания… не первый день уже в чатике по вронту помогаешь

🤓 я вообще саппорт по жизни (5 лет в этой теме проработал)

а скажи чво нить на саппортийском

выключите и включите

аж до мурашек)

ладно, пошел дальше симфони насиловать

Спасибо вам большое за помощь!

А что вы делаете перед тем как сделать коммит?
Я начинающий. Я смотрел  уроки по прог-ю, но там гит не используют. Смотрел уроки по Git, но там все делают на примерах "Hello word". Я ни разу не видел как работают с гитом при профес-ой разработке.
Ну например нужно ли просматривать все измененные файлы перед коммитом, подправлять там код, стирать консольлоги? Может делать тесты? Должен ли при коммите проект быть работоспособным? и т.д.
Такие моменты меня интересуют.

Посмотри у меня на канале, там есть)

ну лично у меня обычно такой порядок:
1. git status (показывает в каких файлах были изменения)
2. если git status показыват все нужные файлы:
git add .
если есть файлы что не нужны, тогда добавляю только нужные:
git add file_name
3. git commit -m "описание что сделано, обычно на англ языке"

+, только я ещё делаю pull перед git add, чтоб, в случае чего, пофиксить конфликты на локале

кто-нибудь по vue может подсказать? у меня стоит задача сначала закинуть запрос на публичный api, получить данные и впоследствии их изменять, но при изменении я заново каждый раз запрашиваю и вывожу элементы, как тут вообще можно закэшировать данные у себя, чтобы каждый раз не запрашивать? с vuex не работала, но чувствую что где-то там решение и вот чет не вдупляю как один раз запросить и больше не запрашивать, храня во vuex

смотря какие инструменты юзаешь, можно как Игорь сказал, если в CLI, можешь через графический инструмент.

А дальше зависит от флоу и размеров команды.

у нас: для ветки создается мерж реквест (МР) который должны отревьювить коллеги. Если МР сообщает о конфликтах – то идешь разруливать конфликты, подтягивая изменения в свою ветку. Опять же, либо мержа целевю ветку к себе, либо делая ребэйз (у нас ребейз). И после решения конфликтов снова отдаешь задачу в ревью.

После получения одобрения коллег мержишь ветку. Иначе возвращаешься к доработкам по комментариям в МР. После пуша изменений снова просишь ревью коллег

спасибо. а каким образом ревьювер делает замечания по коду? куда он их пишет?

а ты что для гита используешь?

хотя, в целом, оно везде примерно так выглядит

https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request

с погрешностью на используемые инструменты )

https://youtu.be/TKaq8rpNNrw нулевой плейлист просмотри на ускоренной)) думаю что 99% вопросов отпадет. Там от "создаем новый репозиторий" до "подключаем actions для генерации документации в автоматическом режиме". Коммиты - в ассортименте)   ПС: модерам - если нельзя, снесите ссылку, не рекламы ради кинул... хотя вру - и рекламы тоже)

можете подсказать кейсы когда интерпретатор поставит точку с запятой и будет ошибка?
я слышал их всего-то пару-тройку таких.
я только знаю что такое нельзя писать:

return
  "some var"

return
  "some var"

наверно тут https://stackoverflow.com/questions/2846283/what-are-the-rules-for-javascripts-automatic-semicolon-insertion-asi