Работа с Гитхаб (последовательное описание команд) / 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 отслеживать изменения в вашем проекте.

Вот подробное объяснение:

1. Создаёт скрытую папку .git в текущей директории. В ней хранится вся история коммитов, ветки, настройки и служебные данные Git. Без этой папки Git не работает в проекте.

2. Инициализирует пустой репозиторий, готовый к отслеживанию файлов.

Команда 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 в зависимости от нужного эффекта.

1. Не используйте --hard без необходимости — изменения невозможно восстановить!

2. Для опубликованных коммитов используйте git revert вместо reset, чтобы не сломать историю у других разработчиков.

3. Перед reset проверяйте статус:

git status
git log --oneline

Если случайно сделали жёсткий reset:

1. Найдите потерянный коммит:

git reflog  # Покажет все действия с Git

2. Восстановите коммит:

git reset --hard a1b2c3d  # Хеш из reflog

Команда git commit фиксирует изменения, добавленные в staging area (индекс) через git add, сохраняя их в истории Git. Это ключевая команда для контроля версий.

git commit -m "Сообщение"  # Создаёт коммит с описанием
git commit                 # Открывает редактор для ввода сообщения

1. Подготовка: Сначала изменения добавляются в индекс через git add.

2. Фиксация: 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). Вот полное руководство по её использованию:

1. Просмотр списка удалённых репозиториев

git remote -v

Вывод показывает имя и URL подключённых репозиториев:

origin  git@github.com:user/repo.git (fetch)
origin  git@github.com:user/repo.git (push)

2. Добавление нового удалённого репозитория

git remote add <имя> <url>

Пример (стандартное имя origin):

git remote add origin git@github.com:user/repo.git

3. Переименование удалённого репозитория

git remote rename <старое-имя> <новое-имя>

4. Удаление подключения

git remote remove <имя>

5. Изменение 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

1. Имя origin — это условность, можно использовать любое (например, prod, backup).

2. Для работы с SSH требуется настройка ключей.

3. Команда не изменяет файлы — только настройки подключения.

Команда git remote — это ваш инструмент для управления связями между локальным и удалёнными репозиториями. Всегда проверяйте текущие подключения перед важными операциями!

Команда git push отправляет локальные изменения в удалённый репозиторий. Это ключевая команда для совместной работы в Git.

• Отправляет изменения из текущей ветки в удалённый репозиторий (по умолчанию в origin).
• Работает только после локального коммита (git commit).

git push <remote-name> <local-branch>:<remote-branch>

<remote-name> | Имя удалённого репозитория (обычно origin)
<local-branch> | Локальная ветка для отправки
<remote-branch> | Ветка в удалённом репозитории

1. Первая отправка в ветку (с привязкой upstream)

git push -u origin main  # Флаг `-u` запоминает связь веток

• После этого можно использовать просто git push.

2. Отправить конкретную ветку

git push origin feature/login

3. Принудительная отправка (перезапись истории)

git push --force  # Только для личных веток!

Или безопасная альтернатива:

git push --force-with-lease

4. Удалить ветку на удалённом репозитории

git push origin --delete old-branch

1. Git проверяет, нет ли новых коммитов в удалённом репозитории.

2. Если есть конфликты — требует сначала сделать git pull.

3. Отправляет все новые коммиты и теги.

4. Обновляет указатель ветки на удалённом репозитории.

-u | Устанавливает связь между локальной и удалённой веткой
--tags | Отправляет все теги
--all | Отправляет все ветки
--dry-run | Показать, что будет отправлено (без реального push)

1. git fetch — забирает изменения с удалённого репозитория.

2. git merge — создаёт новый коммит слияния (merge commit), если были изменения и локальные, и удалённые.

Проблема: История коммитов становится "рваной" из-за merge-коммитов.

1. git fetch — забирает изменения с удалённого репозитория.

2. 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

1. Текущая ветка всегда помечена звёздочкой (*) в списке.

2. Ветка не будет создана, если имя конфликтует с существующей.

3. Для полной синхронизации списка веток с сервером:

git fetch --prune

* main               # Текущая ветка
  feature/auth       # Локальная ветка
  remotes/origin/dev # Удалённая ветка

1. Слияние веток:

git merge feature/login

2. Отправка ветки на сервер:

git push -u origin feature/login

3. Сравнение веток:

git diff main..feature/login

Команда git branch — это фундамент для эффективной работы с ветвлением в Git. Используйте её вместе с git checkout и git merge для полного контроля над вашим workflow!

Команда 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)

1. Безопасность: git switch откажется работать с несохранёнными изменениями

2. Специализация: Только для переключения веток (не путать с восстановлением файлов)

3. Читаемость: Более понятный синтаксис

-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 | Интерактивный режим (пошаговая отмена)

1. Отмена всех локальных изменений

git restore .  # Аналог `git checkout -- .`

2. Восстановление удалённого файла из коммита

git restore --source=HEAD~1 deleted-file.txt

3. Частичная отмена изменений (интерактивно)

git restore --patch index.html

1. Безопасность: git restore не позволит потерять незакоммиченные изменения без явного указания
2. Гибкость: Можно точно указать, что восстанавливать (рабочие файлы, индекс или оба)
3. Читаемость: Команда явно описывает своё действие

1. Для новых проектов используйте git restore вместо git checkout -- <file>
2. Комбинируйте с git status для проверки состояния перед отменой
3. Используйте --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

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

git stash branch new-feature stash@{1}

Создаёт ветку new-feature и применяет stash

3. Просмотр изменений в stash

git stash show -p stash@{0}

1. Stash сохраняет:

• Изменённые tracked-файлы
• Добавленные в индекс изменения (staged) Untracked-файлы требуют флага -u

2. Данные stash хранятся локально (не передаются при git push)

3. Для переноса 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 переписывает историю, поэтому используйте его осторожно.

1. Используйте rebase для локальных веток
2. Перед rebase убедитесь, что рабочая область чистая
3. Регулярно обновляйте feature-ветки через rebase на основную ветку
4. Для общих веток предпочтительнее использовать merge