Задать вопрос
  • Оптимальный перенос Windows Server и сервисов в Proxmox?

    sergey-kuznetsov
    @sergey-kuznetsov
    Автоматизатор
    Самый безопасный способ — P2V‑миграция (перенос с физического сервера в виртуальную среду). Мы раньше делали это через Acronis и VMware Converter, когда внедряли ESXi.

    Сейчас я бы посмотрел в сторону StarWind V2V Converter или Veeam — оба позволяют конвертировать Windows Server в формат, совместимый с Proxmox.
    При этом IP-адреса, SID и роли (например, контроллер домена) не меняются, если всё делать правильно, так что проблем с AD быть не должно.

    Также важно по возможности избежать вложенной виртуализации — лучше перенести гостевые ВМ сразу в Proxmox, а не тянуть за собой весь Workstation.
    Ответ написан
    Комментировать
  • Можно ли обновить макос на sonoma вместо sequoia?

    sergey-kuznetsov
    @sergey-kuznetsov
    Автоматизатор
    Просто найдите «macOS Sonoma» в App Store и нажмите «Get» → установщик загрузится в «Программы»
    Ответ написан
    2 комментария
  • Можно ли пользоваться двумя аккаунтами в Gitlab одновременно?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега GitHub
    Автоматизатор
    Вы уже поняли, что забыли передать ключ в контейнер.

    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
    Ответ написан
  • Как вернуть коммиты после rebase?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Почему «пропали» коммиты?

    Главная ошибка — использование --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 — взрывоопасная смесь, особенно если не до конца понимать, что происходит.
    Ответ написан
    Комментировать
  • После запуска в github - page выдает ошибку 404, отображается только главная страница- index.html, как заставить работать остальные html страницы?

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

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

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    В 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


    Так можно переписать историю аккуратно, без изменений содержимого.
    Ответ написан
    Комментировать
  • Как оптимально переносить состояние таблиц и объектов PL/SQL из БД в Git?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Можно попробовать подойти к задаче через автоматическую генерацию миграций из базы, чтобы не переносить данные вручную в 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-ориентированных решений, где изменения фиксируются на уровне базы, а не вручную.
    Ответ написан
    Комментировать
  • Можно ли на gitverse и/или gitflic форкать чужие репозитории с github?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега GitHub
    Автоматизатор
    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 решает задачу лучше и универсальнее.
    Ответ написан
    Комментировать
  • Как сбросить состояние ветки develop к master непосредственно в репозитории (origin)?

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

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

    Подробное объяснение

    По мотивам аналогичного вопроса
    • Конструкция master^{tree} — это ссылка на текущее состояние файлов из ветки master.
    • Команда git commit-tree — создаёт новый коммит, который:
    • Использует файлы из master.
    • Имеет двух «родителей»: текущий develop и master.
    • Устанавливает сообщение коммита: Reset develop to master.
    • Таким образом, создаётся «мостик» между develop и master, чтобы история изменений выглядела непрерывно.
    • git commit-tree -p develop -p master -m "Reset develop to master" master^{tree}
      — эта команда не просто создаст новый коммит, но ещё вернёт его хеш.
    • Обновляем develop, чтобы она просто «перескочила» на новый коммит.
      git merge --ff $(...)
    • --ff (fast-forward) говорит гиту просто передвинуть указатель develop вперёд на этот новый коммит, если это возможно без создания нового коммита слияния.
    • $(...) — это подстановка команды в bash, то есть git merge --ff получит на вход хеш коммита из предыдущего шага.

    Ответ написан
    Комментировать
  • Как посмотреть чужие репозитории GitHub, в которых я участник?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега GitHub
    Автоматизатор
    Если вас пригласили, то смотрите в уведомлениях гитхаба.

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

    Можно вытянуть список репозиториев через запрос к 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 за наводку
    Ответ написан
    1 комментарий
  • Когда форк перестает быть форком?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

    git push --force

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

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

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

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

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

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

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

    Если интернет ограничен, вы можете скачать например только последний коммит нужной ветки
    git fetch origin updater --depth=1
    И распаковать в рабочий каталог его
    git checkout updater
    Ответ написан
    Комментировать
  • Не получается подключиться к GitHub. Как решить проблему?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Проблема не в 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
    Ответ написан
    Комментировать