Хорошо, иногда это так, но давайте не будем указывать пальцем и поговорим о гораздо более ценном аспекте обвинений GitLens в VS Code. Почему? Потому что часто, когда я слышу, как люди говорят о GitLens, речь идет об использовании этих функций, чтобы обвинять себя или кого-то еще.

Если вы еще не знакомы с GitLens, пожалуйста, проверьте — вперед, я подожду 😁 — в противном случае не стесняйтесь пропустить следующий раздел.

GitLens — Git с наддувом

GitLens — это расширение с открытым исходным кодом, которое я создал для VS Code. GitLens вместе с поддержкой Git, встроенной в VS Code, предлагает довольно полный графический интерфейс Git непосредственно в вашем редакторе. Вот краткий обзор:

GitLens расширяет возможности Git, встроенные в Visual Studio Code. Это поможет вам визуализировать авторство кода с первого взгляда с помощью аннотаций вины Git и линзы кода, беспрепятственно перемещаться и исследовать репозитории Git, получать ценную информацию с помощью мощные команды сравнения и многое другое.

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

Так что GitLens часто упоминается в контексте обвинения кого-то — хотя в основном это ирония и часто самоуничижение. Помимо очевидного комедийного эффекта, я предполагаю, что это во многом из-за плохого названия функции заголовка — виноват. Хотя GitLens принял это название, потому что так его называют Git и другие инструменты Git (Кто я такой, чтобы противостоять тренду?), эта функция гораздо более ценна, чем просто обвинение себя или кого-то еще. Возможно, вы правильно подумали: «Бу-у-у! Вам просто не нравится, когда вас вызывают за кодом 💩», но выслушайте меня.

GitLens просто помогает вам лучше понимать код. Быстро узнать, кто, почему и когда была изменена строка или блок кода.

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

Я также должен упомянуть, что GitLens предоставляет мгновенные аннотации по запросу для всего файла.

С помощью этих простых аннотаций теперь вы можете ответить на 3 важных вопроса для понимания кода и того, как он развивался: когда код последний раз менялся, почему он менялся и, наконец, >кто изменил его. А за счет повышения наглядности и доступности этой информации, которая всегда была частью наших систем управления версиями, GitLens значительно снижает трудности, связанные с ответами на эти важные вопросы. Теперь, в зависимости от того, чего вы пытаетесь достичь, один из них может быть более важным, чем другие, но все они помогают вам лучше понять код.

Вот лишь несколько простых сценариев:

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

И это лишь некоторые из возможных вариантов использования и преимуществ — я уверен, что вы можете придумать гораздо больше. Эти ответы, которые теперь легко доступны, предоставляют нам мощные инструменты, помогающие лучше понять код. В конце концов, понимание кода — одна из самых сложных проблем в разработке программного обеспечения, после, конечно, двух других: именования, инвалидации кеша и ошибок смещения на 1.

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

Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so. In some contexts, the first
line is treated as the subject of an email and the rest of
the text as the body. The blank line separating the
summary from the body is critical (unless you omit the body
entirely); tools like rebase can get confused if you run
the two together.
Further paragraphs come after blank lines.
 - Bullet points are okay, too
 - Typically a hyphen or asterisk is used for the bullet,
   preceded by a single space, with blank lines in
   between, but conventions vary here
Copied from Distributed Git

Надеюсь, теперь я продемонстрировал, насколько ценнее плохо названное обвинение, чем просто указывать пальцем — трясет кулаком в мою сторону. Итак, если вы еще не пробовали GitLens и/или VS Code, чего же вы ждете? 😄

Первоначально опубликовано на blog.amod.io 15 января 2019 г.