Выйдите за рамки команд Git, создайте привычки Git!

Во время кофе-брейка с моими старшими коллегами в CERN мы обсудили навыки, на которые они обращают внимание при найме новых членов в свои компьютерные команды. Поскольку ЦЕРН активно участвует в проектах с открытым исходным кодом, знание Git является обязательным.

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

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

Итак, выпейте чашечку кофе и давайте углубимся в пять привычек Git, которые сделают вас опытным участником!

#1 Поддерживайте согласованность истории Git

Хотя мы все знакомы с лучшими практиками написания кратких и описательных сообщений о коммитах — содержательных сообщений длиной менее 72 символовs-, мы все были виновны в поспешном внесении изменений с расплывчатыми сообщениями вроде « update somefile.py». К счастью, есть удобная команда Git, которая позволяет нам исправить эти ошибки, так называемая git squash.

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

Просто имейте в виду, что последний git push --force может перезаписать изменения в удаленном репозитории.

Давайте посмотрим, как git squash работает на практике:

Забота об истории вашего проекта — это признак профессионализма, и теперь вы знаете, что старшие разработчики будут изучать вашу историю коммитов… Пришло время произвести на них впечатление!

#2 Не используйте устаревшие команды

Быть знакомым с технологией означает быть в курсе новых функций и улучшений инструмента. В контексте Git команда git checkout является одной из широко используемых устаревших команд для переключения и создания веток.

Больше никаких команд оформления заказа!

Используйте git switch вместо команды checkout для безопасного переключения между ветвями. Вот пример того, как это работает:

Дополнительный совет. Если вам нужно переключиться на предыдущую ветвь, имейте в виду, что git switch — сделает эту работу. Да, например аналогия с bashcd —.

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

Давайте посмотрим, как создавать и переключать ветки с помощью соответствующей команды:

Команда git switch более интуитивно понятна, чем старая команда git checkout, поскольку она разработана специально для переключения между ветвями. Он также более надежен и безопасен в использовании, так как предотвращает случайную проверку отсоединенного состояния HEAD, что может сбивать с толку и быть опасным, и обычно происходит непреднамеренно.

И что такое состояние Detached HEAD?

В Git отключенное состояние HEAD возникает, когда вы извлекаете определенный коммит вместо ветки. В этом состоянии ссылка HEAD, которая указывает на проверенную в данный момент ветку, указывает непосредственно на хэш коммита, а не на имя ветки.

В этом состоянии вы можете вносить изменения в файлы в вашем рабочем каталоге и фиксировать их, как обычно. Однако эти изменения не будут связаны с какой-либо веткой и не будут частью истории ветки. Это означает, что если вы переключитесь на другую ветку или создадите новую ветку в состоянии отсоединенной головы, ваши изменения останутся позади и могут быть потеряны.

Отсоединенное состояние заголовка может возникать в нескольких ситуациях, например, когда вы извлекаете конкретный хэш коммита, используете git checkout без указания ветки или коммита или извлекаете тег вместо ветки, среди других нежелательных ошибок.

# 3 Выберите свой собственный риск во время фиксации

Многие из нас, возможно, сталкивались с добавлением git/удалением множества файлов перед фиксацией. Тем не менее, есть несколько флагов, которые можно использовать для ускорения процесса. Опытный участник должен знать о самых быстрых и самых медленных способах сделать это в случае необходимости.

Добавить/удалить и зафиксировать одновременно

Используйте git commit -a(--all) -m <commit message> для автоматического добавления изменений из всех известных файлов, т. е. всех файлов, которые уже перечислены в индексе, и для автоматического rm файлов в индексе, которые были удалены из рабочее дерево. Затем можно выполнить фактическую фиксацию с соответствующим сообщением фиксации -m одновременно, как в следующем примере:

Аккуратно добавляйте свои изменения перед фиксацией

Вместо добавления всех модификаций в файл используйте git add -p(--patch) для интерактивного выбора отдельных модификаций и добавления их в индекс. Это дает вам возможность просмотреть измененный контент перед его добавлением. Целью этой опции является выбор строк измененного содержимого, так называемого исправления, для применения или даже изменения содержимого этих строк перед их добавлением.

Давайте посмотрим, как это работает на примере файла с тремя удаленными строками. Представьте, что нас интересует только удаление последней строки. Можно использовать git add -p и размещать только последний фрагмент, не теряя и не добавляя другие изменения:

Рискуйте (commit -a) или делайте это постепенно (add -p).

#4 Не создавайте новые коммиты, чтобы отменить изменения

Если вы понимаете, что допустили ошибку в своем последнем коммите, например опечатку в сообщении коммита или забыли добавить файл, вы можете использовать флаг git commit --amend для изменения коммита. Вот теория:

Флаг --amend создает новую фиксацию, которая заменяет предыдущую. Это полезно для внесения небольших изменений в последний коммит, не загромождая историю коммитов ненужными коммитами. Однако будьте осторожны при его использовании, если вы уже отправили предыдущую фиксацию в удаленный репозиторий, так как это может вызвать проблемы для всех, кто вытащил предыдущую фиксацию.

Давайте посмотрим на реальный пример исправления сообщения коммита:

Обратите внимание, что с помощью этой команды вы можете избежать заполнения истории git сообщениями «Отменить предыдущую фиксацию».

Правда, специалисты тоже ошибаются. Разница заключается в знании того, как их исправить.

# 5 Будьте в курсе также в терминологии

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

Одно из первых упоминаний рабства в Git было в команде git push, которая изначально использовала термин slave для обозначения удаленного репозитория.

Многие сочли это упоминание оскорбительным, поскольку оно напоминало историю рабства и принудительного труда людей. В ответ на эти опасения сообщество Git решило заменить термин slave на remote в команде git push. Например, изначально команда push изменений в ветке master была написана как git push slave master . В новом синтаксисе команда заменена на git push remote master.

Кроме того, использование термина master в качестве имени ветки по умолчанию также было предметом обсуждения в сообществе, поскольку оно снова может вызывать ассоциации с историей рабства, где термин хозяин использовался для обозначения владелец порабощенных лиц.

Решение о названии ветки остается за отдельными разработчиками и организациями, но важно помнить о потенциальном влиянии этого выбора. И наверняка есть более нейтральные альтернативы, такие как main (рекламируется GitHub), primary или default.

Дополнительный совет, если вы используете поиск GitHub

Поиск символов в GitHub может превратиться в кошмар.

Чтобы не нервничать, измените URL своего репозитория с github.com на github.dev в браузере, чтобы переключиться на среду разработки GitHub. Веб-редактор github.dev может упростить и ускорить ваш рабочий процесс, а также выполнить более полный поиск символов.

Следите за грядущими функциями поиска кода и просмотра кода в GitHub. В этом новом выпуске представлена ​​расширенная система поиска кода GitHub для улучшения результатов поиска на GitHub.com, а также обновленный интерфейс просмотра кода с несколькими новыми функциями, включая панель дерева для просмотра файлов, поиск по символам, нечеткий поиск файлов, фиксированные заголовки кода и гораздо более!

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

Не стесняйтесь комментировать любую другую привычку к Git, которая у вас есть!

Дайте мне знать, если вы хотите, чтобы я написал больше о Git, и не стесняйтесь пересылать любые вопросы, которые могут возникнуть у вас по адресу [email protected] :)

Вы также можете подписаться на мою Информационную рассылку, чтобы быть в курсе новых материалов. Спасибо!

Повышение уровня кодирования

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

  • 👏 Хлопайте за историю и подписывайтесь на автора 👉
  • 📰 Смотрите больше контента в публикации Level Up Coding
  • 💰 Бесплатный курс собеседования по программированию ⇒ Просмотреть курс
  • 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"

🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу