Руководство, как оставаться в здравом уме при работе с Git

Git — это сложно. Кроме того, для многих новых разработчиков это первый инструмент с интерфейсом командной строки (CLI), который они используют. Это может быть слишком, если вы изучаете все следующее одновременно:

• как использовать интерфейс командной строки
• как использовать Git
• и последнее, но не менее важное: программирование

В этой статье я покажу вам несколько приемов, которые сделают работу с 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 <marcin.wosinek@gmail.com>
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 <marcin.wosinek@gmail.com>

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 pull

В Git pull объединяет две операции в одну:

• git fetch и
• git merge или git rebaseВ зависимости от вашей конфигурации

Я всегда хочу перепроверить мое удаленное состояние перед слиянием или перебазированием. Итак, мой типичный порядок действий будет таким:

• git fetch — для получения удаленных обновлений
.
• git tree – псевдоним, который я упомянул выше, чтобы убедиться, что репозиторий находится в том состоянии, которое я ожидаю,
• git rebase origin/<branch-name> — при удаленных и локальных изменениях или
• `git merge origin/ — когда есть изменения на удаленном компьютере, но не локально. То есть это можно сделать как быстрое слияние.

Подмодули Git

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

Моя основная проблема с подмодулями Git заключается в том, что они усложняют и без того сложную проблему — контроль версий — и добавляют дополнительные уровни сложности.

Подмодули Git предоставляют альтернативное решение проблемы, которое лучше решать с помощью:

• используя менеджер пакетов (например, npm) для внешних зависимостей
• объединение нескольких репозиториев в один для внутренних зависимостей

Что дальше

В Git много запутанных аспектов, но когда вы его поймете, он станет намного проще. Если вы хотите узнать больше о Git, зарегистрируйтесь здесь, чтобы получать обновления о моем контенте, посвященном Git.< /p>

Первоначально опубликовано здесь