а тот кто задания выдаёт наверное как-то пытается сделать задачи давать так чтобы разрабы друг-другу поменьше мешали

верно

спасибо. наверное работу с ветками в гит следует повторить)

этот навык никогда не помешает освежить в памяти)

по гиту лучший туториал есть - https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud

от начинающего до нинзя

По гіту ось у мене є збірки лінків, так щоб фундаментально:
https://github.com/kpi-web-guild/django-girls-blog-slsh1o/issues/4 / https://github.com/kpi-web-guild/django-girls-blog-slsh1o/issues/6 / https://github.com/kpi-web-guild/django-girls-blog-slsh1o/issues/7

а у своїх проектах теж би так треба було: CI/тести/лінтери/нормальні коміт меседжі/атомарні зміни, оце от усе

Количество людей четкое:)

В профессиональной разработке часто ESLint используют? Я в пет-проекте попробовал, но мне он надоел своими предупреждениями.

Завжди

Это как использование каски на стройке, сначала неудобно, а потом понимаешь для чего она нужна)

понял. буду юзать значит.

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

лінтери (будь-які) допомагають (1) уникати типових проблем, (2) підтримувати однаковий вигляд коду в проекті і (3) підтягувати найкращі практики, що з'являються з часом.
якщо на тебе лінтер багато свариться, це значить, що ти код проблематичний пишеш. він тебе тренує писати краще і з часом в тебе вже звичка не робити певні помилки з'являється.
крім того, це може слугувати сигналом можливої наявності гівнокоду. наприклад, правило, що каже, що рядок коду занадто довгий це не просто перевірка довжини рядка з якоюсь випадковою константою дозволеної довжини. довгі рядки не дуже читабельні (а код читається людьми значно більше, ніж пишеться), крім того, вони не влазять на екран, якщо розмір шрифту розробника великий (привіт accessibility), або якщо у вертикальних панелях кілька файлів дивитися, або при використанні split view diff і ще купі випадків. також, довгі рядки можуть означати що (1) в одному рядку понапихано забагато всього структурно, відповідно складність розуміння страждатиме при читанні, або (2) цей рядок знаходиться в дуже вкладеному коді (наприклад, 5 вкладений циклів for), це теж сигнал що даний шматок треба би порефакторити, а не просто зробити з одного рядка два (умовно).
це приклад лише одного виду правил, але подібні переваги є в усіх інших.
це до того, що коли ти пишеш код у тебе мислення орієнтоване на вирішення чогось маленького специфічного, але для проекта ще дуже важливо, щоб він лишався читабельним, мав високу maintainability і т.д.

хорошо. буду приучаться использовать

Я зараз трішки накину, соррі, але мені справді цікаво.

TS створювався як надбудова над жс, яку жс розробники можуть легко освоїти. Але по-факту TS вже має цілу окрему мову для опису типів, майже turing complete, вона не інтуїтивна, і освоїти її зовсім не легко.

То в чому сенс зараз вчити ТС, а не якусь нормальну статично строго типізовану мову без зворотньої сумісності з жс?

Це яку?

та будь-яку, elm, purescript, reason тощо