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

Просто найдите «macOS Sonoma» в App Store и нажмите «Get» → установщик загрузится в «Программы»

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

Поэтому само наличие второго аккаунта GitLab не всегда нужно. Хотя на работе могут выдать отдельный логин — и тогда появляются сложности.

Возможные варианты:

1. Работать только с рабочим аккаунтом, а в личных репозиториях просто дать ему доступ на запись.

2. Постоянно перелогиниваться, что неудобно: Git будет путаться в кэше аутентификации.

3. Разделить протоколы:
– личные проекты — через HTTPS,
– рабочие — через SSH.
Так Git не будет пересекать ключи и пароли.

4. Использовать трюк с виртуальными хостами (как написал Виктор).
Git всегда использует один SSH-ключ на один хост, но мы можем создать сколько угодно “виртуальных” хостов и привязать к каждому свой ключ. Git будет думать, что это разные GitLab-сервера.

Я заметил, что у вас два аккаунта на 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