Git стал стандартом де-факто в мире разработки программного обеспечения. Это мощная система контроля версий, которая позволяет командам эффективно сотрудничать, отслеживать изменения и управлять кодовой базой. Новичку Git может показаться сложным из-за обилия команд и концепций. Однако правда в том, что для выполнения 90% повседневных задач достаточно уверенно владеть небольшим набором ключевых команд.
В этой статье мы разберем 15 команд Git, которые покроют почти все ваши задачи. Понимание их работы, контекста использования и потенциальных подводных камней позволит вам чувствовать себя уверенно при работе с Git, будь то личный проект или крупный командный репозиторий. Постараюсь объяснить все как для самых маленьких.
Если вам интересен процесс и вы хотите следить за дальнейшими материалами, буду признателен за подписку на мой телеграм-канал. Там я публикую полезныe материалы по разработке, разборы сложных концепций, советы как быть продуктивным и конечно же отборные мемы: https://t.me/nullPointerDotEXE.
git clone
Эта команда используется для создания локальной копии удаленного репозитория. По сути, вы скачиваете всю историю проекта и рабочие файлы с сервера (например, с GitHub, GitLab, Bitbucket) на свой компьютер. Это самая первая команда, которую вы выполняете, когда начинаете работать с существующим проектом. Вы указываете URL репозитория, и Git создает папку с именем репозитория (если не указать другое имя) и загружает туда все необходимое.
Пример:
git clone https://github.com/имя_пользователя/имя_репозитория.git
# Или так, чтобы клонировать в папку с другим именем:
git clone https://github.com/имя_пользователя/имя_репозитория.git моя_папка_проекта
Просто убедитесь, что у вас есть права доступа к репозиторию, если он приватный. И помните, git clone автоматически настраивает связь с удаленным репозиторием под именем origin, что упрощает последующие push и pull.
git status
Ваш главный индикатор состояния репозитория. Эта команда показывает, какие файлы были изменены с момента последнего коммита, какие файлы готовы к коммиту , а какие файлы Git еще не отслеживает. Выполнять git status стоит часто – перед add, перед commit, после pull, чтобы всегда понимать, что происходит в вашем рабочем каталоге. Она не меняет ничего, только информирует.
Пример:
git statusВывод покажет текущую ветку, наличие неотправленных коммитов и списки измененных, проиндексированных и неотслеживаемых файлов. Это ваша приборная панель в Git, не пренебрегайте ей. Если вывод кажется непонятным, значит, самое время разобраться, что именно изменилось.
git add
Эта команда добавляет изменения из рабочего каталога в так называемую «staging area». Staging area – это промежуточный этап перед созданием коммита. Вы сами выбираете, какие именно изменения войдут в следующий коммит. Это позволяет делать атомарные, логически завершенные коммиты, даже если вы внесли множество разных изменений в разные файлы. Можно добавлять файлы по одному, группами или все сразу.
Примеры:
# Добавить конкретный файл
git add имя_файла.txt
# Добавить все изменения в текущей папке и подпапках
git add .
# Добавить все измененные и новые файлы во всем репозитории
git add -A
# Интерактивно выбрать, какие части изменений в файле добавить
git add -p
Часто используется git add ., но будьте внимательны: эта команда добавит все изменения, включая случайные или временные файлы, если они не указаны в .gitignore. Использование git add -p очень полезно для ревью собственных изменений перед коммитом.
git commit
Фиксирует изменения, добавленные в staging area (git add), в локальной истории репозитория. Каждый коммит — это снимок состояния проекта в определенный момент времени, снабженный уникальным хешем и сообщением, описывающим суть изменений. Хорошее сообщение коммита критически важно для понимания истории проекта вами и вашей командой.
Примеры:
# Создать коммит с коротким сообщением прямо из командной строки
git commit -m "Исправлена опечатка в README"
# Открыть текстовый редактор для ввода подробного сообщения коммита
git commit
Старайтесь писать осмысленные сообщения коммитов. Стандартная практика — начинать с краткой строки (до 50 символов), описывающей суть, а затем, после пустой строки, добавлять более подробное описание, если это необходимо. Если вы забыли что-то добавить в последний коммит, можно использовать git commit --amend, но делайте это только с коммитами, которые еще не были отправлены на удаленный сервер (git push), иначе создадите проблемы коллегам.
git push
Отправляет ваши локальные коммиты на удаленный репозиторий (тот самый origin, который обычно настраивается при git clone). Это делает ваши изменения доступными для других членов команды. Вы указываете имя удаленного репозитория (обычно origin) и имя ветки, которую хотите отправить.
Примеры:
# Отправить изменения из текущей локальной ветки в одноименную ветку на origin
git push origin имя_ветки
# Более короткая версия, если upstream уже настроен (часто работает после первого push)
git push
Перед git push всегда полезно сделать git pull, чтобы убедиться, что ваша локальная версия ветки актуальна и избежать потенциальных конфликтов при отправке. Если Git откажется пушить из-за расхождения историй, вам сначала нужно будет интегрировать эти удаленные изменения (git pull).
git pull
Забирает изменения с удаленного репозитория и пытается слить их с вашей текущей локальной веткой. По сути, это комбинация двух других команд: git fetch (скачивает изменения, но не применяет их) и git merge (сливает скачанные изменения с вашей веткой). Это стандартный способ обновить вашу локальную копию проекта последними изменениями от коллег.
Примеры:
# Скачать изменения из ветки 'main' репозитория 'origin' и слить их с текущей локальной веткой
git pull origin main
# Короткая версия, если upstream настроен для текущей ветки
git pull
Будьте готовы к тому, что git pull может привести к конфликтам слияния, если вы и кто-то другой редактировали одни и те же участки кода в разных коммитах. Git сообщит об этом и отметит конфликтующие места в файлах. Вам нужно будет вручную разрешить эти конфликты, затем добавить (git add) исправленные файлы и завершить слияние (часто это делается новым коммитом). Иногда вместо merge при pull используется rebase (git pull --rebase), что сохраняет историю более линейной.
git branch
Управляет ветками в вашем репозитории. Ветки — это независимые линии разработки, позволяющие работать над новой функциональностью или исправлением ошибок, не затрагивая основной стабильный код (например, в ветке main или master). Команда git branch без аргументов покажет список всех локальных веток и отметит текущую звездочкой.
Примеры:
# Показать все локальные ветки
git branch
# Создать новую ветку с именем 'new-feature'
git branch new-feature
# Удалить ветку (безопасно - не даст удалить, если изменения не слиты)
git branch -d old-feature
# Удалить ветку принудительно (опасно - можно потерять изменения)
git branch -D very-old-feature
# Показать все ветки (локальные и удаленные)
git branch -a
Создание веток — дешевая операция в Git. Не бойтесь создавать их для каждой новой задачи. Это изолирует вашу работу и упрощает процесс ревью и слияния кода. Следите за количеством старых веток и удаляйте те, что уже не нужны, чтобы не захламлять репозиторий.
git checkout
Эта команда используется для переключения между ветками или восстановления файлов в рабочем каталоге до состояния из определенного коммита или индекса. Это одна из самых многозадачных (и потому иногда путающих) команд в Git. Основное применение — переход на другую ветку для работы над ней.
Примеры:
# Переключиться на существующую ветку 'develop'
git checkout develop
# Создать новую ветку 'hotfix' и сразу переключиться на неё
git checkout -b hotfix
# Отменить изменения в файле 'config.yml' до состояния последнего коммита
git checkout -- config.yml
Использование git checkout -- файл опасно, так как отменяет все незакоммиченные изменения в файле безвозвратно. Будьте уверены, что делаете это намеренно. Из-за многозначности checkout, в новых версиях Git появились команды git switch (для переключения веток) и git restore (для восстановления файлов), которые делают код более читаемым и безопасным. Но checkout всё ещё очень распространён.
git switch
Более современная и безопасная альтернатива git checkout для переключения между ветками. Эта команда создана специально для работы с ветками, что делает намерения в коде более ясными и снижает риск случайной потери данных при восстановлении файлов (так как switch этим не занимается).
Примеры:
# Переключиться на существующую ветку 'feature/auth'
git switch feature/auth
# Создать новую ветку 'bugfix/login-issue' и переключиться на неё
git switch -c bugfix/login-issue
# Вернуться на предыдущую ветку
git switch -
Если вы используете свежую версию Git, рекомендуется отдавать предпочтение git switch для переключения веток вместо git checkout. Это делает ваши скрипты и ручные операции более понятными и менее подверженными ошибкам.
git merge
Сливает изменения из одной ветки в другую. Обычно вы переключаетесь на ветку, в которую хотите влить изменения (например, main или develop), а затем выполняете git merge с указанием ветки, из которой хотите забрать изменения (например, ваша feature ветка). Git попытается автоматически объединить истории.
Пример:
# Переключаемся на основную ветку
git switch main
# Вливаем изменения из ветки 'new-feature' в 'main'
git merge new-feature
Если конфликтов нет, Git создаст новый «коммит слияния» (merge commit), у которого будет два родительских коммита. Если есть конфликты, Git остановит процесс, отметит конфликты в файлах, и вам нужно будет разрешить их вручную, добавить исправленные файлы (git add) и завершить слияние командой git commit. Слияние — ключевой процесс интеграции работы разных разработчиков или разных фич.
git rebase
Альтернатива merge. Позволяет «переписать» историю, подставив коммиты ветки поверх другой. Используется для чистой истории без лишних merge-коммитов. Пример:
git checkout feature #переключаемся yf dtnre
git rebase main #так же вливаем измененияПосле завершения — git push --force, если история уже была опубликована.
git log
Показывает историю коммитов текущей ветки, начиная с самого последнего. Вы увидите хеш каждого коммита, автора, дату и сообщение коммита. Это основной инструмент для изучения истории проекта, понимания, кто и когда внес определенные изменения. git log имеет множество опций для форматирования вывода.
Примеры:
# Показать стандартный лог
git log
# Показать лог в более компактном виде (одна строка на коммит)
git log --oneline
# Показать лог с графическим представлением веток и слияний
git log --graph --oneline --decorate
# Показать лог изменений для конкретного файла
git log имя_файла.py
# Показать последние 5 коммитов
git log -n 5
Изучение git log и его опций — очень полезный навык. Он помогает не только смотреть историю, но и находить конкретные коммиты, например, чтобы отменить их (git revert) или посмотреть изменения (git show ).
git diff
Показывает разницу между различными состояниями: между рабочим каталогом и индексом (staging area), между индексом и последним коммитом, между двумя коммитами или ветками. Это незаменимый инструмент для просмотра изменений перед их добавлением (git add) или коммитом (git commit).
Примеры:
# Показать изменения в рабочем каталоге, которые еще НЕ добавлены в индекс (unstaged changes)
git diff
# Показать изменения, которые добавлены в индекс, но еще НЕ закоммичены (staged changes)
git diff --staged
# или
git diff --cached
# Показать разницу между двумя коммитами
git diff
# Показать разницу между двумя ветками
git diff main develop
Используйте git diff перед git add . или git commit -a, чтобы точно понимать, какие изменения вы собираетесь зафиксировать. Это помогает избежать случайного коммита отладочного кода или нежелательных изменений. Также git diff часто используется при код-ревью для просмотра конкретных изменений между ветками.
git stash
Временно сохраняет ваши незакоммиченные изменения (как из рабочего каталога, так и из индекса), чтобы вы могли переключиться на другую ветку или выполнить другую операцию, не теряя свою текущую работу. Это как положить свою работу на полку, чтобы потом вернуться к ней. После того как вы закончили с другими делами, вы можете вернуть сохраненные изменения обратно.
Примеры:
# Сохранить текущие незакоммиченные изменения в 'stash'
git stash save "Работа над интерфейсом пользователя" # Необязательное сообщение
# Показать список сохраненных состояний ('stashes')
git stash list
# Применить последние сохраненные изменения и удалить их из списка stash
git stash pop
# Применить последние сохраненные изменения, но оставить их в списке stash
git stash apply
# Удалить последнее сохраненное состояние из списка
git stash drop
git stash — это спасение, когда вам срочно нужно переключиться на другую задачу (например, исправить баг в продакшене), но ваша текущая работа еще не готова к коммиту. Только не забывайте про сохраненные изменения в stash, со временем там может накопиться много всего, и будет сложно вспомнить, что к чему относится.
git reset
Команда с несколькими режимами, используемая в основном для отмены изменений. Она может перемещать указатель HEAD (и текущей ветки) на другой коммит, а также опционально изменять индекс (staging area) и рабочий каталог. Это мощная, но потенциально опасная команда, особенно в режиме --hard.
Примеры:
# Отменить 'git add' для файла (убрать из индекса, но оставить изменения в рабочем каталоге)
git reset HEAD имя_файла
# или более современный вариант: git restore --staged имя_файла
# Откатить последний коммит, но оставить изменения в рабочем каталоге и индексе (--soft)
git reset --soft HEAD~1
# Откатить последний коммит, оставить изменения в рабочем каталоге, но убрать из индекса (--mixed - это режим по умолчанию)
git reset HEAD~1
# Откатить последний коммит И УДАЛИТЬ все связанные с ним изменения из рабочего каталога и индекса (--hard - ОПАСНО!)
git reset --hard HEAD~1
Используйте git reset с осторожностью, особенно --hard, так как он безвозвратно удаляет незакоммиченные изменения. git reset также используется для отмены коммитов, которые еще не были отправлены на удаленный сервер. Если коммит уже опубликован (git push), для его отмены лучше использовать git revert, чтобы не переписывать общую историю.
Что дальше?
Освоив эти 15 команд, вы действительно сможете решать почти все задачи разработчика, связанных с Git. Практикуйтесь: создайте тестовый репозиторий, экспериментируйте с ветками, слияниями, отменой изменений. Понимание приходит с опытом.
Git — мощный инструмент, и его изучение может продолжаться долго. Но шпаргалка из этих 15 команд позволит вам уверенно навигировать в мире контроля версий и эффективно сотрудничать с другими разработчиками. Гудлак!
Источник: https://habr.com/ru/articles/905658/