GIT

Как удалить историю GIT

1. Создайте новый начальный коммит:

2. Удалите старую ветку main:

3. Переименуйте новую ветку в main:

4. Принудительно отправьте изменения в удаленный репозиторий:

5. Очистите локальный репозиторий (опционально):

Если вы хотите очистить локальный репозиторий от старой истории, выполните:

   git reflog expire --expire=now --all
   git gc --prune=now --aggressive

6. Обновите локальный репозиторий (если необходимо):

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

   git fetch --all
   git reset --hard origin/main

Важно:

Теперь ваш удаленный репозиторий будет содержать только один коммит с текущим состоянием проекта.

Как откатить последний коммит

Инструкция для отката последнего коммита, в зависимости от ситуации.

1. Откат последнего коммита без публикации

Если коммит ещё не был отправлен в удалённый репозиторий:

2. Откат опубликованного коммита (без изменения истории)

Если коммит уже отправлен в удалённый репозиторий:

После этого отправить изменения в репозиторий:

git push

3. Жёсткий откат опубликованного коммита (с изменением истории)

Если нужно полностью удалить коммит (и изменения), и ты готов "переписать" историю репозитория:

⚠️ Предупреждение: Этот способ может привести к проблемам для других разработчиков, так как история репозитория будет изменена.

Вывод

Выбирай способ в зависимости от ситуации: для локальных коммитов подойдут reset, для опубликованных — безопасный revert или жёсткий reset --hard. Если есть сомнения, уточни детали своей задачи!

Полное слияние ветки test в main с удалением test

📌 Задача

У вас есть две ветки: main и test. Вам нужно:

✅ Пошаговое решение

1️⃣ Переключаемся в main

git checkout main

2️⃣ Обновляем main перед слиянием (если работаем с удалённым репозиторием)

git pull origin main

3️⃣ Полностью заменяем main на test

git reset --hard test

4️⃣ Принудительно отправляем изменения в удалённый репозиторий

git push --force origin main

🚨 Внимание! Использование --force полностью заменит удалённую ветку main на состояние test. Будьте уверены, что ничего важного не потеряете!

5️⃣ Удаляем ветку test локально

git branch -D test

6️⃣ Удаляем ветку test на удалённом сервере

git push origin --delete test

🔥 Объяснение команд

Команда Описание
git checkout main Переключаемся в ветку main.
git pull origin main Загружаем актуальные изменения main.
git reset --hard test Полностью заменяем содержимое main на test.
git push --force origin main Принудительно обновляем main на удалённом сервере.
git branch -D test Удаляем локальную ветку test.
git push origin --delete test Удаляем ветку test в удалённом репозитории.

🚀 Итог

⚠ Важно!

Процесс разработки и интеграции изменений в основную ветку

Процесс разработки и интеграции изменений в основную ветку (main или master) в GIT обычно включает несколько этапов. Описание ниже основано на стандартном Git Flow, но может адаптироваться под конкретные требования.

1. Планирование и создание задачи

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

2. Создание новой ветки

Разработчик создает новую ветку на основе последней актуальной версии main:

git checkout main
git pull origin main
git checkout -b feature/new-feature

Где feature/new-feature — имя ветки, соответствующее задаче.

Если работа ведется с багфиксом, может использоваться ветка bugfix/bug-id.

3. Разработка и коммиты

Разработчик пишет код, делает изменения и фиксирует их:

git add .
git commit -m "Добавлена новая функциональность"

Рекомендуется делать осмысленные коммиты и использовать семантические сообщения (fix:, feat:, refactor:, docs:, test:).

4. Локальное тестирование

Перед отправкой изменений важно:

5. Отправка изменений в удаленный репозиторий

После завершения работы над задачей:

git push origin feature/new-feature

Создается Merge Request (Pull Request) в GitLab/GitHub.

6. Код-ревью

7. Интеграция в основную ветку

После успешного ревью:

8. Автоматизация через CI/CD

После слияния в main могут автоматически запускаться:

9. Удаление ненужных веток

После успешного слияния:

git branch -d feature/new-feature
git push origin --delete feature/new-feature

Это помогает поддерживать чистоту репозитория.

10. Деплой и релиз

Если проект использует версионирование:

Итог

Этот процесс помогает обеспечить стабильность разработки, контроль качества и чистоту репозитория. В реальных проектах могут быть добавлены дополнительные этапы, например, работа с hotfix-ветками, релизными ветками (release/), более строгий контроль тестирования и деплоя.

Переключение на другую задачу, когда текущая еще не закончена

Если текущая задача еще не завершена, но требуется переключиться на другую, важно сохранить прогресс, чтобы потом без проблем вернуться к работе. В GIT это можно сделать несколькими способами.

1. Использование git stash (Временное сохранение изменений)

Если изменения не готовы для коммита, можно их временно отложить:

git stash

Теперь рабочая директория станет чистой, и можно переключаться на другую ветку:

git checkout feature/another-task

Когда будет возможность вернуться к предыдущей задаче, можно восстановить изменения:

git checkout feature/new-feature
git stash pop  # Вернет изменения и удалит их из stash

Если требуется сохранить несколько отложенных изменений, можно посмотреть список stash:

git stash list

А затем применить нужный:

git stash apply stash@{0}

2. Коммит незавершенных изменений в черновую ветку

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

git checkout -b wip/feature-new-feature
git add .
git commit -m "WIP: временное сохранение"
git push origin wip/feature-new-feature

После этого можно переключиться на другую задачу:

git checkout feature/another-task

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

git checkout feature/new-feature
git merge wip/feature-new-feature

3. Коммит с пометкой WIP (Work In Progress)

Если возможно закоммитить частичные изменения, можно сделать коммит с пометкой WIP:

git add .
git commit -m "WIP: начало работы над фичей"

Затем переключиться на другую ветку:

git checkout feature/another-task

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

Какой способ выбрать?

Обычно в командах git stash подходит для быстрого переключения, а WIP-коммиты или черновые ветки — для более долгосрочных перерывов.

Squash & Merge в Git или сохранение истории коммитов без промежуточных записей

Squash & Merge — это способ слияния изменений, при котором несколько коммитов объединяются (squash — "сжимать") в один перед вливанием в основную ветку. Этот метод позволяет сохранить чистую историю коммитов без лишних промежуточных записей.

Как работает Squash & Merge?

Допустим, в ветке feature/new-feature есть несколько коммитов:

commit a1b2c3d - Fix bug in query handler
commit d4e5f6g - Add logging
commit h7i8j9k - Implement new feature
commit l0m1n2o - Fix typo in previous commit

При обычном merge они просто добавятся в основную ветку (main).

Но если использовать Squash & Merge, все эти коммиты объединяются в один:

commit p9q8r7s - Implement new feature and fixes

Таким образом, история остается чистой.

Когда использовать Squash & Merge?

✅ Когда нужно объединить "мусорные" коммиты (например, тестовые исправления, исправления опечаток).
✅ Когда код писался в несколько итераций, но результат — одно логическое изменение.
✅ При работе в feature-ветках, чтобы в main попадали только готовые коммиты.
❌ Не подходит для веток, где важна детальная история коммитов (например, в develop или release).

Как выполнить Squash & Merge?

1. Вручную через git rebase -i

Переключаемся на нужную ветку:

git checkout feature/new-feature

Запускаем интерактивный rebase:

git rebase -i main

Git покажет список коммитов, например:

pick a1b2c3d Fix bug in query handler
pick d4e5f6g Add logging
pick h7i8j9k Implement new feature
pick l0m1n2o Fix typo in previous commit

Заменяем pick на squash (s) у всех коммитов, кроме первого:

pick a1b2c3d Fix bug in query handler
squash d4e5f6g Add logging
squash h7i8j9k Implement new feature
squash l0m1n2o Fix typo in previous commit

После сохранения Git предложит изменить сообщение коммита, оставляем итоговое.

Затем пушим изменения (если уже был push в удаленный репозиторий, потребуется --force):

git push origin feature/new-feature --force

2. Через GitHub/GitLab UI

При слиянии Pull Request (Merge Request) можно выбрать опцию Squash & Merge:

Вывод

Squash & Merge удобен для поддержания чистоты истории коммитов. Важно применять его осознанно: если детальная история не нужна, squash поможет убрать ненужные коммиты и оставить только финальные изменения.

Варианты размещения конфигурационных файлов GIT

📁 Где Git ищет конфиги (Windows)

Git использует три уровня конфигурации, в жёстко заданном порядке:

Уровень Команда Файл по умолчанию
System git config --system C:\Program Files\Git\etc\gitconfig
Global git config --global %USERPROFILE%\.gitconfig
Local git config --local (по умолчанию) <путь_к_проекту>\.git\config

🔍 Как Git находит C:\Program Files\Git\etc\gitconfig

Git встроенно знает путь к своему системному конфигу:

🧼 Можно ли его изменить?

📌 Нет — стандартный путь etc/gitconfig не переопределяется в переменных окружения.

Однако ты можешь:

  1. Открыть его вручную: 

    notepad "C:\Program Files\Git\etc\gitconfig"

  2. Удалить или закомментировать ненужные строки: 

    [credential] helper = store ; ← закомментировать

⚠️ Требуются права администратора.

✅ Альтернатива: переопределить в глобальной/локальной конфигурации

Если ты не хочешь трогать системный файл, просто переопредели: 

git config --global credential.helper ""

или 

git config --local credential.helper "store --file=.git/.git-credentials"

Git будет использовать наиболее приоритетный из найденных (local > global > system).

Project Access Token (PAT)

🔍 Кто может видеть токен?

👤 Для кого работает Project Access Token?

Токен работает от имени "виртуального пользователя" проекта:

🔐 Он не зависит от логина, под которым ты залогинен в GitLab UI или Git.

🧠 Как узнать, к какому пользователю "привязан" Project Access Token?

❗ Он не привязан к реальному пользователю. Он:

🔐 Кто может использовать этот токен?

Любой, у кого есть:

📌 Поэтому сам токен нужно хранить безопасно, как обычный пароль.

✅ Как использовать:

# Формат для .git-credentials: https://<token_name>:<access_token>@gitlab.example.com
Пример:
https://ci-bot:glpat-abc123@gitlab.example.com/group/project.git

🔐 Вывод:

Вопрос Ответ
Кто видит токен? Только в момент создания — и владельцы с правами Maintainer в проекте
Кому принадлежит? Проекту, не пользователю
Кто может использовать? Любой, у кого есть значение токена
Где отображается? В настройках проекта → Access Tokens
Можно ли узнать, кто создал? Нет, GitLab не отображает автора токена

Замена пользователя и email во всех коммитах

Массовая замена имени и email в истории Git-репозитория

1. Проверить всех авторов и их email

git log --format='%an <%ae>' | sort

Выведет список всех уникальных авторов и их email. Используйте этот список, чтобы убедиться, что все нужные данные попадут под замену.

2. Замена имени и email во всех коммитах (через callback)

python -m git_filter_repo --name-callback "return b'New Name'" --email-callback "return b'new@email.com'" --force

Пример:

python -m git_filter_repo --name-callback "return b'John Doe'" --email-callback "return b'john.doe@example.com'" --force

3. Добавить ссылку на удалённый репозиторий

Данный пункт необходим, т.к. после выполнения git_filter_repo связь с удаленным репозиторием удаляется.

git remote add origin https://github.com/yourname/yourrepo.git

Замените на свой адрес удалённого репозитория.

4. Форсированная отправка истории в удалённый репозиторий

git push --force origin main

Установка git-filter-repo

Через pip (универсально, нужен Python):

pip install git-filter-repo

Через Homebrew (macOS):

brew install git-filter-repo

Проверка установки:

python -m git_filter_repo --help

Если появилась справка — всё готово.

Замена только определённых email/имён через файл mailmap

1. Создать файл my-mailmap.txt со строками замены:

New Name <new@email.com> <old@email1.com>
New Name <new@email.com> <old@email2.com>

2. Выполнить фильтрацию:

python -m git_filter_repo --mailmap my-mailmap.txt --force

Важно!

Удаление и управление тегами в Git

Ниже описаны основные команды для удаления тегов в Git и различия между лёгкими и аннотированными тегами.

Удаление тегов

1. Локальное удаление тега

git tag -d v0.1.0

Что делает

Как это работает “под капотом”

  1. Git хранит теги как файлы в каталоге .git/refs/tags/.
  2. Команда удаляет файл:
   .git/refs/tags/v0.1.0
  1. История коммитов не меняется, просто исчезает локальный указатель v0.1.0.

Пример вывода

$ git tag -d v0.1.0
Deleted tag 'v0.1.0' (was a1b2c3d)

Где a1b2c3d — SHA-1 коммита, на который указывал удалённый тег.

2. Удаление тега на удалённом сервере

git push --delete origin v0.1.0

Что делает

Как это работает “под капотом”

  1. Git преобразует команду в удалённый запрос удаления рефа:
   :refs/tags/v0.1.0
  1. Отправляет запрос на сервер origin, где удаляется файл refs/tags/v0.1.0.
  2. При последующем git fetch или новом клонировании этот тег больше не будет виден.

Пример вывода

$ git push --delete origin v0.1.0
To git@github.com:yourname/your-repo.git
 - [deleted]         v0.1.0

3. Полный сценарий: удаление и перевыпуск тега

# 1. Локально удаляем старый тег
git tag -d v0.1.0

# 2. Удаляем его на удалённом сервере
git push --delete origin v0.1.0

# 3. (Опционально) Создаём новый тег на другом коммите
git tag -a v0.1.0 -m "Release version 0.1.0"

# 4. Пушим новый тег на сервер
git push origin v0.1.0

Типы тегов в Git

В Git существуют два основных вида тегов:

  1. Лёгкие (lightweight) теги
  2. Аннотированные (annotated) теги

Лёгкий тег (git tag v0.1.0)

git tag v0.1.0

Аннотированный тег

git tag -a v0.1.0 -m "Release version 0.1.0"

Сравнительная таблица

Характеристика Лёгкий тег Аннотированный тег
Объект в базе данных Отсутствует Присутствует (тип tag)
Метаданные (автор, дата) Нет Да
Сообщение Нет Да (через -m)
Возможность GPG-подписи Нет Да (ключ -s)
Вывод git show <tag> Показывает сразу коммит Сначала показывает данные тега, затем коммит

Итог