mayton2019

Картинки в Markdown вставляются так.

![SVG Image](https://host.com/your-image.svg)

Ессли SVG не отрисовывается - сконвертите его в формат растровой картинки.

Если команда большая (больше чем скрам) то имеет смысл раз в неделю собираться на голосовом
митинге в полном составе и хотя-бы по 5 минут заслушать каждого. Кто чем болеет. Какие проблемы.
Какие разработки. Далее по результатам надо думать о создании общего репозиатрия кода.
Что-то вроде библиотеки. И сводить в библиотеку только реально нужное и разделяемое между
проектами. Библиотекой должны заниматься опытные. Она должна иметь структуру и документированность.
Она должна вбирать в себя только полезное. По принципу реального боевого кода. Код который
морально устарел или не используется лучше выбросить из библиотеки.

Нужно создать условия когда код из библиотеки не копируется а инклудится в проекты. Если кто-то
берет наброски и "дорабатывает" - надо смотреть что он доработал и почему.

По иному - вряд-ли получиться. Сниппеты и горизонтальная переброска кусков кода между верстальщиками
и разработчиками - это хаос. Кроме роста количества файлов и сниппетов - ничего полезного не будет.

1) Проблема решается просто переносом home каталога вашей проги "во вне" корня репозитария кода.

2) Непонятно почему вы боитесь что-то добавлять в игнор. Обычно туда уходят специфичные extenions, *.o, *.exe, *.dll которым точно не место в коммитах или фолдер типа /bin или /target который проще менеджерить чем список расширений.

Сделайте так и не будьте мышками которые плачут колються и едят кактус.

гит выдал 25 ошибок, при том, что локально естественно всё прекрасно работает

Я не понимаю. Либо тесты не релевантны к бизнесу. Либо ваше бизнес тестирование просто ходит
по happy path.

Доступ к истории проекта закрывать нельзя. Это противоречит идеологии версионного контроля. В старых версиях кроме sensitive info могут быть знания по предметной области. Нам в разработке с одним банком очень помог анализ истории. По крайней мере мы поняли некоторые причины дефектов мультипоточки.

То что пароли и токены коммитились - это epic fail, но лучше их обновить чем поступать как тупо. Вы-же не хотите походить на пришельцев-бюрократов расы "вогонов" (из романа Дугласа Адамса) которые уничтожили планету Земля только потому что им надо было шоссе построить в космосе.

Коммит - это просто текстовое сообщение которое добавляется командой

git commit -m "Message text here..."

Сделай

git log
для обоих проектов и посмотри как текст выглядит внутри.

Я думаю что ничего интересного там нету.

Его никто не будет смотреть скорее всего.
Просто формат такого общения как кидание ссылками предполагает что вы совсем не цените собеседника.
Мне вот вообще не интересно смотреть никакие гитхабы без наличия автора рядом. Чтобы он дал
поясняющие комметарии по каждой строчке кода. В противном случае я подумаю ... нет я побоюсь
такое подумать что меня просто обманывают и подсовывают чуждой код.

Код как и курсовой требует защиты. А также вступительной речи на тему зачем это вообще нужно и какова
мотивация.

Такие ограничения есть во многих поисковых системах. Это сделано специально для экономии ресурсов. Идея такая что пользователь - просто должен будет детализировать фильтры для поиска нужного результатат. В противном случае, введя символ "asterisk" или любой другой мета-символ можно ddos-ить поисковые системы очень легко.

Как построить их работу так, чтобы в основной репозиторий всё попало одним пулл-реквестом (желательно от программиста)?

Непонятно, какая при этом решается задача. Просто эстетика? Или страх неконсистентного пул-реквеста?

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

Если нет - то тогда вам нужен некий внутренний тестировщик который может что-то быстро проверить и поставить тег что дескыть здесь окей и можно делать промежуточный релиз-кандидат или релиз.

Вот
rsync .... --delete

Можешь сделать
git log
и посмотреть историю изменений
Потом
git checkout xxxxxx
и указать хеш коммита.

Описанный сценарий для GitHub - совершенно нормальный. Бывает и такое.
Перенос изменений из одной ветки в другую делается всегда через merge.
И это - ручной процесс. Тоесть все конфликты merge ты ресольвишь сам вручную.

Ветки А/B/C и master/dev - абсолютно одинаковые с точки зрения слияния и
самому гитхабу безразлично куда вы будете сливать изменения.