Гит это сложно. Кроме того, для многих новых разработчиков это первый инструмент с интерфейсом командной строки (CLI), который они используют. Это может быть слишком много, если вы изучаете все следующее одновременно:
- как использовать интерфейс командной строки
- как использовать гит
- и последнее, но не менее важное: программирование
В этой статье я покажу вам несколько приемов, которые сделают ваш опыт работы с Git менее болезненным и более увлекательным!
Проверьте свое состояние
Git достаточно щедр, чтобы предложить множество команд для проверки состояния вашего репозитория, и в то же время достаточно предусмотрителен, чтобы не перегружать новичка многословием. Короче говоря, вы должны попросить Git предоставить вам необходимые детали. Для этого у вас есть следующая команда:
статус git
Ключевая команда, чтобы получить представление о том, где вы находитесь в Git. Пример выходных данных:
$ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean
когда вы находитесь на чистой ветке и в курсе
$ git status HEAD detached at abc01e7 nothing to commit, working tree clean
когда вы находитесь в отключенном состоянии HEAD.
$ git status
On branch main
Your branch is up to date with 'origin/main'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
lorem-ipsum.txt
nothing added to commit but untracked files present (use "git add" to track)
Когда у вас есть несколько новых файлов в вашей рабочей копии.
git-шоу
Это команда, которая позволяет вам увидеть изменения, произошедшие в коммите. При запуске без аргумента показывает текущую фиксацию:
$ git show commit abc01e761cb9cc14c4d5aecae2488810c834c0f9 (HEAD -> main, origin/main, origin/HEAD) Author: Marcin Wosinek <[email protected]> Date: Wed Nov 2 11:57:33 2022 +0100 Add lorem ipsum to readme diff --git a/README.md b/README.md index 8ae0569..9dca8b4 100644 --- a/README.md +++ b/README.md @@ -1 +1,2 @@ # Test +Lorem ipsum
Вы получаете все подробности о коммите: его автор, время, сообщение и различия каждого файла, который был изменен.
Вы можете указать любой коммит, который хотите увидеть:
$ $ git show edd3504 commit edd3504f6edc722482fa4383443fa1729acc9a87 …rest of the output…
Примечание! Эта команда работает с коммитами. Таким образом, если вы используете имя ветки, оно покажет самую последнюю фиксацию из этой ветки:
$ git show main commit abc01e761cb9cc14c4d5aecae2488810c834c0f9 (HEAD -> main, origin/main, origin/HEAD) Author: Marcin Wosinek <[email protected]>
git tree — собственный псевдоним, который я всем рекомендую
Для просмотра графа всех ветвей рекомендую задать алиас дерева — подробнее об этом можно узнать в этой статье. С его помощью вы можете запустить:
$ $ git tree * 11f7f3c (test) add test.txt file | * 2dbd30f (origin/test) add test.txt file | * e7be203 (test-2) add new file |/ * abc01e7 (HEAD -> main, origin/main, origin/HEAD) Add lorem ipsum to readme * edd3504 Add readme
И получить хороший обзор всего репозитория.
Проверьте, какой у вас редактор по умолчанию
В некоторых случаях Git хочет, чтобы вы вводили данные, редактируя созданный им временный файл. Поначалу этот рабочий процесс может сбивать с толку, особенно если вы не знаете редактор по умолчанию. Вот как это проверить, перечислив логические переменные Git и отфильтровав из них ту, которая содержит EDITOR. В моей MacOS это vi:
$ git var -l | grep EDITOR GIT_EDITOR=vi
Аналогично в Ubuntu:
$ git var -l | grep EDITOR GIT_EDITOR=editor
В Ubuntu editor — это команда, которая запускает то, что настроено как ваш текстовый редактор по умолчанию. На одной машине, к которой у меня есть доступ, это nano:
$ update-alternatives --display editor editor - auto mode link best version is /bin/nano link currently points to /bin/nano …
Независимо от вашего редактора, убедитесь, что вы знаете, как делать следующие вещи:
- отредактируйте файл, что может быть сложно для новичков в
Vimиз-за различных режимов его интерфейса - сохранить изменения
- выйти из редактора
Или измените редактор на что-то, что вы знаете, как использовать.
Используйте вкладку при вводе команд
Команды Git, все атрибуты и имена веток длинные; и интерфейс не допускает ошибок. Ключевой трюк повышения производительности — не печатать их целиком. В большинстве оболочек, когда вы нажимаете клавишу табуляции, оболочка либо:
- показывает вам все доступные автозавершения команд
- выбирает команду, если доступна только одна
Итак, например, с оболочкой zsh, которую я использую, давайте посмотрим на эти параметры после ввода git co<tab>:
$ git co Completing main porcelain command commit -- record changes to repository Completing ancillary manipulator command config -- get and set repository or global options Completing ancillary interrogator command count-objects -- count unpacked objects and display their disk consumption Completing plumbing manipulator command commit-graph -- write and verify Git commit-graph files commit-tree -- create new commit object Completing plumbing internal helper command column -- display data in columns
И просто завершите слово, когда я наберу git com<tab>:
$ git commit
Точно так же он обеспечивает автозаполнение для параметров, имен ветвей и т. д. Это имеет большое значение при наборе текста.
Используйте стрелки
Смотреть, как кто-то повторяет всю команду, которую он использовал несколько минут назад, — болезненный опыт. Большинство оболочек позволяют повторно использовать последнюю команду, просто используя клавиши со стрелками. Стрелка вверх выводит самую последнюю команду, вы вводите ее снова, чтобы получить предыдущую, и так далее. Найдя нужный, вы можете отредактировать его, чтобы он соответствовал операции, которую вы выполняете прямо сейчас.
Постоянно получайте удаленные изменения
Я постоянно синхронизирую свой локальный репозиторий с удаленным — даже в своих личных репозиториях, где я знаю, что работаю один. Слишком легко все испортить, не обращая внимания на то, что меняют другие. И требуется всего одна команда, чтобы убедиться, что все в актуальном состоянии:
$ git fetch
После его запуска вы знаете, что каждая ссылка origin/<branch-name>, которую вы видите локально, находится в том же месте, что и удаленно.
Конфликты иногда очень болезненно исправлять, но нет ничего более болезненного, чем конфликты, которых можно было бы легко избежать. Один из распространенных сценариев, когда люди создают ненужный конфликт, — это запуск новой ветки после самой последней фиксации. Этого легко избежать, если:
- делать выборку все время
- обращая внимание на то, где вы находитесь в дереве истории
Короткоживущие ветки
Наличие веток, которые быстро объединяются, имеет несколько преимуществ:
- новые функции быстрее интегрируются в кодовую базу. Если они не совсем готовы, их всегда можно скрыть флажком фичи.
- меньшее количество изменений как в основной, так и в другой ветке означает меньший риск конфликтов,
- меньшие ветки означают меньше кода для проверки.
Краткосрочные ветки — это способ прогресса посредством небольших взаимодействий — то, что я рекомендую в другой статье.
Чего следует избегать
Я часто вижу, как новички приходят с проблемами, с которыми мне обычно не приходится иметь дело, потому что я избегаю следующих вещей в Git:
git тянуть
В Git pull объединяет две операции в одну:
Я всегда хочу перепроверить свое удаленное состояние перед выполнением слияния или перебазирования. Итак, мой типичный поток будет таким:
git fetch-для получения обновлений удаленно,git tree-псевдоним, который я упомянул выше, чтобы убедиться, что репо находится в том состоянии, в котором я ожидаю,git rebase origin/<branch-name>-когда есть изменения на удаленке и локально, или- `git merge origin/ — когда есть изменения на удаленном компьютере, но не локально. То есть это можно сделать как быстрое слияние вперед.
Подмодули Git
Наконец, подмодули — это способ встраивания репозитория или репозиториев Git внутрь другого. Внутренний репозиторий поддерживает свою отдельную историю, тогда как содержащий его хранит только ссылку на источник и текущую фиксацию, в которой должен находиться внутренний репо.
Моя главная проблема с подмодулями Git заключается в том, что они усложняют и без того сложную проблему контроля версий и добавляют больше уровней сложности.
Подмодули Git предоставляют альтернативное решение проблемы, которое лучше решать с помощью:
- использование некоторого менеджера пакетов (например, npm) для внешних зависимостей
- объединение нескольких репозиториев в один для внутренних зависимостей
Что дальше
Git имеет много запутанных аспектов, когда вы начинаете его использовать, но он становится намного проще, когда вы его понимаете. Если вы хотите узнать больше о Git, подпишитесь здесь, чтобы получать обновления о моем контенте, посвященном Git.
Первоначально опубликовано на https://how-to.dev.
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord . Заинтересованы в хакинге роста? Ознакомьтесь с разделом Схема.
