Гитом я пользуюсь достаточно долго, правда по большей части для моих задач хватало графического интерфейса в виде SourceTree. Но я давно понимала, что рано или поздно мне придётся обратиться к консольным командам Git. Хотя бы потому, что консольные команды работают везде одинаково, в любой операционной системе, в любой среде.

Я решила покопать чуть глубже в одном из базовых навыков для любого разработчика с целью подтянуть знания по части CLI-интерфейса гита. В общем и целом у меня получился небольшой список базовых консольных команд Git и разъяснения как и что работает. Делюсь с вами, если вы новичок в теме гита — пожалуйста, наслаждайтесь ))

Конечно, для начинающих более удобно (на мой взгляд) использовать графический интерфейс, но я всё же советую сразу учиться пользоваться консолью/терминалом, т.к. это очень полезный навык. Можно исключительно в качестве дополнительного способа взаимодействия с гитом, помимо того же SourceTree (как это происходит у меня).

Основные команды Git

git clone git@ssh-clone-address[или https://github.com/account/repo.git

Данная команда клонирует репозиторий из гитхаба (битбакета или других хранилищ) на локальную машину. Копирует в ту директорию, из которой был произведён запуск команды. Для того чтобы клонировать репозиторий через ssh, само собой разумеется необходим сгенерированный ключ ssh, но это не тема сегодняшней заметки. Если же интересует вопрос как это сделать — будет отдельная статья или обновление здесь. Там посмотрим.

git status

Данная команда позволяет увидеть статус текущей ветки. Какие файлы были изменены, добавлены, удалены и т.д. и т.п. Это полезно, когда (и если) вы работаете через терминал.

git add .[или filename, или dirname]

Когда файлы изменены, используем команду add чтобы добавить изменённые файлы в качестве «внесённых изменений» (staged). Без этого не получится коммит, что является основой работы с гитом. Если ввести git add . — то все изменённые, добавленные и удалённые файлы будут добавлены в список для последующего коммита.

git commit -m "message title" [-m "message description"]

После того, как изменения добавлены, можно совершить коммит. У коммита обязательно должен быть заголовок. В целом описание не обязательно, но будет желательно. Плюс хорошей практикой является написание в заголовке коммита «что произошло», а в описании «какие конкретно изменения были внесены».

После того, как коммит произведён, изменения считаются локально внесёнными. Т.е. если вы работаете с удалённым репозиторием в гитхаб например, то изменения на этом этапе есть у вас на локальной машине, но не в репозитории на гитхаб.

Прежде чем перейти к отправке изменений в удалённый репозиторий, надо отметить ещё один вариант коммита и пару других полезных команд.

git commit -am "message title" или git commit -a -m "message title"

Особенность параметра -а данной команды заключается в том, что прежде чем делать коммит, вам не нужно добавлять изменённые файлы через команду git add. Но есть одно важное НО. Это работает только для изменённых файлов. Если у вас есть новые файлы в проекте, то их всё равно придётся добавить через git add. В таком случае мне кажется более удобным разделить добавление (стейджинг) и коммит на две команды.

git branch

Данная команда позволяет увидеть список всех веток в репозитории. Также данная команда позволяет увидеть текущую ветку — она будет отмечена символом *.

git branch branch_name

С помощью этой команды мы можем создать новую ветку в репозитории. Полезно при разработке в команде, когда над кодом работают несколько человек. Также общепринятой практикой можно считать создание отдельной ветки для отдельной задачи.

Имя ветки допускает также следующий формат branch_group/branch_name. Допустим вы реализуете какую-нибудь фичу в проекте и для этой задачи будет неплохо сделать отдельную ветку, но если в команде много разработчиков и каждый работает над своей фичей, то будет много веток, в которых кто-нибудь да запутается. Допустим вы делаете галерею изображений, а другие разработчики занимаются своими задачами. В этой ситуации спасает вариант git branch features/imageGallery. Если ваша ветка первая в группе, то группа будет создана автоматически. Если же данная группа уже существует, то ваша ветка просто будет добавлена в группу. В клиентах с визуальным пользовательским интерфейсом данные ветки будут выглядеть как вложенный список, что также помогает упорядочить и упростить работу.

git branch -d branch_name

Ну а с помощью данной команды, точнее флага -d, можно удалить ветку. Команда максимально понятна в своём назначении.

git push origin branchName

Ну вот и отправка изменений в удалённый репозиторий. После исполнения данной команды, изменения будут внесены уже в репозиторий на гитхабе (например). Здесь тоже есть свои особенности. Когда вы работаете не над совсем маленьким проектом, где вся работа ведётся в ветке main или master, или dev, вам придётся создавать ветки для разработки тех или иных частей проекта. И если ваша ветка создана на локальной машине, но её нет в удалённом репозитории, команда выше вызовет ошибку. Чтобы загрузить новую ветку в удалённый репозиторий, необходимо указать параметр команды

git push -u[--set-upstream] origin branchName

Параметр -u или —set-upstream позволит отправить новую ветку в удалённый репозиторий и сделать её отслеживаемой (tracked).

git log

Позволяет увидеть последовательность коммитов. В выводе мы увидим commit: commit hash, автора, дату и текст описания коммита. Это довольно полезная команда, т.к. по сути хэш коммита — это его идентификатор, по которому с ним можно работать.

P.S. для совсем новичков: Чтение лога коммитов открывается в vim-подобном редакторе прямо в консоли. Здесь есть одна особенность. Выйти из него новичку может оказаться непросто, если раньше не работали с подобными редакторами. Из него не получится выйти на ctrl+d/f/x/c. В нижней части терминала вы можете заметить символ двоеточия [:]. При нажатии некоторых клавиш вместо него могут появляться уведомления. Например если нажмёте клавишу v, то там появится сообщение, что стандартный ввод недоступен. Так вот, чтобы выйти из редактора, надо нажать клавишу q когда видите в нижней строке символ : . А если вместо : вы видите что-то другое (сообщение, символы и т.д.) можно попробовать убрать их с помощью клавиши backspace [ ← ].

git reset [filename]

Данная команда позволяет удалить добавленные (командой git add) файлы, если вы ещё не успели сделать коммит. Если ввести конкретное имя файла, то он будет убран из списка файлов, подготовленных к коммиту, если же не вводить имён вообще, то убраны будут все файлы, которые были добавлены командой git add. Здесь важно обратить внимание на то, что сами файлы сохранятся и не будут удалены или ещё как-то изменены. Командой git status мы их снова увидим в списке изменённых, но не добавленных к коммиту.

git reset HEAD~1

Данная команда может быть полезна в ситуации, когда вы уже сделали коммит, но ещё не сделали пуш, например, если в коммит попал лишний файл, который не должен быть отправлен в ремоут. Данная команда удаляет последний сделанный коммит. Опять же, файлы затронуты не будут, они просто снова будут показаны как изменённые, но не добавленные к какому-либо коммиту. Их снова нужно будет добавить командой git add, а затем сделать коммит.

git reset commit_hash

А вот здесь нам пригодится хэш, он же условно id коммита, который можно получить из git log. Суть команды в том, что она позволяет нам откатиться до конкретного коммита. Опять же это сработает идеально, если вы ещё не делали пуш в удалённый репозиторий. Если же вы его уже сделали… ну скорее всего вас ждут конфликты, которые придётся решать. Но это тема для отдельной статьи, которая, надеюсь, когда-нибудь появится =) Данная команда не удаляет изменённые файлы, она просто делает изменения не добавленными. Здесь важно не удалить лишний код из файлов, которые вы откатили из коммита, т.к. он ещё нигде не сохранён и можно потерять данные. Но всё же в данной ситуации это не так страшно.

git reset —hard commit_hash

Данная команда идентична предыдущей за одним очень большим и серьёзным исключением. Флаг —hard указывает на принудительный переход к коммиту по всем фронтам. Другими словами происходит полный откат репозитория до указанного коммита, с удалением данных, которые были сделаны после указанного коммита. Вообще всё, что связано с флагами —hard или —force стоит если не обходить стороной, то использовать с крайней осторожностью. Да, с опытом придёт и умение работать с такими вещами, но по началу лучше много раз проверить всё ли делается чётко по плану.

git checkout branch_name

Это последняя на сегодня команда и она позволяет нам переключиться между существующими ветками. Не забывайте, что если у вас есть изменённые файлы в текущей ветке и вам надо переключиться на другую — лучше всего сделать коммит, а затем уже переключаться. А иногда это в принципе обязательно, потому что иначе гит выдаст ошибку и просто не пустит в другую ветку.

Также у данной команды есть ещё один маленький бонус — он же недостаток. Если вы переключаетесь на несуществующую ветку, то она будет автоматически создана и после этого вы будете переключены на неё. Бонус — можно не заморачиваться с отдельной командой git branch branch_name. Недостаток — опечатка в названии ветки, и вы попадёте не туда куда хотели, и к тому же создадите дополнительную ветку. Это, конечно, не смертельно, но всё равно заставит вас ввести несколько лишних команд.

Пожалуй на этом мы на сегодня закончим. В данном посте мы разобрали основные команды гита для совсем-совсем начинающих. Конечно, такие серьёзные инструменты, как git, имеют огромную массу возможностей, сложно устроены и бла-бла. Но для начала команд, рассмотренных в данной статье хватит. Обязательно будет продолжение с разбором других команд, которые не раз пригодятся каждому в работе. Но пока не могу обещать точных дат.

Спасибо, что прочитали. Удачи вам в работе и обучении.

До скорого 🐾