{"id":19608559,"url":"https://github.com/andreiextr/git_commands","last_synced_at":"2026-02-11T12:34:15.985Z","repository":{"id":192034178,"uuid":"685921961","full_name":"AndreiExtr/Git_commands","owner":"AndreiExtr","description":"Cheat sheet on Git console commands","archived":false,"fork":false,"pushed_at":"2024-11-06T19:35:37.000Z","size":74,"stargazers_count":0,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-08-27T21:03:16.434Z","etag":null,"topics":["git-commands"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"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/AndreiExtr.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":"2023-09-01T10:16:10.000Z","updated_at":"2023-09-01T11:37:57.000Z","dependencies_parsed_at":"2025-01-09T09:48:44.335Z","dependency_job_id":"bca1bd55-e4fd-415c-951f-c0d65094a134","html_url":"https://github.com/AndreiExtr/Git_commands","commit_stats":null,"previous_names":["andreiextr/git_commands"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/AndreiExtr/Git_commands","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AndreiExtr%2FGit_commands","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AndreiExtr%2FGit_commands/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AndreiExtr%2FGit_commands/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AndreiExtr%2FGit_commands/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AndreiExtr","download_url":"https://codeload.github.com/AndreiExtr/Git_commands/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AndreiExtr%2FGit_commands/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29333049,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-11T06:13:03.264Z","status":"ssl_error","status_checked_at":"2026-02-11T06:12:55.843Z","response_time":97,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"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":["git-commands"],"created_at":"2024-11-11T10:15:45.244Z","updated_at":"2026-02-11T12:34:15.950Z","avatar_url":"https://github.com/AndreiExtr.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Git_commands\nШпаргалка по консольным командам Git\n\u003c!-- \n*   [Общее](https://github.com/cyberspacedk/Git-commands/tree/master/git#Общее)\n*   [Консольные команды](https://github.com/cyberspacedk/Git-commands/tree/master/git#Консольные-команды)\n*   [Примеры реальной работы](https://github.com/cyberspacedk/Git-commands/tree/master/git#Примеры) --\u003e\n\n\n\n## Общее\n\nGit — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). **Важно**: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс (`git add`), потом «сохраняем» (`git commit`).\n\nЛюбой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).\n\nОтслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).\n\n### Ключ к пониманию\n\nКлюч к пониманию концепции git — знание о «трех деревьях»:\n\n- Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).\n- Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).\n- Директория `.git/` — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).\n\nКоммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.\n\nУ всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.\n\n### Простейший цикл работ\n\n- Редактирование, добавление, удаление файлов (собственно, работа).\n- Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).\n- Коммит (фиксация изменений).\n- Возврат к шагу 1 или отход ко сну.\n\n### Указатели\n\n- `HEAD` — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.\n- `ORIG_HEAD` — указатель на коммит, с которого вы только что переместили `HEAD` (командой `git reset ...`, например).\n- Ветка (`master`, `develop` etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.\n- Теги — простые указатели на коммиты. Не перемещаются.\n\n\n\n### Настройки\n\nПеред началом работы нужно выполнить некоторые настройки:\n\n```\ngit config --global user.name \"Your Name\" # указать имя, которым будут подписаны коммиты\ngit config --global user.email \"e@w.com\"  # указать электропочту, которая будет в описании коммитера\n```\n\nЕсли вы в Windows:\n\n```\ngit config --global core.autocrlf true # включить преобразование окончаний строк из CRLF в LF\n```\n\n\n### Указание неотслеживаемых файлов\n\nФайлы и директории, которые не нужно включать в репозиторий, указываются в файле `.gitignore`. Обычно это устанавливаемые зависимости (`node_modules/`, `bower_components/`), готовая сборка `build/` или `dist/` и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, [возможно использование шаблонов](http://git-scm.com/book/ru/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%97%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B9-%D0%B2-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%B9#Игнорирование-файлов).\n\n\n### Консоль\n\n[Как использовать консоль Bash в Windows, основные команды](https://github.com/cyberspacedk/BASH-Commands).\n\n\n### Длинный вывод в консоли: Vim\n\nВызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой `git log -p fileName.txt`). При этом прямо в консоли запускается редактор [Vim](https://ru.wikipedia.org/wiki/Vim). Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести \u003ckbd\u003e:q\u003c/kbd\u003e. Переход в командный режим из любого другого: \u003ckbd\u003eEsc\u003c/kbd\u003e.\n\nЕсли нужно что-то написать, нажмите \u003ckbd\u003ei\u003c/kbd\u003e — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите \u003ckbd\u003e:w\u003c/kbd\u003e.\n\n# Vim (некоторые команды)\n\n```bash\n# Нажатия кнопок\nESC     — переход в командный режим\ni       — переход в режим редактирования текста\nZQ (зажат Shift, поочередное нажатие) — выход без сохранения\nZZ (зажат Shift, поочередное нажатие) — сохранить и выйти\n```bash\n# Нажатия кнопок\nESC     — переход в командный режим\ni       — переход в режим редактирования текста\nZQ (зажат Shift, поочередное нажатие) — выход без сохранения\nZZ (зажат Shift, поочередное нажатие) — сохранить и выйти\n\n# Ввод в командном режиме\n:q!             — выйти без сохранения\n:wq             — сохранить файл и выйти\n:w filename.txt — сохранить файл как filename.txt\n\n```\n\n\n## Консольные команды\n\n### Создать новый репозиторий\n\n``` bash\ngit init             # создать новый проект в текущей директории\ngit init folder-name # создать новый проект в указанной директории\n```\n\n\n### Клонирование репозитория\n\n``` bash\n# клонировать удаленный репозиторий в одноименную директорию\ngit clone https://github.com/cyberspacedk/Git-commands.git    \n\n# клонировать удаленный репозиторий в директорию «FolderName»\ngit clone https://github.com/cyberspacedk/Git-commands.git FolderName \n\n# клонировать репозиторий в текущую директорию\ngit clone https://github.com:nicothin/web-design.git .           \n```\n\n\n### Просмотр изменений\n\n``` bash\ngit status              # показать состояние репозитория (отслеживаемые, изменённые, новые файлы и пр.)\ngit diff                # сравнить рабочую директорию и индекс (неотслеживаемые файлы ИГНОРИРУЮТСЯ)\ngit diff --color-words  # сравнить рабочую директорию и индекс, показать отличия в словах (неотслеживаемые файлы ИГНОРИРУЮТСЯ)\ngit diff index.html     # сравнить файл из рабочей директории и индекс\ngit diff HEAD           # сравнить рабочую директорию и коммит, на который указывает HEAD (неотслеживаемые файлы ИГНОРИРУЮТСЯ)\ngit diff --staged       # сравнить индекс и коммит с HEAD\ngit diff master feature # посмотреть что сделано в ветке feature по сравнению с веткой master\ngit diff --name-only master feature # посмотреть что сделано в ветке feature по сравнению с веткой master, показать только имена файлов\ngit diff master...feature # посмотреть что сделано в ветке feature с момента (коммита) расхождения с master\n```\n\n\n### Добавление изменений в индекс\n\n``` bash\ngit add .        # добавить в индекс все новые, изменённые, удалённые файлы из текущей директории и её поддиректорий\ngit add text.txt # добавить в индекс указанный файл (был изменён, был удалён или это новый файл)\ngit add -i       # запустить интерактивную оболочку для добавления в индекс только выбранных файлов\ngit add -p       # показать новые/изменённые файлы по очереди с указанием их изменений и вопросом об отслеживании/индексировании\n```\n\n\n### Удаление изменений из индекса\n\n``` bash\ngit reset            # убрать из индекса все добавленные в него изменения (в рабочей директории все изменения сохранятся), антипод git add\ngit reset readme.txt # убрать из индекса изменения указанного файла (в рабочей директории изменения сохранятся)\n```\n\n\n### Отмена изменений\n\n``` bash\ngit checkout text.txt      # ОПАСНО: отменить изменения в файле, вернуть состояние файла, имеющееся в индексе\ngit reset --hard           # ОПАСНО: отменить изменения; вернуть то, что в коммите, на который указывает HEAD (незакомиченные изменения удалены из индекса и из рабочей директории, неотслеживаемые файлы останутся на месте)\ngit clean -df              # удалить неотслеживаемые файлы и директории\n```\n\n\n### Коммиты\n\n``` bash\ngit commit -m \"Name of commit\"    # зафиксировать в коммите проиндексированные изменения (закоммитить), добавить сообщение\ngit commit -a -m \"Name of commit\" # проиндексировать отслеживаемые файлы (ТОЛЬКО отслеживаемые, но НЕ новые файлы) и закоммитить, добавить сообщение\n```\n\n\n### Отмена коммитов и перемещение по истории\n\nВсе коммиты, которые уже были отправлены в удалённый репозиторий, должны отменяться новыми коммитами (`git revert`), дабы избежать проблем с историей разработки у других участников проекта.\n\n``` bash\ngit revert HEAD --no-edit    # создать новый коммит, отменяющий изменения последнего коммита без запуска редактора сообщения\ngit revert b9533bb --no-edit # то же, но отменяются изменения, внесённые коммитом с указанным хешем (b9533bb)\n```\n\n**Все команды, приведённые ниже можно выполнять ТОЛЬКО если коммиты еще не были отправлены в удалённый репозиторий.**\n\n``` bash\n# ВНИМАНИЕ! Опасные команды, можно потерять незакоммиченные изменения\ngit commit --amend -m \"Название\"  # «перекоммитить» изменения последнего коммита, заменить его новым коммитом с другим сообщением (сдвинуть текущую ветку на один коммит назад, сохранив рабочую директорию и индекс «как есть», создать новый коммит с данными из «отменяемого» коммита, но новым сообщением)\ngit reset --hard @~      # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию и индекс сделать такими, какими они были в момент предыдущего коммита\ngit reset --hard 75e2d51 # передвинуть HEAD (и ветку) на коммит с указанным хешем, рабочую директорию и индекс сделать такими, какими они были в момент указанного коммита\ngit reset --soft @~      # передвинуть HEAD (и ветку) на предыдущий коммит, но в рабочей директории и индексе оставить все изменения\ngit reset --soft @~2     # то же, но передвинуть HEAD (и ветку) на 2 коммита назад\ngit reset @~             # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию оставить как есть, индекс сделать таким, каким он был в момент предыдущего коммита (удобнее, чем git reset --soft @~, если индекс нужно задать заново)\n# Почти как git reset --hard, но безопаснее: не получится потерять изменения в рабочей директории\ngit reset --keep @~      # передвинуть HEAD (и ветку) на предыдущий коммит, сбросить индекс, но в рабочей директории оставить изменения, если возможно (если файл с изменениями между коммитами менялся, будет выдана ошибка и переключение не произойдёт)\n```\n\n\n### Временно переключиться на другой коммит\n\n``` bash\ngit checkout b9533bb # переключиться на коммит с указанным хешем (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита)\ngit checkout master  # переключиться на коммит, на который указывает master (переместить HEAD на коммит, на который указывает master, рабочую директорию вернуть к состоянию на момент этого коммита)\n```\n\n\n### Переключиться на другой коммит и продолжить работу с него\n\nПотребуется создание новой ветки, начинающейся с указанного коммита.\n\n``` bash\ngit checkout -b new-branch 5589877   # создать ветку new-branch, начинающуюся с коммита c хешем 5589877 (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита, создать указатель на этот коммит (ветку) с указанным именем)\n```\n\n\n### Восстановление изменений\n\n``` bash\ngit checkout 5589877 index.html  # восстановить в рабочей директории указанный файл на момент указанного коммита (и добавить это изменение в индекс) (git reset index.html для удаления из индекса, но сохранения изменений в файле)\n```\n\n\n### Копирование коммита (перенос коммитов)\n\n``` bash\ngit cherry-pick 5589877          # скопировать на активную ветку изменения из указанного коммита, закоммитить эти изменения\ngit cherry-pick master~2..master # скопировать на активную ветку изменения из master (2 последних коммита)\ngit cherry-pick -n 5589877       # скопировать на активную ветку изменения из указанного коммита, но НЕ КОММИТИТЬ (подразумевается, что мы сами потом закоммитим)\ngit cherry-pick master..feature  # скопировать на активную ветку изменения из всех коммитов ветки feature с момента её расхождения с master (похоже на слияние веток, но это копирование изменений, а не слияние), закоммитить эти изменения; это может вызвать конфликт\ngit cherry-pick --abort    # прервать конфликтный перенос коммитов\ngit cherry-pick --continue # продолжить конфликтный перенос коммитов (сработает только после решения конфликта)\n```\n\n\n### Удаление файла\n\n``` bash\ngit rm text.txt    # удалить отслеживаемый неизменённый файл и проиндексировать это изменение\ngit rm -f text.txt # удалить отслеживаемый изменённый файл и проиндексировать это изменение\ngit rm -r log/     # удалить всё содержимое отслеживаемой директории log/ и проиндексировать это изменение\ngit rm ind*        # удалить все отслеживаемые файлы с именем, начинающимся на «ind» в текущей директории и проиндексировать это изменение\ngit rm --cached readme.txt # удалить из отслеживаемых индексированный файл (ФАЙЛ ОСТАНЕТСЯ НА МЕСТЕ) (часто используется для нечаянно добавленных в отслеживаемые файлов)\n```\n\n\n### Перемещение/переименование файлов\n\nДля git не существует переименования. Переименование воспринимается как удаление старого файла и создание нового. Факт переименования может быть определен только после индексации изменения.\n\n``` bash\ngit mv text.txt test_new.txt # переименовать файл «text.txt» в «test_new.txt» и проиндексировать это изменение\ngit mv readme_new.md folder/ # переместить файл readme_new.md в директорию folder/ (должна существовать) и проиндексировать это изменение\n```\n\n\n### История коммитов\n\nВыход из длинного лога вывода: `q`.\n\n``` bash\ngit log master             # показать коммиты в указанной ветке\ngit log -2                 # показать последние 2 коммита в активной ветке\ngit log -2 --stat          # показать последние 2 коммита и статистику внесенных ими изменений\ngit log -p -22             # показать последние 22 коммита и внесенную ими разницу на уровне строк\ngit log --graph -10        # показать последние 10 коммитов с ASCII-представлением ветвления\ngit log --since=2.weeks    # показать коммиты за последние 2 недели\ngit log --after '2018-06-30' # показать коммиты, сделанные после указанной даты\ngit log index.html         # показать историю изменений файла index.html (только коммиты)\ngit log -5 index.html      # показать историю изменений файла index.html, последние 5 коммитов (только коммиты)\ngit log -p index.html      # показать историю изменений файла index.html (коммиты и изменения)\ngit log -G'myFunction' -p  # показать все коммиты, в которых менялись строки с myFunction (в кавычках регулярное выражение)\ngit log -L '/\u003chead\u003e/','/\u003c\\/head\u003e/':index.html # показать изменения от указанного до указанного регулярных выражений в указанном файле\ngit log --grep fix         # показать коммиты, в описании которых есть буквосочетание fix (регистрозависимо, только коммиты текущей ветки)\ngit log --grep fix -i      # показать коммиты, в описании которых есть буквосочетание fix (регистроНЕзависимо, только коммиты текущей ветки)\ngit log --grep 'fix(ing|me)' -P # показать коммиты, в описании которых есть совпадения для регулярного выражения (только коммиты текущей ветки)\ngit log --pretty=format:\"%h - %an, %ar : %s\" -4 # показать последние 4 коммита с форматированием выводимых данных\ngit log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short # мой формат вывода, висящий на алиасе оболочки\ngit log master..branch_99  # показать коммиты из ветки branch_99, которые не влиты в master\ngit log branch_99..master  # показать коммиты из ветки master, которые не влиты в branch_99\ngit log master...branch_99 --boundary -- graph # показать коммиты из указанных веток, начиная с их расхождения (коммит расхождения будет показан)\n```\n\n``` bash\ngit show 60d6582           # показать изменения из коммита с указанным хешем\ngit show HEAD~             # показать данные о предыдущем коммите в активной ветке\ngit show @~                # аналогично предыдущему\ngit show HEAD~3            # показать данные о коммите, который был 3 коммита назад\ngit show my_branch~2       # показать данные о коммите, который был 2 коммита назад в указанной ветке\ngit show @~:index.html     # показать контент указанного файла на момент предыдущего (от HEAD) коммита\ngit show :/\"подвал\"        # показать самый новый коммит, в описании которого есть указанное слово (из любой ветки)\n```\n\n\n### Кто написал строку\n\n``` bash\ngit blame README.md --date=short -L 5,8 # показать строки 5-8 указанного файла и коммиты, в которых строки были добавлены\n```\n\n\n### История изменений указателей (веток, HEAD)\n\n```\ngit reflog -20             # показать последние 20 изменений положения указателя HEAD\ngit reflog --format='%C(auto)%h %\u003c|(20)%gd %C(blue)%cr%C(reset) %gs (%s)' -20 # то же, но с указанием давности действий\n```\n\n\n### Ветки\n\n``` bash\ngit branch                 # показать список веток\ngit branch -v              # показать список веток и последний коммит в каждой\ngit branch new_branch      # создать новую ветку с указанным именем на текущем коммите\ngit branch new_branch 5589877 # создать новую ветку с указанным именем на указанном коммите\ngit branch -f master 5589877  # переместить ветку master на указанный коммит\ngit branch -f master master~2 # переместить ветку master на 2 коммита назад\ngit checkout new_branch    # перейти в указанную ветку\ngit checkout -b new_branch # создать новую ветку с указанным именем и перейти в неё\ngit checkout -B master 5589877 # переместить ветку с указанным именем на указанный коммит и перейти в неё\ngit merge hotfix           # влить в ветку, в которой находимся, данные из ветки hotfix\ngit merge hotfix -m \"Горячая правка\" # влить в ветку, в которой находимся, данные из ветки hotfix (указано сообщение коммита слияния)\ngit merge hotfix --log     # влить в ветку, в которой находимся, данные из ветки hotfix, показать редактор описания коммита, добавить в него сообщения вливаемых коммитов\ngit merge hotfix --no-ff   # влить в ветку, в которой находимся, данные из ветки hotfix, запретить простой сдвиг указателя, изменения из hotfix «останутся» в ней, а в активной ветке появится только коммит слияния\ngit branch -d hotfix       # удалить ветку hotfix (используется, если её изменения уже влиты в главную ветку)\ngit branch --merged        # показать ветки, уже слитые с активной\ngit branch --no-merged     # показать ветки, не слитые с активной\ngit branch -a              # показать все имеющиеся ветки (в т.ч. на удаленных репозиториях)\ngit branch -m old_branch_name new_branch_name # переименовать локально ветку old_branch_name в new_branch_name\ngit branch -m new_branch_name # переименовать локально ТЕКУЩУЮ ветку в new_branch_name\ngit push origin :old_branch_name new_branch_name # применить переименование в удаленном репозитории\ngit branch --unset-upstream # завершить процесс переименования\n```\n\n\n### Теги\n\n``` bash\ngit tag v1.0.0               # создать тег с указанным именем на коммите, на который указывает HEAD\ngit tag -a -m 'В продакшен!' v1.0.1 master # создать тег с описанием на том коммите, на который смотрит ветка master\ngit tag -d v1.0.0            # удалить тег с указанным именем(ами)\ngit tag -n                   # показать все теги, и по 1 строке сообщения коммитов, на которые они указывают\ngit tag -n -l 'v1.*'         # показать все теги, которые начинаются с 'v1.*'\n```\n\n\n### Временное сохранение изменений без коммита\n\n``` bash\ngit stash     # временно сохранить незакоммиченные изменения и убрать их из рабочей директории\ngit stash pop # вернуть сохраненные командой git stash изменения в рабочую директорию\n```\n\n\n### Удалённые репозитории\n\nЕсть два распространённых способа привязать удалённый репозиторий к локальному: по HTTPS и по SSH. Если SSH у вас не настроен (или вы не знаете что это), привязывайте удалённый репозиторий по HTTPS (адрес привязываемого репозитория должен начинаться с https://).\n\n``` bash\ngit remote -v              # показать список удалённых репозиториев, связанных с локальным\ngit remote remove origin   # убрать привязку удалённого репозитория с сокр. именем origin\ngit remote add origin https://github.com:nicothin/test.git # добавить удалённый репозиторий (с сокр. именем origin) с указанным URL\ngit remote rm origin       # удалить привязку удалённого репозитория\ngit remote show origin     # получить данные об удалённом репозитории с сокращенным именем origin\ngit fetch origin           # скачать все ветки с удаленного репозитория (с сокр. именем origin), но не сливать со своими ветками\ngit fetch origin master    # то же, но скачивается только указанная ветка\ngit checkout --track origin/github_branch # создать локальную ветку github_branch (данные взять из удалённого репозитория с сокр. именем origin, ветка github_branch) и переключиться на неё\ngit push origin master     # отправить в удалённый репозиторий (с сокр. именем origin) данные своей ветки master\ngit pull origin            # влить изменения с удалённого репозитория (все ветки)\ngit pull origin master     # влить изменения с удалённого репозитория (только указанная ветка)\n```\n\n\n### Конфликт слияния\n\nПредполагается ситуация: есть ветка `master` и есть ветка `feature`. В обеих ветках есть коммиты, сделанные после расхождения веток. В ветку `master` пытаемся влить ветку `feature` (`git merge feature`), получаем конфликт, т.к. в обеих ветках есть изменения одной и той же строки в файле `index.html`.\n\nПри возникновении конфликта, репозиторий находится в состоянии прерванного слияния. Нужно оставить в конфликтующих местах файлов только нужный код, проиндексировать изменения и закоммитить.\n\n``` bash\ngit merge feature                # влить в активную ветку изменения из ветки feature\ngit merge-base master feature    # показать хеш последнего общего коммита для двух указанных веток\ngit checkout --ours index.html   # оставить в конфликтном файле (index.html) состояние ветки, В КОТОРУЮ мы вливаем (в примере — из ветки master)\ngit checkout --theirs index.html # оставить в конфликтном файле (index.html) состояние ветки, ИЗ КОТОРОЙ мы вливаем (в примере — из ветки feature)\ngit checkout --merge index.html  # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток (для ручного редактирования)\ngit checkout --conflict=diff3  --merge index.html # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток плюс то, что было в месте конфликта в коммите, на котором разошлись сливаемые ветки\n```\n\n``` bash\ngit reset --hard  # прекратить это прерванное слияние, вернуть рабочую директорию и индекс как было в момент коммита, на который указывает HEAD, а я пойду немного поплачу\ngit reset --merge # прекратить это прерванное слияние, но оставить изменения, не закоммиченные до слияния (для случая, когда слияние делается не на чистом статусе)\ngit reset --abort # то же, что и строкой выше\n```\n\n\n### «Перенос» ветки\n\nМожно «переместить» ответвление какой-либо ветки от основной на произвольный коммит. Это нужно для того, чтобы в «переносимой» ветке появились какие-либо изменения, внесённые в основной ветке (уже после ответвления переносимой).\n\nНельзя «переносить» ветку, если она уже отправлена на удалённый репозиторий.\n\n``` bash\ngit rebase master # перенести все коммиты (создать их копии) активной ветки так, будто активная ветка ответвилась от master на нынешней вершине master (часто вызывает конфликты)\ngit rebase --onto master feature # перенести коммиты активной ветки на master, начиная с того места, в котором активная ветка отделилась от ветки feature\ngit rebase --abort # прервать конфликтный rebase, вернуть рабочую директорию и индекс к состоянию до начала rebase\ngit rebase --continue # продолжить конфликтный rebase (сработает только после разрешения конфликта и индексации такого разрешения)\n```\n\n#### Как отменить rebase\n\n``` bash\ngit reflog feature -2        # смотрим лог перемещений ветки, которой делали rebase (в этом примере — feature), видим последний коммит ПЕРЕД rebase, на него и нужно перенести указатель ветки\ngit reset --hard feature@{1} # переместить указатель ветки feature на один коммит назад, обновить рабочую директорию и индекс\n```\n\n\n### Разное\n\n``` bash\ngit archive -o ./project.zip HEAD # создать архив с файловой структурой проекта по указанному пути (состояние репозитория, соответствующее указателю HEAD)\n```\n\n\n\n\n\n## Примеры\n\nСобираем коллекцию простых и сложных примеров работы.\n\n\n### Начало работы\n\nСоздание нового репозитория, первый коммит, привязка удалённого репозитория с gthub.com, отправка изменений в удалённый репозиторий.\n\n``` bash\n# указана последовательность действий:\n# создана директория проекта, мы в ней\ngit init                      # создаём репозиторий в этой директории\ntouch readme.md               # создаем файл readme.md\ngit add readme.md             # добавляем файл в индекс\ngit commit -m \"Старт\"         # создаем коммит\ngit remote add origin https://github.com:nicothin/test.git # добавляем предварительно созданный пустой удаленный репозиторий\ngit push -u origin master     # отправляем данные из локального репозитория в удаленный (в ветку master)\n```\n\n\n### «Внесение изменений» в коммит\n\nТолько если коммит ещё не был отправлен в удалённые репозиторий.\n\n``` bash\n# указана последовательность действий:\nsubl inc/header.html          # редактируем и сохраняем разметку «шапки»\ngit add inc/header.html       # индексируем измененный файл\ngit commit -m \"Убрал телефон из шапки\" # делаем коммит\n# ВНИМАНИЕ: коммит пока не был отправлен в удалённый репозиторий\n# сознаём, что нужно было еще что-то сделать в этом коммите.\nsubl inc/header.html          # вносим изменения\ngit add inc/header.html       # индексируем измененный файл (можно git add .)\ngit commit --amend -m \"«Шапка»: выполнена задача №34\" # заново делаем коммит\n```\n\n\n### Работа с ветками\n\nЕсть master (публичная версия сайта), выполняем масштабную задачу (переверстать «шапку»), но по ходу работ возникает необходимость подправить критичный баг (неправильно указан контакт в «подвале»).\n\n``` bash\n# указана последовательность действий:\ngit checkout -b new-page-header # создадим новую ветку для задачи изменения «шапки» и перейдём в неё\nsubl inc/header.html            # редактируем разметку «шапки»\ngit commit -a -m \"Новая шапка: смена логотипа\" # делаем коммит (работа еще не завершена)\n# тут выясняется, что есть баг с контактом в «подвале»\ngit checkout master             # возвращаемся к ветке master\nsubl inc/footer.html            # устраняем баг и сохраняем разметку «подвала»\ngit commit -a -m \"Исправление контакта в подвале\" # делаем коммит\ngit push                        # отправляем коммит с быстрым критическим изменением в master в удалённом репозитории\ngit checkout new-page-header    # переключаемся обратно в ветку new-page-header для продолжения работ над «шапкой»\nsubl inc/header.html            # редактируем и сохраняем разметку «шапки»\ngit commit -a -m \"Новая шапка: смена навигации\" # делаем коммит (работа над «шапкой» завершена)\ngit checkout master             # переключаемся в ветку master\ngit merge new-page-header       # вливаем в master изменения из ветки new-page-header\ngit branch -d new-page-header   # удаляем ветку new_page_header\n```\n\n\n### Работа с ветками, слияние и откат к состоянию до слияния\n\nБыла ветка `fix`, в которой исправляли баг. Исправили, влили `fix` в `master`. но тут выяснилось, что это исправление ломает какую-то функциональность, Нужно откатить `master` к состоянию без слияния (наличие бага менее критично, чем порча функциональности).\n\n``` bash\n# находимся в ветке fix, баг уже «исправлен»\ngit checkout master            # переключаемся на master\ngit merge fix                  # вливаем изменения из fix в master\n# видим проблему: часть функциональности сломалась\ngit checkout fix               # переключаемся на fix (пока мы в master, git не даст ее двигать)\ngit branch -f master ORIG_HEAD # передвигаем ветку master на коммит, указанный в ORIG_HEAD (тот, на который указывала master до вливания fix)\n```\n\n\n\n### Работа с ветками, конфликт слияния\n\nЕсть ветка `master` (публичная версия сайта), в двух параллельных ветках (`branch-1` и `branch-2`) было отредактировано одно и то же место одного и того же файла, первую ветку (`branch-1`) влили в master, попытка влить вторую вызывает конфликт.\n\n``` bash\n# указана последовательность действий:\ngit checkout master           # переключаемся на ветку master\ngit checkout -b branch-1      # создаём ветку branch-1, основанную на ветке master\nsubl .                        # редактируем и сохраняем файлы\ngit commit -a -m \"Правка 1\"   # коммитим\ngit checkout master           # возвращаемся к ветке master\ngit checkout -b branch-2      # создаём ветку branch-2, основанную на ветке master\nsubl .                        # редактируем и сохраняем файлы\ngit commit -a -m \"Правка 2\"   # коммитим\ngit checkout master           # возвращаемся к ветке master\ngit merge branch-1            # вливаем изменения из ветки branch-1 в текущую ветку (master), удача (автослияние)\ngit merge branch-2            # вливаем изменения из ветки branch-2 в текущую ветку (master), КОНФЛИКТ автослияния\n# Automatic merge failed; fix conflicts and then commit the result.\nsubl .                        # выбираем в конфликтных файлах те участки, которые нужно оставить, сохраняем\ngit commit -a -m \"Устранение конфликта\" # коммитим результат устранения конфликта\n```\n\n\n\n### Синхронизация репозитория-форка с мастер-репозиторием\n\nЕсть некий репозиторий на github.com, он него нами был сделан форк, добавлены какие-то изменения. Оригинальный (мастер-)репозиторий был как-то обновлён. Задача: стянуть с мастер-репозитория изменения (которые там внесены уже после того, как мы его форкнули).\n\n``` bash\n# указана последовательность действий:\ngit remote add upstream https://github.com:address.git # добавляем удаленный репозиторий: сокр. имя — upstream, URL мастер-репозитория\ngit fetch upstream            # стягиваем все ветки мастер-репозитория, но пока не сливаем со своими\ngit checkout master           # переключаемся на ветку master своего репозитория\ngit merge upstream/master     # вливаем стянутую ветку master удалённого репозитория upstream в свою ветку master\n```\n\n\n\n### Ошибка в работе: закоммитили в мастер, но поняли, что нужно было коммитить в новую ветку\n\n**ВАЖНО: это сработает только если коммит еще не отправлен в удалённый репозиторий.**\n\n``` bash\n# указана последовательность действий:\n# сделали изменения, проиндексировали их, закоммитили в master, но ЕЩЁ НЕ ОТПРАВИЛИ (не делали git push)\ngit checkout -b new-branch    # создаём новую вертку из master\ngit checkout master           # переключаемся на master\ngit reset HEAD~ --hard        # сдвигаем указатель (ветку) master на 1 коммит назад\ngit checkout new-branch       # переключаемся обратно на новую ветку для продолжения работы\n```\n\n\n\n### Нужно вернуть содержимое файла к состоянию, бывшему в каком-либо коммите (известен хеш коммита)\n\n``` bash\n# указана последовательность действий:\ngit checkout f26ed88 -- index.html # восстановить в рабочей директории состояние указанного файла на момент указанного коммита, добавить это изменение в индекс\ngit commit -am \"Navigation fixs\"   # сделать коммит\n```\n\n\n\n### При любом действии с github (или другим удалённым сервисом) запрашивается логин и пароль\n\nРечь именно о запросе пары логин + пароль, а не ключевой фразы. Происходит это потому, что git по умолчанию не сохранит пароль для доступа к репозиторию по HTTPS.\n\nПростое решение: [указать git кешировать ваш пароль](https://help.github.com/articles/caching-your-github-password-in-git/).\n\n\n\n## `.gitattributes`\n\n```\n* text=auto\n\n*.html diff=html\n*.css  diff=css\n*.scss diff=css\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fandreiextr%2Fgit_commands","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fandreiextr%2Fgit_commands","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fandreiextr%2Fgit_commands/lists"}