{"id":24623156,"url":"https://github.com/xnngee/my-cheetsheets","last_synced_at":"2026-05-10T14:47:27.047Z","repository":{"id":269724225,"uuid":"905642262","full_name":"xnngee/my-cheetsheets","owner":"xnngee","description":null,"archived":false,"fork":false,"pushed_at":"2025-01-21T15:03:11.000Z","size":86,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-01-21T16:21:54.596Z","etag":null,"topics":["cheetsheet","git","markdown","vim"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/xnngee.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-12-19T08:36:55.000Z","updated_at":"2025-01-21T15:03:15.000Z","dependencies_parsed_at":"2024-12-25T17:17:46.612Z","dependency_job_id":"b2c7c2af-066a-4c59-8aea-d346fc1c6619","html_url":"https://github.com/xnngee/my-cheetsheets","commit_stats":null,"previous_names":["xnngee/my-cheetsheets"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xnngee%2Fmy-cheetsheets","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xnngee%2Fmy-cheetsheets/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xnngee%2Fmy-cheetsheets/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xnngee%2Fmy-cheetsheets/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/xnngee","download_url":"https://codeload.github.com/xnngee/my-cheetsheets/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244339043,"owners_count":20437168,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cheetsheet","git","markdown","vim"],"created_at":"2025-01-25T03:33:48.181Z","updated_at":"2026-05-10T14:47:22.014Z","avatar_url":"https://github.com/xnngee.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# GIT --- Cheet Sheet\n\n[Markdown Cheet Sheet](md.md) \\\n[VIM Cheet Sheet](vim.md)\n\n## Основные команды\n\n### Init (Инициализация)\n\n```\ngit init\n```\n*Инициализация нового локального Git репозитория в текущей директории. Создаётся скрытая папка `.git` с локальным репозиторием, в которой хранятся данные для управления версией проекта.*\n\n### Status (Статус)\n\n```\ngit status\n```\n*Показывает статус рабочего дерева, включая файлы, которые добавлены, изменены или удалены. Полезно для проверки текущего состояния перед созданием коммитов.*\n\n### Log (История коммитов)\n\n```\ngit log\n```\n*Показать историю коммитов в текущей ветке, включая автора, дату и сообщения коммитов.*\n\n```\ngit log --merge\n```\n*Показать историю конфликтов при слиянии веток.*\n\n```\ngit ls-files\n```\n*Показать список файлов в рабочем дереве*\n\n### Reflog (История всех действий)\n\n```\ngit reflog\n```\n*Показать историю всех действий в репозитории, включая создание коммитов, переключение веток и другие операции:*\n\nЭта команда показывает хеши коммитов и временную метку каждой операции. Если коммит не привязан ни к одной ветке, он всё ещё может быть найден в reflog до удаления сборщиком мусора (GC).\n\nЧтобы восстановить Detached commit (коммит не привязанный к ветке), можно переключиться на него или создать ветку, как это показано в [Detached HEAD](#detached-head-(отсоединённый-указатель-head-на-конкретный-коммит)).\n\n### Config (Конфигурация)\n\n```\ngit config\n```\n*Управление конфигурацией Git. Настройки могут быть локальными (для одного репозитория), глобальными (для всех репозиториев в системе, который определяется в файле `~/.gitconfig` в домашней директории пользователя).*\n\n```\ngit config user.name\n```\n*Получить текущее имя пользователя.*\n\n```\ngit config user.email\n```\n*Получить текущий email пользователя.*\n\n```\ngit config --global user.name \"MyName\"\n```\n*Установить глобальное имя пользователя, которое будет использоваться для всех репозиториев.*\n\n```\ngit config --global user.email \"myemail@example.com\"\n```\n*Установить глобальный email пользователя.*\n\n```\ngit config --list\n```\n*Список всех настроек конфигурации.*\n\n```\ncat ~/.gitconfig\n```\n*Просмотр содержимого глобального конфигурационного файла Git.*\n\n### Add (Staging Area, область подготовленных изменений)\n\n**Staging Area** (также называется 'индекс', 'область подготовленных изменений') — это промежуточная область, где фиксируются изменения перед их сохранением в истории репозитория. Она позволяет выбрать, какие изменения войдут в следующий коммит.\n\n**Пример:**\n\n* Изначально файл находится в состоянии **Untracked** (неотслеживаемый), при удалении файла его статус в репозитории становится аналогичным.\n* После выполнения команды `git add` файл становится **Staged** (готовый к коммиту, отслеживаемый).\n* После выполнения команды `git commit` файл переходит в состояние **Commited** (зафиксированный) или **Unmodified** (неизмененный).\n* При внесении изменений в файл он становится **Modified** (изменённый).\n\n```\ngit add\n```\n*Добавить файл в Staging Area для отслеживания изменений.*\n\n```\ngit add .\n# или\ngit add -a\n```\n*Добавить все изменённые файлы в текущем каталоге и подкаталогах.*\n\n```\ngit add \u003cfile\u003e\n```\n*Добавить конкретный файл.*\n\n```\ngit add -p\n```\n*Интерактивно выбрать, какие изменения добавить в Staging Area.*\n\n```\ngit add -a --amend\n```\n*Добавить все новые\\измененные файлы в Staging Area и внести изменения в последний коммит.*\n\n### Commit (Коммит, фиксация изменений)\n\n```\ngit commit\n```\n*Создать коммит с изменениями из Staging Area. Коммит фиксирует состояние проекта в определённый момент времени.*\n\n```\ngit commit -m \"Сообщение коммита\"\n```\n*Создать коммит с сообщением.*\n\n```\ngit commit -m \"commit message\" -m \"additional commit message\"\n```\n*Создать коммит с сообщением и c дополнительным сообщением*\n\n```\ngit commit -am \"Сообщение коммита\"\n```\n*Добавить все изменённые файлы в Staging Area и создать коммит (новые файлы добавлять вручную через `git add`).*\n\n```\ngit commit --amend -m \"commit message\n# or\n--no-edit\n```\n*Изменить последний коммит. Можно обновить сообщение или добавить изменения, которые забыли включить в предыдущий коммит.*\n\nЕсли не указывать флаг `-m` , то сообщение коммита будет изменено во внешнем редакторе (nano\\vim).С флагом `--no-edit` коммит будет изменен с прежним сообщением.\n\n## Ветки и слияние\n\n### Branch (Ветки)\n\n```\ngit branch\n```\n*Показать список локальных веток. Текущая ветка будет помечена звёздочкой (\\*).*\n\n```\ngit branch -a\n```\n*Показать список всех веток (локальные и удалённые).*\n\n```\ngit branch \u003cновая ветка\u003e\n```\n*Создать новую ветку. Эта ветка не будет автоматически переключена. Название ветки может содержать только буквы, цифры, дефисы и символы подчёркивания, но может содержать пробелы.*\n\nCоздания новой ветки не влияет на основную `master` ветку. После разработки новой функциональности на новой ветке, она может быть слита с основной `master` веткой.\n\n```\ngit branch -d \u003cветка\u003e\n```\n*Удалить локальную ветку. До удаления ветки нужно убедиться, что вы не находитесь в этой ветке. Используйте `git branch` для просмотря текущей ветки.*\n\nЕсли попытаться удалить ветку, находясь в ней, Git выдаст ошибку об использовании ветки. Используйте `git log` и `git branch` для проверки, была ли ветка успешно удалена.\n\n**Важное замечание:** При удалении ветки все невлитые коммиты тоже удаляются. Следует удалять ветку только после того, как её изменения были влиты в главную ветку и ветка больше не нужна.\n\n```\ngit branch -vv\n```\n*Показать список веток с информацией об их отслеживании и последнем коммите.*\n\n### Checkout (Переключиться, восстановить)\n\n```\ngit checkout \u003cветка\\коммит\\тег\u003e\n```\n* Переключиться на существующую ветку.*\n\nТакже эта команда позволяет переключиться на другой коммит или тег, откатывает файл к последнему комиту (если указать точку `git checkout .`)\n\nСохраняйте незакоммиченные изменения перед переключением в [Stash](#stash-(сохранение-изменений%2C-тайник)), чтобы не потерять их.\n\n```\ngit checkout -b \u003cновая ветка\u003e\n```\n* Создать новую ветку и переключиться на неё.*\n\n```\ngit checkout --track \u003corigin\\branch\u003e\n```\n* Создать локальную ветку из ветки удаленного репозитория и переключиться на неё.*\n\n### Merge (Слияние веток)\n\nСлияние веток объединяет изменения из одной ветки в другую. Полезно для интеграции новых функций или исправлений.\n\nПеред слиянием ветки - переключитесь на ту ветку в которую нужно слить изменения с помощью команды `git checkout \u003cветка\u003e`. При слиянии ветки X в ветку Y, ветка X не удаляется сама по себе.\n\n```\ngit merge \u003cветка\u003e\n```\n*Слить указанную ветку в текущую. Git попытается автоматически объединить изменения.*\n\n```\ngit merge --abort\n```\n*Отменить слияние, если возникли конфликты.*\n\n### Switch (Переключиться на ветку)\n\n```\ngit switch \u003cветка\u003e\n```\n*Переключиться на другую ветку.*\n\nАльтернатива `git checkout` для работы с ветками. В отличие от `git checkout`, команда `git switch` специализируется только на переключении веток и включает дополнительные проверки безопасности. Например, она автоматически остановит операцию, если обнаружит риск потери несохраненных локальных изменений. Однако с помощью ключа `--detach` можно переключиться на конкретный коммит или тег.\n\n```\ngit switch -c \u003cновая ветка\u003e\n```\n*Создать новую ветку и переключиться на неё.*\n\n```\ngit switch --detach \u003cкоммит\u003e\n```\n*Переключиться на конкретный коммит или тег в режиме Detached HEAD.*\n\n### Tag (Теги)\n\n```\ngit tag\n```\n*Показать список тегов.*\n\n```\ngit tag \u003cимя\u003e\n```\n*Создать новый тег для пометки релиза или значимого состояния.*\n\n### HEAD (Указатель, ссылка на объект фиксации)\n\n**HEAD** — это указатель Git, который показывает на текущий коммит в репозитории. Это тот коммит, от которого будут проходить дальнейшие изменения или коммиты.\n\nПри переключении между ветками командой `git checkout`, HEAD автоматически перемещается на последний коммит выбранной ветки. После внесения изменений в файлы, добавления их в Staging area и создания нового коммита, HEAD обновляется и указывает на этот новый коммит в текущей ветке.\n\n[**Detached HEAD**](#detached-head-(отсоединённый-указатель-head-на-конкретный-коммит)) — состояние указателя HEAD, при котором он ссылается на определённый коммит, а не на ветку. Вы можете перейти к конкретному коммиту, чтобы изучить состояние репозитория в точке этого коммита. HEAD будет указывать на выбранный коммит без привязки к ветке.\n\n**Файл `.git/HEAD`:** Внутри скрытой папки `.git` находится файл HEAD, содержащий сведения о текущем положении HEAD. Используя команды типа `cat .git/HEAD`, можно узнать, на какой коммит или ветку в данный момент указывает HEAD.\n\n**Возвращение к ветке:** Чтобы выйти из состояния Detached HEAD и вернуться к работе с ветками, достаточно выполнить `git checkout` на имя ветки, например, в `master`. Таким образом, HEAD снова будет указывать на последний коммит активной ветки.\n\n### Detached HEAD (Отсоединённый указатель HEAD на конкретный коммит)\n\n**Detached HEAD** — состояние, в котором HEAD указывает на конкретный коммит, а не на ветку.\n\nВ таком состоянии можно внести изменения в уже совершенный коммит. Как воспроизвести это состояние и изменить коммит:\n\n1. Используем `git checkout` с идентификатором коммита, чтобы перейти в режим отсоединённой HEAD.\n2. Вносим необходимые изменения в файлы. Проверьте статус изменений: `git status`\n3. Добавьте изменения в индекс: `git add \u003cfile\u003e`. Создайте новый коммит с изменениями: `git commit -m \"commit message\"`.\n\n    Сохраняем изменения:\n\n    Создайте новую ветку: `git branch \u003cnew-branch-name\u003e`\n\n    Переключитесь на неё: `git switch \u003cnew-branch-name\u003e`\n4. После этого можно слить новую ветку. Переключитьесь в ту ветку в которую нужно слить изменения, например `git switch master`. Соедините изменения из созданной ветки `git merge \u003cnew-branch-name\u003e`. В случае конфликтов:\n\n    Разрешите конфликты вручную в файлах или через редактор (VS Code).\n\n    Добавьте исправленные файлы в индекс `git add \u003cfile\u003e` и завершите слияние `git commit`\n\nРекомендуется просматривать наличие таких коммитов через [`git reflog`](#reflog-(история-всех-действий)).\n\n### Stash (Сохранение изменений, тайник)\n\n**Stash** используется для временного сохранения изменений в рабочем дереве, чтобы вы могли переключиться на другую ветку или выполнить другие операции, не затрагивая текущие изменения. Раньше без этой команды нужно было коммитить изменения, создавать новую ветку, а затем удалить коммит из исходной ветки.\n\n```\ngit stash\n```\n*Сохранить изменения в стек.*\n\n```\ngit stash list\n```\n*Показать список сохранённых изменений.*\n\n```\ngit stash apply\n```\n*Применить последние сохранённые изменения (без удаления из стека).*\n\n```\ngit stash apply stash@{[index]}\n```\n\nПрименить изменения из stash по индексу\n\n```\ngit stash pop\n```\n*Применить изменения и удалить их из стека.*\n\n```\ngit stash clear\n```\n*Удалить все сохранённые изменения.*\n\n## Удаление и откат изменений\n\nУдалить файл можно простым способом, так и альтернативным.\n\n**Простой способ:**\n\n1. Удалить файл с помощью команды `rm -rf \u003cfilename\u003e`, либо через графический интерфейс.\n2. Проверяем что файл\\директория удалены через `git status` и добавляем изменения в Staging area с помощью `git add .`.\n3. Создаем коммит с помощью `git commit -m \"message\"`.\n\n**Альтернативный способ с помощью команды `git rm \u003cfilename\u003e`:**\n\n1. Удалить файл с помощью команды\n```\ngit rm \u003cfilename\u003e\n```\n2. Проверяем что файл\\директория удалены через `git status` или `git ls-files`.\n3. Создаем коммит с помощью `git commit -m \"message\"`.\n\n### Rm (Удаление файлов)\n\n```\ngit rm \u003cфайл\u003e\n```\n*Удалить файл из рабочего дерева и из индекса.*\n\n```\ngit rm --cached \u003cфайл\u003e\n```\n*Удалить файл только из индекса (он останется в рабочем дереве).*\n\n```\ngit rm -r \u003cпапка\u003e\n```\n*Рекурсивно удалить папку и её содержимое.*\n\n```\ngit rm -f \u003cфайл\u003e\n```\n*Удалить файл принудительно.*\n\n### Restore (Откат изменений)\n\n```\ngit restore \u003cфайл\u003e\n```\n*Отменить изменения в файле, вернув его к состоянию последнего коммита. Эта команда является альтернативой команды `git checkout` для отката изменений.*\n\n```\ngit restore --staged \u003cфайл\u003e\n```\n*Убрать файл из Staging Area, оставив изменения в рабочей директории.*\n\n### Clean (Удаление неотслеживаемых файлов)\n\nКоманда `git clean` используется для удаления неотслеживаемых файлов и директорий из рабочего дерева. Неотслеживаемые файлы — это файлы, которые не были добавлены в индекс с помощью `git add` и не были зафиксированы в коммите.\n\nИспользование `git clean -n` (или `-dn`) для предварительного просмотра удаляемых файлов и `git clean -f` (или `-df`) для фактического удаления.\n\nЕще раз: `git clean` удаляет только файлы, не добавленные в индекс (не staged)\n\n```\ngit clean\n```\n*Удалить неотслеживаемые файлы из рабочего дерева.*\n\n```\ngit clean -n\n```\n*Предварительный просмотр файлов, которые будут удалены.*\n\n```\ngit clean -f\n```\n*Удалить неотслеживаемые файлы принудительно.*\n\n```\ngit clean -df\n```\n*Удалить неотслеживаемые файлы и папки принудительно.*\n\n### Reset (Откат изменений)\n\n```\ngit reset\n```\n*Отменить изменения в индексе и/или рабочем дереве.*\n\n```\ngit reset --soft HEAD~1\n```\n*Отменить последний коммит, оставив изменения в индексе.*\n\n```\ngit reset HEAD~1\n```\n*Отменить последний коммит, оставив изменения в рабочем дереве.*\n\n```\ngit reset --hard HEAD~1\n```\n*Полностью удалить последний коммит и все изменения.*\n\n## Типы слияния\n\n### Fast-forward merge (Прямое слияние)\n\n**Fast Forward Merge** -- это тип слияния, который происходит тогда, когда в основной ветке (main/master) нет новых коммитов с момента создания новой ветки. Указатель основной ветки просто перемещается вперёд.\n\n**Подробнее:**\n\n1. Ветка, куда вы хотите выполнить слияние (например, `main`), не содержит новых коммитов после того момента, когда она разошлась с веткой, которую вы сливаете (например, `feature`).\n2. Git просто перемещает указатель текущей ветки (HEAD) на последний коммит целевой ветки, без создания нового коммита слияния. Fast Forward Merge невозможен в том случае, если в основной ветке (`main`\\\\`master`) были новые коммиты после расхождения с новой веткой, то Fast Forward Merge невозможен. Git выполнит обычное слияние с созданием коммита слияния (merge commit).\n\n### Recursive Merge (Рекурсивное слияние)\n\n**Recursive Merge** используется, когда обе ветки (например, `master` и `develop`) содержат изменения, что делает Fast Forward Merge невозможным.\n\nGit объединяет изменения из обеих веток, создавая merge commit (merge branch '\u003cbranch\u003e') - коммит слияния.\n\n```\ngit merge --no-ff \u003cbranch\u003e\n```\n*Принудительное создание merge commit в обход Fast Forwarding Merge происходит с помощью флага `--no-ff`.*\n\nRecursive Merge является стандартным методом, если в обеих ветках есть изменения. При возникновении конфликтов требуется их ручное разрешение.\n\n### Squash Merge (Объединение изменений в один коммит из ветки)\n\n**Squash Merge** используется для объединения нескольких коммитов из ветки в один, чтобы упростить и улучшить читаемость истории изменений, особенно в случае, когда ветка содержит множество изменений, фиксов и пр. Полезно для поддержания чистоты истории.\n\n**Как работает:** Все коммиты из сливаемой ветки объединяются в один перед слиянием:\n```\ngit merge --squash \u003cbranch\u003e\n```\nПосле выполнения `--squash` нужно вручную выполнить коммит:\n```\ngit commit -m \"Объединённые изменения из ветки \u003cbranch\u003e\"\n```\n## Patching (Исправления в репозитории)\n\n### Rebase (Переписывание истории коммитов из одной ветки поверх другой)\n\n**Rebase Merge** переписывает историю коммитов, добавляя изменения из одной ветки поверх другой. Используется, чтобы избежать merge commit’ов и сохранить историю более чистой.\n\n```\ngit rebase \u003cветка\u003e\n```\n*Переместить изменения текущей ветки поверх указанной.*\n\n**Как работает:** Команда `git rebase \u003cbranch\u003e` переносит все коммиты из текущей ветки (например develop, перед этим переключитесь на неё) на вершину указанной ветки (например master), создавая линейную историю.\n\nДалее нужно переключиться на ветку, в которую вы хотите слить изменения: `git switch \u003cbranch\u003e`. Затем выполнить `git merge \u003cbranch\u003e` для слияния изменений.\n\n**Осторожно:** Rebase изменяет историю, поэтому не рекомендуется использовать его для веток, которые уже были опубликованы.\n\n### Cherry-pick (Применение конкретных изменений из другой ветки в текущую ветку)\n\n```\ngit cherry-pick \u003cхеш коммита\u003e\n```\n*Применить изменения из конкретного коммита в текущую ветку.*\n\n## Трекинг файлов\n\n### .gitignore (Игнорирование файлов)\n\nФайл **.gitignore** используется для исключения файлов из отслеживания. В нём указываются файлы или директории, которые Git должен игнорировать.\n\n### .gitkeep (Отслеживание пустых директорий)\n\nДля отслеживания пустых директорий можно создать файл **.gitkeep**. Он не содержит содержимого, но позволяет Git учитывать директорию.\n\n## Удалённые репозитории\n\n### Clone (Клонирование удалённого репозитория)\n```\ngit clone \u003curl\u003e\n```\n*Клонировать удалённый репозиторий.*\n\n### Remote (Добавление удалённого репозитория)\n```\ngit remote add \u003cимя\u003e \u003curl\u003e\n```\n*Добавить удалённый репозиторий.*\n\n```\ngit remote -v\n```\n*Просмотреть список удалённых репозиториев и их URL.*\n\n### Remote tracking branches (Ветки синхронизации между локальным и удалённым репозиториями)\n(local tracking branches -\u003e remote tracking branches -\u003e origin)\n\nRemote Tracking Branch — это промежуточная ветка, которые используются для синхронизации изменений между локальным и удалённым репозиториями. \\\nОблегчает синхронизацию локальных изменений с удаленным репозиторием и наоборот, помогает в разрешении конфликтов и слиянии.\n\n**Процесс отправки изменений в удалённый репозиторий:**\nИмеется локальная мастер ветка (например, `master`) и удалённая ветка (например, `origin/master`). \\\nСоздание Tracking Branch: \\\nПри выполнении команды `git push`, Git создает Tracking Branch (локальное представление удалённого репозитория). \\\nИмена веток слежения имеют вид \u003cremote\u003e/\u003cbranch\u003e. Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master. Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53, при том что у вас может быть своя локальная ветка iss53, удалённая ветка будет представлена веткой слежения с именем origin/iss53\nОтправка изменений: \\\nЧерез Tracking Branch изменения отправляются в удалённый репозиторий (Remote). \\\n\n**Работа с различными ветками:**\nОтправка изменений в новые ветки: Требует явного указания, куда отправить изменения (упоминание о Upstream).\nСимуляция работы в команде: Создание и редактирование новой фича-ветки непосредственно в удаленном репозитории через web interface.\nFetch изменений: Команда git fetch позволяет увидеть новые или измененные ветки в удаленном репозитории.\nВажность Tracking Branch\nTracking Branch выполняет критически важную роль в процессе синхронизации и объединения изменений между локальными и удаленными репозиториями, обеспечивая эффективную командную работу и конфликт-резолюцию.\n\n### Fetch (Получение изменений)\n```\ngit fetch\n```\n*Получить изменения из удалённого репозитория (без слияния).*\n\n### Pull (Получение изменений и слияние)\n```\ngit pull\n```\n*Получить изменения и слить с текущей веткой (эквивалентно `git fetch` + `git merge`).*\n\n### Push (Отправка изменений)\n```\ngit push\n```\n*Отправить изменения в удалённый репозиторий.*\n\n```\ngit push --set-upstream \u003cremote(origin)\u003e \u003cbranch\u003e\n```\n*Отправить изменения и установить связь для отслеживания локальной ветки в удалённом репозитории.*\n\n### Local tracking branches\n(local tracking branches \u003c- remote tracking branches \u003c- origin)\nLocal Tracking Branches - это локальные ветки, связанные с удалёнными ветками, позволяющие отслеживать их изменения для удобного выполнения команд `git pull` и `git push`.\n\nПример использования:\n- При работе с веткой Master, которая связана с Remote Origin Master, команда `git pull` влечёт за собой загрузку изменений из удалённой ветки в локальную. Аналогично, `git push` отправляет изменения из локальной ветки в удалённую.\n- Установление трекинга для ветки происходило автоматически при её создании, если выполняется `git branch` с подробным выводом, можно увидеть, что локальная ветка master уже отслеживает изменения в origin/master.\n\n```\ngit branch --track \u003clocal_branch\u003e \u003cremote_branch\u003e\n```\n*Начать трекинг определённой удалённой ветки - это создает локальную ветку и связывает ее с удалённой веткой.*\n\nПрактический пример:\n- Если нужно отслеживать изменения в удалённой ветке dev/remote, сначала проверяем наличие интересующей удалённой ветки командой `git branch -a`\n- Затем создаём локальную ветку и устанавливаем трекинг через `git branch --track dev/remote origin/dev/remote`.\n- После выполнения этих шагов, любые изменения в origin/dev/remote будут синхронизироваться с локальной веткой dev/remote при выполнении `git pull`.\n\n```\ngit branch --set-upstream-to=\u003corigin/branch-name branch-name\u003e\n```\n*Начать трекинг удаленной ветки с существующей локальной веткой*\n\n### Upstream, Origin (Отслеживаемая ветка, название удаленного репозитория)\n**Upstream** - это отслеживаемая ветка, связанная с удалённой веткой.\n**Origin** - это удаленный репозиторий Git, он может быть назван как угодно, но обычно это просто `origin`.\n\n```\ngit push -u origin master\n```\n*Создание внешней ветки (если не существует) и использование ее в качестве Upstream для отправки изменений*\n\n### Удаление remote branches\nПри попытке удалить удаленную ветку (tracking branch) локально через `git branch -d \u003corigin/branch\u003e\u003e` произойдет ошибка, так как ветка не найдена.\n\n```\ngit branch -d --remote [-r] \u003corigin/branch\u003e\n```\n*Удаление удалённой ветки*\n\nВетка исчезнет из локального списка, но останется в удаленном репозитории. \\\nИспользуйте `git ls-remote` для просмотра списка удаленных веток.\n\nДля удаления ветки во внешнем репозитории используйте: `git push origin --delete \u003cbranch\u003e`. После этого команда `git ls-remote` покажет, что ветка удалена из удаленного репозитория.\n\nУдаление ветки из удаленного репозитория предотвращает доступ других пользователей к этой ветке через репозиторий. \\\nЕсли у кого-то осталась копия ветки локально, он может снова запушить ее изменения, и ветка появится в репозитории заново.\n\n### Force push\nЕсли требуется удалить коммит из истории удаленного репозитория, можно использовать `git reset --hard` для отката на предыдущий коммит локально. \\\nПри повторном выполнении `git pull`, удаленный коммит будет снова загружен, т.к. изменения были только локальными.\n\n```\ngit push \u003cremote\u003e \u003cbranch\u003e --force\n```\n*Принудительная отправка изменений в удалённый репозиторий*\n\nПри попытке выполнить `git push` после отката, Git может выдать ошибку о расхождении версий. \\\n`git push --force` позволяет переписать историю в удаленном репозитории, но это должно делаться с крайней осторожностью, чтобы не потерять изменения, внесенные другими пользователями. \\\nСуществует риск перезаписи изменений других участников команды, что может привести к потере данных. \\\nВажно убедиться, что в удаленном репозитории нет новых коммитов от других участников перед выполнением force push.\n\nПри необходимости исправить недавний коммит (например, изменить сообщение или добавить забытые изменения), можно использовать команды типа `git commit --amend`, за которым следует `git push --force`. \\\nТем не менее, следует проверить, не было ли новых изменений в удаленном репозитории, чтобы не перезаписать их.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxnngee%2Fmy-cheetsheets","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fxnngee%2Fmy-cheetsheets","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxnngee%2Fmy-cheetsheets/lists"}