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

Самый безопасный способ — создать синтетический коммит слияния, вливающий текущее актуальное состояние ветки master в ветку develop. Так у вас не будет проблем с отправкой исправления в общий репо и не будет конфликта с коллегами.

git checkout develop # удостовериться что мы в нужной ветке
git merge --ff $(git commit-tree -p develop -p master -m "Reset develop to master" master^{tree})

Если вас пригласили, то смотрите в уведомлениях гитхаба.

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

Можно вытянуть список репозиториев через запрос к API гитхаба:

curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
     -H "Accept: application/vnd.github.v3+json" \
     "https://api.github.com/user/repos?affiliation=collaborator" | jq -r '.[].full_name'

Тут используются утилиты curl и jq, их возможно придется предварительно установить если их ещё нет.
YOUR_GITHUB_TOKEN — ваш персональный токен доступа (его можно создать в настройках GitHub).

Формально GitHub всегда будет считать ваш проект форком, пока связь с оригинальным репозиторием не будет удалена.

В реальном мире граница между “форком” и “самостоятельным проектом” размыта. Если проект развивается, у него своя архитектура, комьюнити, документация, и его воспринимают как отдельный продукт — значит, он уже перестал быть “просто форком”.

Например:
• MariaDB — изначально форк MySQL, но сейчас это полностью самостоятельный проект.
• LibreOffice — форк OpenOffice, но никто не называет его просто “форком”.
• ReactOS — начинался как форк FreeWin95, но эволюционировал в отдельную ОС.

Вы некорректно поставили вопрос. Никакой репозиторий не может быть рабочим каталогом. Рабочий каталог репозитория и сам репозиторий это разные сущности и лежат в разных местах. Обычно репозиторий лежит в подкаталоге .git основного рабочего каталога проекта.

Вы наверное хотели спросить — может ли во внешнем общем репозитории тоже быть свой рабочий каталог?

Да, может, но с некоторыми ограничениями. Например нельзя пушить в ветку вышестоящего репозитория, если она в данный момент там активна и распакована в рабочий каталог. Если в общем репо HEAD стоит на ветке main, то вы легко сможете другие ветки отправить, но main не сможете и получите ошибку. И это логично.

Забирать коммиты вы сможете из любой ветки, даже из активной.

И у вас изначально ошибка вот тут:

Создаю на сервере репозиторий git init. Создаю у себя репозиторий

Для чего? Вы создали две отдельные истории. Даже если в обоих случаях получилась ветка с названием main, это всё равно будут разные ветки без общей истории. Не нужно так делать. Репозиторий следует создавать в одном месте, а затем уже клонировать в другие.

Очень многие наступают на эти же грабли, когда инициализируют репозиторий локально, а затем создают НЕ ПУСТОЙ репозиторий на гитхабе. Потом удивляются, почему не получается их связать. ))

Ни пуш ни пулл не работают.

Причина неработоспособности первого заключается в том, что ветка активна. Второй не функционирует из-за отсутствия коммитов в вышестоящем репозитории, поэтому нечего скачивать.

Поэтому общие репозитории проще делать без рабочего каталога, зачем он там?
Но теоретически можно работать децентрализованно. Допустим если вы все сидите в одном офисе, то можно некоторых коллег добавить как remote со ссылками в локальной сети и спокойно обмениваться коммитами в любую сторону. Почему бы и нет? Вы только не сможете пушить ветки, над которыми коллеги у себя в данный момент работают и не сможете сломать им код.

Если при git pull возникает конфликт, это означает, что история ветки разошлась. Пока вы работали в локальной ветке, кто-то другой внёс изменения и отправил их во внешний репозиторий. Теперь Git не может просто передвинуть указатель ветки на новый коммит — ему нужно объединить две разные версии в одну.

Вместо простого скачивания (fetch) и обновления указателя (fast-forward), Git создаёт коммит слияния (merge commit). Именно об этом говорит сообщение:

Merge remote-tracking branch 'refs/remotes/origin/' into

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

Да, этот коммит объединяет локальные и внешние изменения.

моя ветка поглащает origin и станет основной

Да, в вашем репозитории. Но вы же собираетесь продолжать совместную работу над проектом? Значит после завершения слияния (merge) вы отправите обновленное состояние ветки в вышестоящий репозиторий с помощью git push, и ваша версия ветки станет там «основной», иначе у вас будет локальная версия ветки, отличная от вышестоящей.

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

Что значит «я их принял»?
Конфликты нельзя просто «принять». Их нужно разрешить — вручную объединить изменения. Если вы просто удалили свои или чужие правки, то фактически потеряли часть кода. Будьте внимательны: важно не просто устранить конфликт, а сохранить все нужные изменения.

Сделав amend вы фактически убрали этот коммит f97331c1c из ветки vlad-account в локальном репозитории и начали строить альтернативную версию этой ветки от предыдущего коммита. Так как старый коммит никуда не исчез из дерева (на него по прежнему указывает ветка origin/vlad-account), получается, что вы создали разветвление, а ветки vlad-account и origin/vlad-account теперь стали разными ветками, поэтому гит не знает что делать если быстрая перемотка невозможна (non-fast-forward).

В данной конкретной ситуации, думаю, проще удалить старую историю, отправив локальную версию принудительно, указав ключ force.

git push --force

Гит вам советует склеить ветки обратно перед отправкой через pull
Это тоже вариант, но получатся дубли коммитов в истории и, возможно, конфликты.
Лучше просто перезаписать вторую ветку.

Git — это система контроля версий, которая помогает работать над проектами параллельно, не мешая друг другу. А то, что вы называете «залить на гит», скорее всего, значит «отправить изменения на GitHub» (или другую платформу). Эти понятия важно различать.

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

Что касается описаний изменений. Ваш друг прав: нужно объяснять, что сделано, но вручную перечислять каждую строку не требуется. Git сам показывает разницу между версиями, а платформы вроде GitHub делают это наглядно.

Вам стоит пройти курс по основам Git, чтобы понять, как он работает, зачем нужны ветки и как решать конфликты. Тогда таких споров не будет, и работа пойдёт быстрее.

Вы сами попросили гит не скачивать весь репо, а скачать только 900 коммитов основной ветки. (параметром --depth 900). Это называется поверхностная копия shallow clone.

Сейчас вы можете докачать всё с помощью команды
git fetch --unshallow
либо
git fetch --all

Если интернет ограничен, вы можете скачать например только последний коммит нужной ветки
git fetch origin updater --depth=1
И распаковать в рабочий каталог его
git checkout updater

Проблема не в 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.

Тут возможна путаница в терминологии.

Гитигнор не удаляет файлы из отслеживания, а скорее наоборот — игнор убирает файлы из списка неотслеживаемых (Untracked). Чтобы случайно не начать их отслеживать (случайно не добавить файлы в репозиторий).

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

Ну и ваше правило избыточно. Достаточно просто
__pycache__/

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

у меня не связывается папка B2 c репозиторием с гитхаба

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

Но вы это не видите, так как инициализировали в папке packages пустой репозиторий и именно для него VSCode и показывает кнопку Publish Branch.

.
└───yyy.loc
    ├───.git 
    └───packages
        ├───.git # пустой репо созданный git init
        └───B2
            └───.git

А чтобы VSCode увидел вложенный репо, лежащий в папке packages/B2 вам надо в папке packages тоже создать .gitignore и прописать в нем /B2/

Вы же сами увидели в vscode — что произошло. Вы забыли обновить ветку и начали строить вторую цепочку коммитов. Ваша ветка раздвоилась (diverged).

Гит вам тоже всё подробно пояснил, что нельзя пушить в другую ветку и предлагает вам сначала объединить разные ветки в одну используя pull.

Но тут вылезла другая проблема, что у вас немного недонастроен гит. В новых версиях он просит вас уточнить, каким методом вы хотите объединять ветки? Можно путем создания коммита слияния, а можно путем пересаживания вашей текущей ветки main на вершину вышестоящей ветки origin/main, чтобы история осталась простой и линейной, без этих разветвлений и слияний.

Первая стратегия задается командой
git config pull.rebase false # merge
И это поведение по-умолчанию которое было раньше. Рекоменду вам его и выбрать. Эта команда выполняется один раз и больше вам не потребуется.

А затем просто повторите git pull и всё сработает. Разве что могут возникнуть конфликт, но это уже другая тема.

Если хотите сохранить линейную историю то можно принудительно вызвать вторую стратегию только для одного раза
git pull --rebase

Гуглить фразу failed to push (не удалось отправить) бесполезно. Это слишком абстрактное описание проблемы. Причины могут быть самые разные.

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

На данном этапе вам проще удалить репозиторий
rm -rf ".git"
И начать заново. Но не пихать в коммит что попало, git add . а индексировать только нужные файлы.

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

Моно-репозиторий — это репозиторий, который содержит исходный код и ресурсы для нескольких проектов в одной общей структуре. Обычно разработчикам требуется не весь репозиторий целиком, а только отдельный каталог, относящийся к конкретному подпроекту. Однако 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

по мнению status никаких неотслеживаемых файлов нет, а по мнению pull есть неотслеживаемые файлы которые будут перезаписаны. Как так?

Легко! В вышестояшем репозитории эта папка закоммичена. При pull возникает конфликт.

А вот кстати и коммит который пытаюсь спулить:
[htdocs]$ git status

Коммит то где? Статус рабочего каталога это не коммит.

Что может быть не так?

Забудьте про команды типа

git add --all .
git commit -am "..."

Которые добавляют в репозиторий что-попало. Индексируйте только нужное, и проблемы исчезнут.

И покажите свой .gitignore