Сергей Кузнецов

На скрине у вас какой-то очень долгоиграющий Pull Request. Никогда не видел, что за сотни коммитов так и не смогли доделать задачу. Обычно требуется максимум десятки итераций.

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

В том выпадающем окошке, которое вы замазали, в самом начале есть «секретные» опции

• Показать сразу все изменения пиара.
  
• Показать только то, что изменилось после вашей последней рецензии.
  
• Либо с зажатой клавишей Shift выделить диапазон коммитов.
  
  

При выборе этих вариантов покажется суммарный вклад многих коммитов и тогда кнопки вперед и назад уже неуместны.

Чтобы файл оказался во внешнем репозитории, его следует сначала закоммитить, чтобы он попал в локальный репозиторий. А уже после пуша новых коммитов, вы увидите изменения на гитхабе. Что за ошибка при аутентификации через терминал — это уже другой интересный вопрос.

Изначально непонятно, почему вы хотите, чтобы точка входа на ваш сайт была в описании репозитория на GitHub, почему не сразу на GitHub Pages?

Как можно сделать так, чтобы человек заходил в мой профиль гитхаба и видел в репозитории проекта «Мой сайт» только README-файл?

Когда кто-то заходит в ваш репозиторий, то он видит содержимое вашей ветки по-умолчанию. Скрыть файлы из ветки нельзя, если они там реально есть.
Вы можете создать ещё одну ветку, поместить в неё только файл Readme и сделать её основной. Либо публиковать ваш сайт из ветки gh-pages, а в ветке main удалить всё что вы не хотите показывать. В любом случае люди смогут выбрать любую ветку вручную и посмотреть все что там есть сейчас, либо было когда-либо раньше. Так как репозиторий помнит всё.

Как спрятать файлы через gitignore

Что делает файл gitignore?
Файл gitignore помогает не добавить случайно файл в репозиторий. Он действует только на ещё неотслеживаемые файлы в рабочем каталоге. Если файл уже в репозитории, то совершенно не важно, что у вас прописано в игноре. И даже если файл есть в игноре, это всё равно не помешает нам добавить его в репо, при желании.

Что не умеет делать файл gitignore?
Добавление файла в игнор точно не удалит файл из репозитория, и даже не сделает его невидимым.

У вас проблемы с пониманием того, что такое указатель HEAD.

в новой ветке будет правильно установлено положение HEAD

установить в ветке main ту же позицию HEAD, что и в ветке temp

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

Обычно указатель HEAD ссылается на ветку, но если по ошибке, вместо reset использовать checkout на произвольный коммит, то указатель HEAD станет ссылаться на этот коммит, а не на ветку. Мы как бы выходим из ветки в никуда. Это состояние называется detached HEAD.

Если в истории проекта есть коммиты этого человека, то мы увидим его в списке Contributors — тех авторов коммитов, кто внес свой вклад в проект.
Имена авторов коммитов берутся из подписей коммитов и не всегда их можно сопоставить с конкретными аккаунтами гитхаба, так как люди не удосуживаются настроить подпись, а на гитхабе вообще скрывают своё мыло. В итоге не попадают в список авторов и их работа остаётся анонимной.

Пытаться удалять человека из авторов (забывать его вклад) нет смысла. Достаточно забрать права на изменения, или вообще удалить из списка Collabolators.

Объясните, плиз, в двух словах

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

Основная задача, чтобы на гитхабе был основной репозиторий

Все репозитории на самом деле равноправны и вы можете любой из них объявить «главным», если хочется. Это вообще не важно.

На остальных компах такие же настройки сделать?

Эти настройки задают подпись, которая поставится на новых коммитах. Следовательно настроить подпись вы должны везде, где будете коммитить. В том числе и на гитхабе надо настроить эту подпись. Но так как там у вас нет доступа к командной строке, то настраивается через веб-интерфейс:

Или сделать на каждом компе имя типа MyName_COMP1?

Вы хотите сохранять информацию о том, на каком компе создан коммит? Что это вам даст?

для компов репозиторий на гитхабе является remote или origin?

Репозиторий с которым вы работаете на текущем компе, является локальным. Все остальные по отношению к нему будут называться внешними (или удаленными, по-английски — remote). Ссылку на внешний репозиторий обычно запоминают в специальной переменной. Как правило используется связь с одним внешним репозиторием и принято называть эту remote-переменную origin. Но это имя может быть абсолютно любым, особенно если внешних репозиториев подключено несколько. Например вы можете вообще не использовать гитхаб, а обмениваться коммитами между компами напрямую. Ваш локальный репозиторий на одном компе станет внешним для другого репозитория на соседнем компе. Всё относительно.

Ветку надо создавать новую, а не пытаться переименовать main.

Когда вы клонировали проект, то ваша локальная main автоматически связалась с внешней main на гитхабе. От переименования эта связь никуда не денется и при дальнейшем push вы будете отправлять всё равно в main, что запрещено у вас. Поэтому вы и получаете ошибку.

Ваша проблема в том, что готовый проект после компиляции складывается в каталог dist, то есть корень проекта фактически будет в том каталоге. А гитхабу в настройках вы сказали что проект будет лежать в корне самого репозитория. Он его там разумеется не находит и сообщает вам об этом ошибкой 404.

Буковка M в статусе означает что эти файлы уже добавлены в репозиторий или просто в индекс. Игнор не заставит гит игнорировать изменения файлов, которые уже контролируются. Игнор лишь немного помогает случайно не закоммитить новое. Игнорироваться будут только те файлы, которые ещё не проиндексированы и не находятся в репозитории.

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

У VPS нет особенностей, это такой же компьютер. Вы делаете всё то же самое, что ранее сделали на своём компьютере, чтобы получить доступ к этому репозиторию. У вас видимо проблема с непониманием самого процесса аутентификации.

Если вы хотите клонировать через https, то не забудьте создать токен персонального доступа, который потом будете вводить вместо пароля. Тот пароль, который вы вводите на сайте, не будет работать в терминале.

Если предпочитаете ssh, то процедура тоже ничем не отличается от описанной в документации. Просто следуйте официальным инструкциям.

Если вы админ, то интерфейс выглядит так:

Вы наверное не видите что делает напарник, потому что он работает не на вашем компьютере, а на своем собственном.
У него свой локальный репозиторий.
Откройте учебник и почитайте как обмениваться изменениями с коллегами.

Попробуйте Sincthing

Репозиторий созданный из шаблона, не содержит истории «родительского» репозитория. По факту это совершенно другой репозиторий, но созданный на основе последнего состояния проекта в шаблоне. Поэтому не получится так просто получить обновления, как это делается в форках.

Но можно склеить принудительно:

# Сохранить адрес шаблона в переменную template 
git remote add template https://github.com/OWNER/TEMPLATE.git
# Скачать все обновления
git fetch template
# Попробовать сделать слияние ветки BRANCH-NAME шаблона с нашей текущей веткой
git merge --allow-unrelated-histories template/BRANCH-NAME

Опция --allow-unrelated-histories нужна, так как истории веток никак не связаны.

GitHub Pages предназначен для статических сайтов и не поддерживает серверные языки, включая Node.js. Если ваш Next.js проект использует Node.js для серверной логики, рассмотрите альтернативные платформы хостинга, такие как Vercel, Netlify или Heroku.

Это лишь эвристическая подсказка. Она может появиться, а может и нет. Просто не обращайте внимания на неё, если не хотите сливать ветки. В интерфейсе гитхаба много кнопок и вы не обязаны нажимать их все.

Чаще всего люди спрашивают об обратном — почему такая подсказка у них не вылезла, так как они не знают других способов создать Pull Request. Они привыкли, что гитхаб обычно додумывает за них.

Ещё вы можете нажать на кнопку, но запрос не создавать. Плашка больше не появится.

Эти папки у вас существуют только в рабочем каталоге и их нет в репозитории, потому что гит отслеживает только файлы. Невозможно закоммитить пустой каталог. Каталоги фигурируют лишь как часть полного пути к файлам.

Если вам нужно непременно сохранить структуру каталогов, то поместите в них любой файл. Стандартная практика — создавать пустой файл с именем .gitkeep

Вы наверное забыли задать имя для собственной ветки.
Сейчас создайте новую ветку, с именем, которого ещё нет на гитхабе и тогда она ни с кем не будет конфликтовать
Например так:

git branch ветка # придумать название вашего проекта
git switch ветка # сделать эту ветку текущей
git push -u origin ветка # отправить текущую ветку в ветку «ветка» и связать их

Если задали пароль ключа, при его создании, то он спрашивается при использовании.
Настройки GitHub Desktop тут никак не влияют.