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

Проблема не в URL-адресе (/ в конце пути не влияет на работу).

Permission to kirill-pereshyvalov-13/laravel-docker.git denied to KirillPereshyvalov13

— вероятно, вы вошли не под тем аккаунтом, который имеет доступ к репозиторию.

Возможно вы поменяли свой username для логина, а перелогиниться забыли, вот и ошибка.

Удалите неправильные учетные данные из кэша:

echo "url=https://github.com" | git credential reject

При следующей попытке git push залогиньтесь как kirill-pereshyvalov-13 а не как KirillPereshyvalov13

Если проект небольшой, то Gitflow вам, скорее всего, не нужен. Достаточно одной главной ветки (main), куда изменения вносятся через pull request. Для каждой задачи создаёте короткие ветки (например, feature/task-name), работаете в них и после завершения слияния с main удаляете. Саму ветку main закрывайте от прямых изменений. Никто не должен коммитить напрямую в main.

Что касается веток на сервере: храним как минимум те ветки, с которыми совместно работаем. Иначе как коллеги их получат к себе? Это могут быть главная ветка, стабильные версии или временные ветки задач, если нужно поделиться ими с коллегами. Всё остальное — локально.

Ветки с номерами версий (например, 2.3.X) используются в крупных проектах для поддержки старых релизов и выпуска патчей. Если у вас нет таких требований, можно обойтись одной актуальной веткой.

Ошибка возникает из-за проблем с биллингом: неоплаченные счета, активные подписки или некорректные данные оплаты. Проверьте раздел Settings → Billing & plans, обновите данные и отключите подписки. Если проблема не решается, обратитесь в GitHub Support.

Вас пометили как спамера. Пишите в Support, чтобы разблокировали.

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

Моно-репозиторий — это репозиторий, который содержит исходный код и ресурсы для нескольких проектов в одной общей структуре. Обычно разработчикам требуется не весь репозиторий целиком, а только отдельный каталог, относящийся к конкретному подпроекту. Однако Git по умолчанию скачивает весь репозиторий, включая ненужные файлы и каталоги.

Git теперь поддерживает так называемое выборочное скачивание содержимого через механизм sparse-checkout. Это позволяет вам работать только с нужными файлами или каталогами, исключая остальные, такие как node_modules.

# Клонировать репозиторий с фильтром, чтобы не загружать все файлы сразу
git clone --filter=blob:none --sparse https://example.com/repo.git
cd repo
# Инициализировать выборочную загрузку
git sparse-checkout init --no-cone

Нужно отредактировать файл .git/info/sparse-checkout:

# включить все файлы
/*
# кроме одной папки
!/node_modules/

Применить настройки

# Докачать всё, кроме папки node_modules
git sparse-checkout reapply

После выполнения этих команд Git скачает весь репозиторий, исключая указанный каталог node_modules. Вы сможете работать с репозиторием, не загружая лишние данные. Если потребуется вернуть node_modules, достаточно удалить соответствующее правило из файла sparse-checkout и снова выполнить git sparse-checkout reapply

Отменить все незакоммиченные изменения в рабочем каталоге поможет команда
git reset --hard

PS. Немного подумав мне теперь нравится такой универсальный и более корректный способ.

git restore --source=хеш_коммита --staged --worktree .

Затем не забудьте закоммитить новые изменения.

Указывая --source=хеш_коммита, вы говорите Git использовать содержимое файлов из этого коммита.

Флаг --staged значит, что изменения будут сразу проиндексированы, как если бы вы их добавили с помощью git add. Этот флаг особенно полезен, если вы хотите сбросить изменения, которые уже были добавлены в индекс, но ещё не закоммичены.

Флаг --worktree указывает Git восстановить файлы в рабочем каталоге до состояния указанного коммита. Это означает, что любые незакоммиченные изменения в рабочих файлах будут сброшены, и файлы будут восстановлены до состояния, соответствующего указанному коммиту.

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

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

Чем вам вообще не устроил официальный GitHub CLI?
gh repo create Sushilka
Одна строка вместо вашей портянки и никакие токены не нужны.

Это может быть связано с тем, что ваш аккаунт подвергся ограничению за нарушение правил сервиса — своего рода «теневой бан». Рекомендую проверить свою почту на наличие писем от GitHub с темой Your account has been flagged. Если такое письмо есть, вам нужно будет следовать инструкциям в нем, чтобы разблокировать свой аккаунт.

На скрине у вас какой-то очень долгоиграющий 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, то процедура тоже ничем не отличается от описанной в документации. Просто следуйте официальным инструкциям.

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