Работа с Гитхаб (последовательное описание команд) / Working with github (sequential description of commands)
- Флаг — добавочная команда, которая пишется сразу следом за основной с проставлением перед ней - или --. Например:
git commit -m, гдеgit commit— основная команда,-m— флаг.
.gitignore — в этот файл вносятся папки и файлы, которые нужно игнорировать и не закачивать в репозиторий
Пример написания:
# Папки (Folders):
/node_modules
/.pnp
/_site
/dist
.git
# Файлы (Files):
desktop.ini
# Исключение по расширению (Exclusion by extension):
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local
.pnp.js
# Исключение по имени (Exception by name), звёздочка * означает "любые символы после этой части имени":
npm-debug*
yarn-debug*
yarn-error*
Команда git init — это основа для начала работы с Git. Она создаёт новый локальный репозиторий в текущей директории, позволяя Git отслеживать изменения в вашем проекте.
Вот подробное объяснение:
-
Создаёт скрытую папку .git в текущей директории. В ней хранится вся история коммитов, ветки, настройки и служебные данные Git. Без этой папки Git не работает в проекте.
-
Инициализирует пустой репозиторий, готовый к отслеживанию файлов.
Команда git status — это одна из основных команд Git, которая показывает текущее состояние рабочей директории и индекса (staging area). Она помогает понять:
- Какие файлы изменены, но не добавлены в индекс
- Какие файлы добавлены в индекс и готовы к коммиту
- Есть ли новые/удалённые файлы, которые Git ещё не отслеживает
- Состояние текущей ветки (актуальна ли она относительно удалённого репозитория)
Полезные флаги для git status
-s(или--short) | Сокращённый вывод (буквы обозначают статус файлов).-b| Показывает информацию о ветке (актуально для скриптов).--ignored| Показывает игнорируемые файлы (из .gitignore).
Команда git add — это важнейшая команда Git, которая добавляет изменения из рабочей директории в индекс (staging area), подготавливая их к коммиту. Вот полное руководство по её использованию:
Переводит файлы из состояния «modified/untracked» в состояние «staged» (готово к коммиту).
git add <файл_или_папка> # Добавляет конкретный файл/папку
git add . # Добавляет ВСЕ изменения (новые, изменённые, удалённые)
git add -A # Аналог `git add .` (но учитывает вышестоящие директории)
git add -u # Только изменённые/удалённые файлы (не новые)
git add *.js # Все JS-файлы
git add src/*.css # Все CSS-файлы в папке src
Команда git reset — это мощный инструмент для отмены изменений в Git. Она работает с тремя основными областями: рабочей директорией, индексом (staging area) и историей коммитов.
Git reset воздействует на разные области в зависимости от флага:
--soft | Историю коммитов | Отменяет коммит, но сохраняет изменения в индексе
--mixed (по умолчанию) | Историю + индекс | Отменяет коммит и выносит изменения в рабочую директорию
--hard | Историю + индекс + файлы | Полностью удаляет коммит и все изменения
1. Отмена последнего коммита (с сохранением изменений)
git reset --soft HEAD~1
- Что делает: Удаляет последний коммит, но оставляет изменения в индексе (staged).
- Когда использовать: Если нужно переделать коммит (изменить сообщение или добавить файлы).
2. Полная отмена коммита (с сохранением изменений в файлах)
git reset HEAD~1
# Или (то же самое):
git reset --mixed HEAD~1
- Что делает: Удаляет коммит и выносит изменения в рабочую директорию (как до git add).
- Когда использовать: Если нужно переработать изменения перед новым коммитом.
3. Жёсткая отмена (полное удаление коммита и изменений)
git reset --hard HEAD~1
- Что делает: Полностью удаляет коммит и все связанные с ним изменения.
- Когда использовать: Когда нужно полностью откатиться к предыдущему состоянию.
⚠️ Опасность: Все изменения будут безвозвратно удалены!
git reset file.txt # Убирает файл из staged, сохраняя изменения
git reset a1b2c3d # Хеш коммита
- Используйте --soft, --mixed или --hard в зависимости от нужного эффекта.
-
Не используйте --hard без необходимости — изменения невозможно восстановить!
-
Для опубликованных коммитов используйте git revert вместо reset, чтобы не сломать историю у других разработчиков.
-
Перед reset проверяйте статус:
git status
git log --oneline
Если случайно сделали жёсткий reset:
- Найдите потерянный коммит:
git reflog # Покажет все действия с Git
- Восстановите коммит:
git reset --hard a1b2c3d # Хеш из reflog
Команда git commit фиксирует изменения, добавленные в staging area (индекс) через git add, сохраняя их в истории Git. Это ключевая команда для контроля версий.
git commit -m "Сообщение" # Создаёт коммит с описанием
git commit # Открывает редактор для ввода сообщения
-
Подготовка: Сначала изменения добавляются в индекс через
git add. -
Фиксация:
git commitсоздаёт «снимок» этих изменений с:
- Уникальным хешем (например, a1b2c3d)
- Автором и датой
- Сообщением (commit message)
-m "текст" | Добавить сообщение прямо в командной строке
-a | Автоматически добавить ВСЕ изменённые файлы (кроме новых) и закоммитить
--amend | Исправить последний коммит (изменить сообщение или добавить файлы)
-v | Показать diff в редакторе сообщения
--no-verify | Пропустить pre-commit хуки
Команда git log показывает историю коммитов в текущей ветке. Это основной инструмент для анализа изменений в репозитории.
--oneline | Сокращённый вид (хеш + сообщение)
--graph | Визуализация ветвления (ASCII-граф)
--pretty=format:"..." | Кастомный формат
-n 5 | Показать последние 5 коммитов
--since="2023-01-01" | Коммиты после указанной даты
--until="1 week ago" | Коммиты до периода
--author="John" | Поиск по автору
--grep="bug" | Поиск по сообщению
-p | Показать изменения в файлах (diff)
-- | --
--stat | Статистика изменённых файлов
--name-only | Только имена изменённых файлов
Команда git log — это «машина времени» Git. Чем лучше вы ею владеете, тем проще находить нужные изменения в истории проекта!
Команда git remote управляет подключением локального репозитория к удалённым репозиториям (например, на GitHub, GitLab или Bitbucket). Вот полное руководство по её использованию:
- Просмотр списка удалённых репозиториев
git remote -v
Вывод показывает имя и URL подключённых репозиториев:
origin git@github.com:user/repo.git (fetch)
origin git@github.com:user/repo.git (push)
- Добавление нового удалённого репозитория
git remote add <имя> <url>
Пример (стандартное имя origin):
git remote add origin git@github.com:user/repo.git
- Переименование удалённого репозитория
git remote rename <старое-имя> <новое-имя>
- Удаление подключения
git remote remove <имя>
- Изменение URL существующего репозитория
git remote set-url <имя> <новый-url>
Просмотр подробной информации
git remote show origin
Выводит:
- URL репозитория;
- Отслеживаемые ветки;
- Состояние (отстаёт/опережает локальная ветка).
1. Стандартная настройка для нового проекта
git init
git remote add origin git@github.com:user/repo.git
git push -u origin main
2. Добавление второго удалённого репозитория
git remote add upstream git@github.com:original/repo.git
3. Переключение с HTTPS на SSH
git remote set-url origin git@github.com:user/repo.git
-
Имя origin — это условность, можно использовать любое (например, prod, backup).
-
Для работы с SSH требуется настройка ключей.
-
Команда не изменяет файлы — только настройки подключения.
Команда git remote — это ваш инструмент для управления связями между локальным и удалёнными репозиториями. Всегда проверяйте текущие подключения перед важными операциями!
Команда git push отправляет локальные изменения в удалённый репозиторий. Это ключевая команда для совместной работы в Git.
- Отправляет изменения из текущей ветки в удалённый репозиторий (по умолчанию в origin).
- Работает только после локального коммита (git commit).
git push <remote-name> <local-branch>:<remote-branch>
<remote-name> | Имя удалённого репозитория (обычно origin)
<local-branch> | Локальная ветка для отправки
<remote-branch> | Ветка в удалённом репозитории
- Первая отправка в ветку (с привязкой upstream)
git push -u origin main # Флаг `-u` запоминает связь веток
- После этого можно использовать просто git push.
- Отправить конкретную ветку
git push origin feature/login
- Принудительная отправка (перезапись истории)
git push --force # Только для личных веток!
Или безопасная альтернатива:
git push --force-with-lease
- Удалить ветку на удалённом репозитории
git push origin --delete old-branch
-
Git проверяет, нет ли новых коммитов в удалённом репозитории.
-
Если есть конфликты — требует сначала сделать git pull.
-
Отправляет все новые коммиты и теги.
-
Обновляет указатель ветки на удалённом репозитории.
-u | Устанавливает связь между локальной и удалённой веткой
--tags | Отправляет все теги
--all | Отправляет все ветки
--dry-run | Показать, что будет отправлено (без реального push)
-
git fetch— забирает изменения с удалённого репозитория. -
git merge— создаёт новый коммит слияния (merge commit), если были изменения и локальные, и удалённые.
Проблема: DCA8 История коммитов становится "рваной" из-за merge-коммитов.
-
git fetch— забирает изменения с удалённого репозитория. -
git rebase— перемещает ваши локальные коммиты поверх новых изменений с удалённого репозитория, вместо создания merge-коммита.
Результат:
История остаётся линейной (без лишних merge-коммитов).
Ваши коммиты выглядят так, будто вы создали их после последних изменений в удалённой ветке.
Команда git branch — это основной инструмент для работы с ветками в Git. Она позволяет создавать, просматривать, переименовывать и удалять ветки.
1. Просмотр списка веток
git branch
Вывод:
* main # Текущая ветка (помечена звёздочкой)
feature/login
dev
2. Создание новой ветки
git branch <имя-ветки>
Пример:
git branch feature/search
3. Удаление ветки
git branch -d <имя-ветки> # Безопасное удаление (если изменения слиты)
git branch -D <имя-ветки> # Принудительное удаление (даже при не слитых изменениях)
4. Переименование ветки
git branch -m <старое-имя> <новое-имя>
-a | Показать все ветки (включая удалённые)
-v | Показать последний коммит в каждой ветке
--merged | Показать ветки, уже слитые с текущей
--no-merged | Показать не слитые ветки
-r | Показать только удалённые ветки
1. Создание ветки и переход в неё
git branch new-feature # Создаёт ветку
git checkout new-feature # Переходит в неё
# Или одной командой:
git checkout -b new-feature # Создаёт и переходит
2. Сравнение веток
git branch -v
Вывод:
* main a1b2c3d [ahead 2] Добавил поиск
feature/login b2c3d4e Исправил баг
3. Удаление слитых веток
git branch --merged | grep -v "\*" | xargs -n 1 git branch -d
1. Просмотр удалённых веток
git branch -r
Вывод:
origin/main
origin/dev
2. Создание локальной ветки на основе удалённой
git checkout --track origin/feature
3. Удаление удалённой ветки
git push origin --delete old-branch
-
Текущая ветка всегда помечена звёздочкой (*) в списке.
-
Ветка не будет создана, если имя конфликтует с существующей.
-
Для полной синхронизации списка веток с сервером:
git fetch --prune
* main # Текущая ветка
feature/auth # Локальная ветка
remotes/origin/dev # Удалённая ветка
- Слияние веток:
git merge feature/login
- Отправка ветки на сервер:
git push -u origin feature/login
- Сравнение веток:
git diff main..feature/login
Команда git branch — это фундамент для эффективной работы с ветвлением в Git. Используйте её вместе с git checkout и git merge для полного контроля над вашим workflow!
Команда git checkout (считается устаревшим вариантом, вместо него правильнее использовать git switch и git restore)
Команда git checkout — это один из самых мощных инструментов Git для переключения между ветками, восстановления файлов и работы с историей.
Основной синтаксис:
git checkout <имя-ветки>
Пример:
git checkout develop # Переключиться на ветку develop
Создание и переключение на новую ветку:
git checkout -b new-feature # Создаёт ветку new-feature и переключается на неё
Вернуть файл к последней закоммиченной версии:
git checkout -- <файл>
Пример:
git checkout -- index.html # Отменяет все изменения в index.html
Вернуть файл из другого коммита:
git checkout a1b2c3d -- file.js # Берёт file.js из коммита a1b2c3d
Временное переключение на коммит:
git checkout a1b2c3d # Переходит в состояние Detached HEAD
Важно: в этом режиме новые коммиты будут "висеть в воздухе".
Чтобы сохранить изменения:
git checkout -b new-branch # Создаёт ветку из текущего состояния
Создать локальную ветку для удалённой:
git checkout --track origin/feature # Автоматическое отслеживание
Или эквивалентная команда:
git checkout -b feature origin/feature
Быстрое переключение на предыдущую ветку:
git checkout - # Как cd - в терминале
Восстановление удалённой ветки:
git checkout -b lost-branch origin/lost-branch
Полный сброс рабочей директории:
git checkout -- . # Отменяет ВСЕ изменения в рабочей директории
Команда git switch была добавлена в Git 2.23 (2019 год) как более безопасная и интуитивная альтернатива git checkout для работы с ветками. Вот полное руководство по её использованию:
1. Переключение на существующую ветку
git switch <имя-ветки>
Пример:
git switch main
2. Создание и переключение на новую ветку
git switch -c <новая-ветка>
Пример:
git switch -c feature/login
(Флаг -c означает --create)
-
Безопасность: git switch откажется работать с несохранёнными изменениями
-
Специализация: Только для переключения веток (не путать с восстановлением файлов)
-
Читаемость: Более понятный синтаксис
-c | Создать новую ветку и переключиться
-C | Принудительно перезаписать существующую ветку
--track | Создать ветку с отслеживанием удалённой
--detach | Переключиться на коммит (Detached HEAD)
1. Создать локальную ветку для удалённой
git switch --track origin/feature
Или сокращённо:
git switch feature
(Если ветка существует только на удалённом репозитории)
2. Переключиться на новую ветку из удалённого репозитория
git fetch
git switch -c new-feature origin/main
1. Стандартный workflow
git switch main # Переключиться на main
git switch -c hotfix # Создать ветку для исправления
# ... вносим изменения ...
git switch main # Вернуться обратно
2. Восстановление удалённой ветки
git fetch
git switch feature/login # Автоматически создаст локальную версию удалённой ветки
Если есть не сохранённые изменения:
Способ 1: Зафиксировать изменения
git commit -a -m "Сообщение"
git switch other-branch
Способ 2: Временно сохранить (stash)
git stash
git switch other-branch
git stash pop
Способ 3: Перенести изменения
git switch -m other-branch # Флаг -m переносит не сохранённые изменения
Команда git restore (появилась в Git 2.23+) — это современная замена части функциональности git checkout и git reset для управления состоянием файлов. Она предоставляет более предсказуемый и безопасный способ отмены изменений.
1. Отмена изменений в рабочей директории (аналог git checkout -- )
git restore <file>
Пример:
git restore index.html # Отменяет все не закоммиченные изменения в файле
2. Удаление файла из индекса (staging area)
git restore --staged <file>
Пример:
git restore --staged style.css # Убирает файл из staged, сохраняя изменения
3. Полное восстановление файла (из последнего коммита)
git restore --source=HEAD --staged --worktree <file>
Пример:
git restore --source=HEAD --staged --worktree app.js
--staged | Работает только с индексом (staging area)
--worktree | Работает только с рабочей директорией
--source=<commit> | Указывает, из какого коммита восстанавливать
--patch | Интерактивный режим (пошаговая отмена)
- Отмена всех локальных изменений
git restore . # Аналог `git checkout -- .`
- Восстановление удалённого файла из коммита
git restore --source=HEAD~1 deleted-file.txt
- Частичная отмена изменений (интерактивно)
git restore --patch index.html
- Безопасность:
git restoreне позволит потерять FCCC езакоммиченные изменения без явного указания - Гибкость: Можно точно указать, что восстанавливать (рабочие файлы, индекс или оба)
- Читаемость: Команда явно описывает своё действие
- Для новых проектов используйте
git restoreвместоgit checkout -- <file> - Комбинируйте с
git statusдля проверки состояния перед отменой - Используйте
--patchдля точного контроля над изменениями
Команда git restore — это важная часть современного Git-воркфлоу, делающая работу с изменениями более предсказуемой и безопасной.
Команда git stash — это «временное хранилище» для незакоммиченных изменений, позволяющее быстро переключаться между задачами без создания лишних коммитов. Вот полное руководство по её использованию.
1. Сохранить изменения в stash
git stash
или с сообщением:
git stash push -m "Сообщение"
Сохраняет все изменения (включая untracked файлы с флагом -u)
2. Просмотр списка stash'ей
git stash list
Вывод:
stash@{0}: On main: Сообщение
stash@{1}: WIP on feature: a1b2c3d...
3. Вернуть изменения из stash
git stash apply stash@{1} # Вернуть конкретный stash
git stash pop # Вернуть последний stash и удалить его из списка
4. Удалить stash
git stash drop stash@{0} # Удалить конкретный stash
git stash clear # Очистить весь список
-u | Включает untracked файлы
-a | Включает все файлы (даже игнорируемые)
--patch | Интерактивный режим (выбор изменений)
show | Показать изменения в stash
branch | Создать ветку из stash
1. Стандартный workflow
# 1. Работаем в ветке feature
git switch feature
# 2. Срочное исправление в main
git stash -m "Сохранение перед исправлением"
git switch main
# 3. После исправления возвращаемся
git switch feature
git stash pop
- Создание ветки из stash
git stash branch new-feature stash@{1}
Создаёт ветку new-feature и применяет stash
3. Просмотр изменений в stash
git stash show -p stash@{0}
- Stash сохраняет:
- Изменённые tracked-файлы
- Добавленные в индекс изменения (staged) Untracked-файлы требуют флага
-u
-
Данные stash хранятся локально (не передаются при git push)
-
Для переноса stash между ветками используйте:
git stash show -p > patch.diff
git apply patch.diff
Команда git stash — идеальный инструмент для:
- Срочного переключения между задачами
- Сохранения «рабочего хаоса» перед pull/merge
- Временного хранения экспериментальных изменений
Используйте её вместо временных коммитов для поддержания чистой истории!
Команда git merge объединяет изменения из одной ветки в текущую. Это основной инструмент для интеграции изменений в Git. Разберём её работу детально.
git merge <ветка-источник>
Пример:
git checkout main # Переключаемся в ветку-приёмник
git merge feature/login # Вливаем изменения из feature/login в main
--no-ff | Всегда создаёт коммит слияния (даже при возможности fast-forward)
--squash | Объединяет все изменения в один новый коммит
-m | Сообщение для коммита слияния
--abort | Отмена слияния при конфликтах
git checkout main
git merge feature --no-ff -m "Объединение функционала входа"
git merge feature --squash
git commit -m "Все изменения из feature"
При конфликте Git остановит процесс
Вручную редактируем файлы (маркеры <<<<<<<, =======, >>>>>>>)
Добавляем исправленные файлы:
git add .
Завершаем слияние:
git merge --continue
recursive | По умолчанию для большинства случаев
octopus | Для одновременного слияния нескольких веток
subtree | Для проектов с подмодулями
git merge -s recursive -X theirs feature
git diff main..feature # Покажет все изменения
git log --graph --oneline --all # Визуализация истории
До коммита:
git merge --abort
После коммита:
git reset --hard HEAD~1
или для опубликованных изменений:
git revert -m 1 <коммит-слияния>
Всегда обновляйте ветку перед слиянием:
git fetch origin
git rebase origin/main # Для feature-веток
Используйте --no-ff для важных слияний — так история будет нагляднее.
Для сложных веток рассмотрите альтернативу — git rebase (линеаризует историю).
Слияние не той ветки
Всегда проверяйте текущую ветку:
git branch
Потеря изменений при конфликтах
Используйте git mergetool для визуального разрешения.
Слияние уже слитых изменений
Проверьте историю:
git log --oneline --graph
Команда git merge — это фундамент совместной работы в Git.
Для больших проектов дополнительно изучите:
git rebase для поддержания линейной истории
git rerere для автоматического разрешения повторяющихся конфликтов
Системы pull/merge request в GitHub/GitLab
git rebase — это мощная команда, которая позволяет изменять историю коммитов: перемещать, объединять или редактировать коммиты. Это альтернатива слиянию (merge), которая помогает поддерживать историю проекта более чистой и линейной.
git rebase <ветка>
Эта команда "перемещает" коммиты из текущей ветки и применяет их поверх указанной ветки.
Перемещение feature-ветки на основную ветку:
git checkout feature-branch
git rebase main
Интерактивный rebase (для редактирования коммитов):
git rebase -i HEAD~3 # Редактирует последние 3 коммита
Продолжение прерванного rebase:
git rebase --continue
Отмена rebase:
git rebase --abort
Интерактивный rebase (rebase -i)
Позволяет:
- Изменять порядок коммитов
- Объединять коммиты (squash)
- Редактировать сообщения коммитов (reword)
- Разделять коммиты (edit)
- Удалять коммиты (drop)
- Используйте rebase для локальных веток
- Перед rebase убедитесь, что рабочая область чистая
- Регулярно обновляйте feature-ветки через rebase на основную ветку
- Для общих веток предпочтительнее использовать merge