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

Я заметил, что у вас два аккаунта на GitHub. Согласно правилам, создание дубликатов аккаунтов не рекомендуется — это может привести к путанице с доступами, как в вашем случае, а иногда и к блокировке.

Лучшее решение — удалить дополнительный аккаунт и создать организацию. Репозитории можно перенести туда и назначить себя администратором от основного аккаунта. Это удобно, прозрачно и полностью соответствует политике GitHub.

Сейчас вы создали новый аккаунт, но в GitHub Desktop остались под старым. Из-за этого попытка push в репозиторий заканчивается ошибкой «permission denied», потому что у текущего аккаунта нет прав.

Временные варианты:

• перелогиниться в GitHub Desktop,
  
• или выдать доступ старому аккаунту (через Collaborators).
  

Но повторюсь — лучше объединить всё в один основной аккаунт и использовать организации. Так проще и безопаснее.

Да, можно сделать git revert на revert-коммит — так возвращают отменённые изменения.
Проверьте, что именно вернёте, и напишите в коммите понятно (Restore: фильтр по датам, а не Revert "Revert...").
Если восстановить аккуратно не получается, проще сделать новый коммит руками.

Альтернативы revert:
— сделать новый коммит руками, переписав изменения заново,
— git cherry-pick нужного старого коммита,
— git rebase -i (локально переписать ветку и удалить ненужный revert-коммит),
— git reset на более ранний коммит (если хотите полностью откатить ветку назад и начать заново, и если её ещё никто не забрал).

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

github-workflow.yml

- name: Build and Push Docker Image with Kaniko
        uses: int128/kaniko-action@v1
        with:
          context: .
          file: Dockerfile
          push: true
          build-args: |
            ID_RSA=${{ secrets.ID_RSA }}

в Dockerfile

ARG ID_RSA
RUN mkdir -p /root/.ssh
RUN echo "$ID_RSA" | base64 -d > /root/.ssh/id_rsa
RUN chmod 600 /root/.ssh/id_rsa
RUN ssh-keyscan github.com >> /root/.ssh/known_hosts

Почему «пропали» коммиты?

Главная ошибка — использование --amend во время rebase.
Команда git commit --amend не создает новый коммит, а перезаписывает предыдущий.

Когда вы время интерактивного rebase на каждом шаге делаете --amend, вы по сути всё время заменяете один и тот же коммит. Остальные коммиты, которые Git должен был «применить» в процессе ребейза, просто исчезают, потому что их заменили.

Как делать правильно?

Во время rebase -i вместо amend нужно:

git add <файлы> #  главное проиндексировать правки файлов
git rebase --continue # тут гит уже сам сделает git commit --no-edit

Вручную делать git commit перед continue имеет смысл только если вы хотите поменять ещё и сообщение коммита.

Как восстановить утерянные коммиты

Git не удаляет коммиты сразу. Они остаются в репозитории и доступны в reflog — журнале ссылок.

Их можно найти так: git reflog

Затем восстановить ветку: git reset --hard <хеш_из_reflog>

Вывод

Это не баг Git, а ожидаемое поведение. Просто rebase + amend — взрывоопасная смесь, особенно если не до конца понимать, что происходит.

Абсолютные ссылки вроде /about.html не работают, потому что GitHub Pages размещает сайт по адресу https://nushany.github.io/prob/, а не в корне. Ссылка /about.html ведёт на https://nushany.github.io/about.html, где файла нет — отсюда и 404.

И не пытайтесь выкладывать питоновские исходники и прочие файлы. Помещайте в репозиторий только откомпилированные статические html-файлы и картинки.

В Git у коммита есть две даты:

• AuthorDate — когда работа была написана (автор)
  
• CommitterDate — когда она попала в историю репозитория (коммиттер)
  

Если ваш работодатель почему-то ориентируется на дату коммита, а не на его содержимое — можно сразу задать нужное время при создании:

GIT_COMMITTER_DATE="2025-03-28T17:00:00" git commit --date="2025-03-28T17:00:00" -m "Your message"

Это работает только в bash, zsh и других POSIX-совместимых оболочках. В PowerShell не сработает.

Если коммиты уже сделаны, можно их поправить через перебазирование:

git rebase -i HEAD~N

Меняете pick на edit, потом:

GIT_COMMITTER_DATE="2025-03-28T17:00:00" git commit --amend --no-edit --date="2025-03-28T17:00:00"
git rebase --continue

Так можно переписать историю аккуратно, без изменений содержимого.

Можно попробовать подойти к задаче через автоматическую генерацию миграций из базы, чтобы не переносить данные вручную в CSV и SQL.

Вот несколько подходов, которые могут помочь:

1. Liquibase diff
   
   Liquibase умеет сравнивать текущее состояние базы с эталонным snapshot или changelog (команды liquibase diff, generateChangeLog). Это может автоматически сгенерировать changesets. Не всегда идеально, особенно для данных, но может служить хорошей стартовой точкой.
   
   
2. Скрипт дампа и автоформатирования
   
   Написать утилиту, которая:
   
   • выгружает актуальные записи (по дате или через служебную метку),
     
   • форматирует результат построчно (для удобных диффов в Git),
     
   • сохраняет в SQL или CSV с нужным форматированием,
     
   • проверяет ошибки: зависимости, ключи, синтаксис и т. п.
     
   
   
3. Служебное поле change_id
   
   Добавление такого поля в ключевые таблицы упростит группировку и экспорт связанных изменений. Это также упростит отладку и проверку связей.
   
   
4. Проверки перед мержем
   
   Автоматический pre-merge скрипт может:
   
   • проверять, что ветка актуальна относительно master,
     
   • валидировать синтаксис SQL и CSV,
     
   • выявлять ошибки в зависимостях (foreign keys, отсутствие spec при наличии body и т. п.),
     
   • проверять потенциальные конфликты по ключам в changesets.
     
   
   
5. Dolt и Bytebase
   
   Как уже писали выше, эти проекты позволяют рассматривать базу как репозиторий Git. Подход интересный, но требует серьёзной перестройки процессов. Внедрение возможно, если проект активно развивается и готов к архитектурным изменениям.
   

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

GitFlic и GitVerse не поддерживают форки с GitHub, но это и не нужно. Достаточно клонировать репозиторий и работать с ним как с обычным проектом.

Сначала клонируем репозиторий с GitHub командой git clone, затем заходим в папку проекта. Добавляем второй внешний репозиторий, например, на GitFlic: git remote add myrepo https://gitflic.ru/user/repo.git. После этого отправляем код на новый сервис через git push -u myrepo main.

Когда в оригинальном репозитории появляются изменения, получаем их с помощью git fetch origin, затем сливаем в свою ветку git merge origin/main. Если есть конфликты, решаем их, коммитим и отправляем в свой репозиторий git push myrepo main.

Кстати, даже на GitHub кнопка «Синхронизировать форк» не работает, если есть конфликты. Всё равно приходится делать fetch, merge и разбирать изменения вручную. Так что встроенный форк не даёт никаких преимуществ — стандартный механизм Git решает задачу лучше и универсальнее.

Самый безопасный способ — создать синтетический коммит слияния, вливающий текущее актуальное состояние ветки 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).

Ну и вот тут показывает полный список https://github.com/settings/repositories
Спасибо dreadwood за наводку

Формально 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) используются в крупных проектах для поддержки старых релизов и выпуска патчей. Если у вас нет таких требований, можно обойтись одной актуальной веткой.

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

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

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

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

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