Продвинутые функции гита, о которых вы, возможно, не знали

Автор оригинала: Martin Heinz
  • Перевод
  • Tutorial

Git – очень мощный инструмент, который практически каждый разработчик должен использовать ежедневно, но для большинства из нас git сводится к нескольким командам: pull commit push. Однако, чтобы быть эффективным, продуктивным и обладать всей мощью git, необходимо знать ещё несколько команд и трюков. Итак, в этой статье мы исследуем функции git, которые просто запомнить, применять и настроить, но которые могут сделать ваше время с git гораздо более приятным.


Прокачиваем базовый рабочий процесс

Прежде чем мы воспользуемся даже самыми базовыми командами – pull, commit и push, необходимо выяснить, что происходит с нашими ветками и изменёнными файлами. Для этого можно воспользоваться git log – довольно известной командой, хотя не все знают, как сделать его вывод на самом деле читабельным и красивым:

Дерево git log.
Дерево git log.

Такой граф даст хороший обзор, однако часто нужно копать немного глубже. Например, посмотреть историю (эволюцию) определённых файлов или даже отдельных функций; в этом поможет git log с флагом -L::).

git log для функции.
git log для функции.

Теперь, когда мы немного представляем происходящее в репозитории, мы, возможно, захотим проверить различия между обновлёнными файлами и последним коммитом. Здесь можно воспользоваться git diff; опять же ничего нового здесь нет, но у diff есть кое-какие опции и флаги, о которых вы, возможно, не знаете. Например, можно сравнить две ветки: git diff branch -a… branch -b, или даже конкретные файлы в разных ветках: `git diff <commit-a> <commit-b> -- <пути>`.

Иногда чтение git diff становится трудной задачей. Можно попробовать прописать игнорирующий все пробельные символы (white-space) флаг -w, и этим немного заспамить diff, или флаг --word-diff и работать вместо строк с раскрашенными словами.

Если простой статичный вывод в оболочке вас не устраивает, можно запустить difftool, вот так: git difftool=vimdiff, команда откроет файлы diff внутри vim в два окна – слева и справа. Очевидно, что Vim – не единственный вариант; можно запустить git difftool --tool-help, чтобы увидеть список всех инструментов, которые можно использовать вместе с diff.

Мы уже видели, как просматривать историю конкретных частей или строк в файла с помощью git log. Было бы удобно делать нечто подобное, например, стейджинг частей файлов, правда? И такое легко делается в в IDE, например, в IntelliJ; то же самое уже сложнее в git CLI, но, конечно же, по-прежнему возможно: в git add пропишите опцию --patch:

Команда открывает редактор, в котором отображается один "hunk" [кусок], представляющий собой кусок кода с несколькими отличающимися друг от друга строками в нём. Можно много чего сделать с этим куском, но самые важные опции – это y – принять изменения (делает стейджинг), n – не принимать (не делать стейджинг) и e – отредактировать кусок перед стейджингом (полный список опций здесь).

Когда закончите с интерактивным стейджингом, вы можете запустить git status, и увидите, что файл с частичным стейджингом находится в разделах "Changes to be committed:" и "Changes not staged for commit:". Кроме того, можно запустить git add -i (интерактивный стейджинг), а затем воспользоваться командой s (статус), которая покажет вам, какие строки находятся на стейджинге, а какие – нет.

Исправление распространённых ошибок

Закончив со стейджингом, я (слишком) часто осознаю, что добавил то, чего добавлять не хотел. Однако на этот случай у git для файлов нет команды un-stage. Чтобы обойти ограничение, можно сбросить репозиторий командой git reset --soft HEAD somefile.txt. Вы также можете включить в git reset флаг -p, который покажет вам тот же UI, что и у git-add -p. Также не забудьте добавить туда флаг --soft, иначе вы сотрёте ваши локальные изменения!

Поменьше грубой силы

Теперь, когда мы закончили стейджинг, всё, что осталось, – commit и push. Но что, если мы забыли что-то добавить или совершили ошибку и хотим исправить уже запушенные коммиты? Есть простое решение, использующее git commit -a и git push --force, но оно может быть довольно опасным, если мы работаем над общей веткой, например, master. Таким образом, чтобы избежать риска перезаписи чужой работы из-за того, что мы решили проблему грубой силой, мы можем воспользоваться флагом --force-with-lease. Этот флаг – в отличие от --force – запушит на изменения только в том случае, если за время работы никто не добавил никаких изменений в ветку. Если ветка изменялась, код не будет отправлен, и этот факт сам по себе указывает на то, что перед отправкой кода мы должны выполнить git pull.

Правильное слияние веток

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

История с ветвлением.
История с ветвлением.

Подход гораздо лучше (не стесняйтесь спорить со мной по этому поводу, образно говоря,  это та высота, на которой я готов умереть) заключается в том, чтобы сделать rebase ветки функции в master, а затем выполнить так называемую быструю перемотку (git merge --ff). Подход сохраняет историю линейной, читать такую историю легче, упрощается и последующий поиск коммитов с новым функционалом и коммитов – виновников ошибок.

Но как нам сделать такой rebase? Можно выполнить rebase в его базовой форме с помощью git rebase master feature_branch, чего часто бывает достаточно (за этим следует push --force). Однако, чтобы получить от git rebase максимальную отдачу, также следует включить флаг -i, чтобы rebase был интерактивным. Интерактивный rebase – удобный инструмент, чтобы, например, переформулировать, сжать или вообще очистить ваши коммиты и всю ветку. В качестве небольшой демонстрации мы можем даже сделать rebase ветки на саму себя:

Приём выше позволяет нам повторно применять последние 4 коммита и изменить их, получив полезный результат, например сжать одни коммиты и переформулировать другие:

Выше показан пример сеанса rebase. В верхней части показывается ветка перед перезагрузкой. Вторая часть фрагмента – это список коммитов, представленных после запуска git rebase …каждый из них можно выбрать, чтобы включить в работу (pick). Мы можем изменить действие для каждого из них, а также полностью переупорядочить коммиты. Как показано в третьем разделе примера, некоторые допустимые действия – переформулирование (оно говорит git открыть редактор сообщений о коммите), сжатие коммита (объединяет коммиты в предыдущий) и исправление коммита: (исправление работает как сжатие, но при этом сбрасывает сообщение о коммите). После того как мы применим эти изменения и переформулируем изменённые коммиты, мы получим историю, которая показана на скриншоте выше, в его нижней части.

Если во время rebase вы столкнулись с каким-либо конфликтом, чтобы разрешить его, вы можете запустить git mergetool --tool=vimdiff, а затем продолжить rebase с помощью git rebase --continue. git mergetool может быть вам не знаком, на первый взгляд он может показаться пугающим. В действительности же это то же самое, что IDE вроде IntelliJ, просто в стиле Vim. Если вы не знаете хотя бы несколько сочетаний клавиш Vim, то, как и в случае с любым другим использующим этот редактор инструментом, вам, может быть, трудно даже понять, на что на самом деле вы смотрите. Если вам нужна помощь, я рекомендую прочитать эту исчерпывающую статью.

Если всё это кажется слишком сложным или вы просто боитесь работать с rebase, в качестве альтернативы создайте пул реквест на GitHub и нажмите кнопку Rebase and merge, чтобы сделать, по крайней мере, простые и быстрые rebase и merge с быстрой перемоткой.

Главное – эффективность

Я думаю, что примеры выше показали несколько изящных советов и хитростей, но всё это может быть довольно сложно запомнить, особенно когда дело касается команд вроде git log. К счастью, чтобы разрешить эти трудности, можно воспользоваться глобальной конфигурацией git. Она находится в ~/.gitconfig и обновляется каждый раз, когда вы запускаете git config --global. Даже если вы не настраивали этот файл, он, вероятно, содержит кое-какие базовые вещи, такие как раздел [user], но можно добавить много других разделов:

Выше приведён пример некоторых из доступных опций конфигурации. Примечательно, что длинная команда git log – это только псевдоним git graph. Автокоррекция установлена 10: такое значение включает её и заставляет ждать 1 секунду, прежде чем выполнить правильную команду, в которой была опечатка, и, наконец, последний раздел – подписывание коммита GPG (подробнее об этом читайте ниже).

Настройка .gitconfig с кучей алиасов требует отдельной статьи. Есть довольно много хороших ресурсов и примеров того, что можно прописать в .gitconfig, поэтому вместо полного списка всех опций и псевдонимов я оставлю ссылки:

Автозавершение команд – это инструмент не менее продуктивный, чем псевдонимы, и он просто устанавливается: 

Extras

Можно не только писать свои псевдонимы, но и взять на вооружение плагин git-extras, он вводит много полезных команд, которые могут немного упростить вам жизнь. Я не буду вдаваться в подробности обо всех возможностях этого плагина – посмотрите список команд, а я просто покажу один краткий пример из этого списка прямо здесь:

  • git delta – список файлов, которые в другой ветке отличаются.

  • git show-tree – древовидное представление коммитов всех ветвей, похожее на показанный ранее git log.

  • git pull-request – пул-реквест в командной строке.

  • git changelog – генерирует журнал изменений (changelog) из тегов и сообщений в коммитах.

Конечно, это не единственный крутой плагин. Например, есть ещё один удобный инструмент, позволяющий открыть репозиторий в браузере прямо из командной строки. Кроме того, в приглашении терминала можно настроить статус репозитория, это делается с помощью zsh или bash-it.

Подписываем коммиты

Даже если вы никогда не вкладывались в какой-либо проект Open Source, вы, вероятно, прокручивали историю коммитов такого проекта. В ней вы, скорее всего, видели значок подтверждённого (sign-off – знак о правах на ПО), проверенного или подписанного коммита. Что это такое и зачем?

Первый значок используется, когда автор подтверждает, что соответствующий код написал именно он, или же значком вы подтверждаете, что, насколько вам известно, он был создан на основе соответствующей лицензии Open Source. Это делается по юридическим причинам, которые связаны со статусом авторских прав на код. Обычно вам не нужно пользоваться этим значком, но, если вы в какой-то момент захотите внести вклад в проект, который требует подтверждения прав, знак подтверждения ставится так:

Сверху видно, что в git commit с опцией --sign-off в конце сообщения о коммите автоматически добавляется строка Signed-off-by: …, которая формируется на основе вашего имени пользователя в конфигурации git.

Что касается значка signed/verified, который вы, вероятно, заметили в некоторых репозиториях, он существует, потому что на GitHub довольно легко выдавать себя за других пользователей. Всё, что вам нужно сделать, – изменить имя сделавшего коммит человека и электронную почту в вашей конфигурации и отправить изменения. Чтобы предупредить ситуацию, вы можете подписывать коммиты с помощью ключей GPG, подтверждающих, что автор коммита и отправитель изменений на самом деле является тем, за кого он себя выдаёт. Подпись коммита более распространена, чем подтверждение прав, поскольку важно знать, кто на самом деле внёс код.

Если вы хотите начать пользоваться этой функцией или, возможно, хотите внедрить её в вашей команде, можно сделать следующее:

Сначала вы генерируете пару ключей GPG (если у вас её ещё нет), затем устанавливаете ключи при помощи git config … и, наконец, добавляете опцию -S, когда делаете коммит. Затем, посмотрев на информацию о коммите на GitHub, вы увидите значок, как на картинке ниже.

Подписанный непроверенный коммит.
Подписанный непроверенный коммит.

Однако, как видно на изображении, подпись не проверена, потому что GitHub не знает, что ключ GPG принадлежит вам. Чтобы это исправить, открытый ключ из нашей пары ключей нужно отправить на GitHub. Для этого экспортируем ключ командой gpg --export, как здесь:

Затем скопируйте этот ключ и вставите его в поле https://github.com/settings/gpg/new. Если вы проверите ранее подписанный коммит после добавления ключа, то увидите, что коммит теперь проверен (verified). Здесь предполагаем, что вы добавили на GitHub именно тот ключ, которым подписывали коммит:

Подписанный проверенный коммит.
Подписанный проверенный коммит.

Заключение

Git – очень мощный инструмент, у которого слишком много подкоманд и опций, чтобы в одной статье описать их все. Если вы хотите глубже погрузиться в некоторые связанные с Git темы, я бы порекомендовал прочитать Debugging with Git, чтобы узнать больше о blame, bisect или Getting solid at Git rebase vs. merge, чтобы глубже понять rebase и merge. Помимо множества полезных статей в Интернете часто при поиске информации о некоторых тонкостях git лучший выбор – это мануал, который выводится опцией --help, или версия в сети.


Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодом HABR, который даст еще +10% скидки на обучение.

SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Комментарии 17

    +6
    Примерно то, что каждый день и так используем в нашей команде, все ожидаемо =). Пара комментов:

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

    git pull-request


    Сходил, я уж думал, неужели наконец GH придумал что-то стоящее. Но нет, «за кулисами» там простой curl, использующий API токен :( Для сравнения, как это сделано в Gitlab — обычными push options, которые гит поддерживает из коробки. git push ... -o merge_request.create -o merge_request.title="My Wonderful MR"

    Ну а в целом алиасы — это примерно то, что в первую рабочую неделю новому разработчику показывается в рамках вводного тренинга по гиту: если чел уже все знает и у него свои алиасы устоявшиеся, то все ок, введем в курс тех, которые у нас в некотором смысле «общие», но никого не заставляем. Но обычно люди не знают гит на том уровне, на котором мы ведем разработку, поэтому предлагается взять наши командные алиасы как «основу» (естественно, с объяснениями, что магии там нет и что за ними стоит), а дальше отпускаем в вольное плавание.
      +4

      Я юзаю pull, merge, commit и push 99.99 процентов времени уже лет пять.
      Что за мега процессы такие, что приходится пользоваться всякими эзотерическими командами?

        0
        мега процессы
        это процессы, в которых участвует не один разработчик.
          0

          Я работаю не один. Вас не затруднит привести пример юзкейса, так сказать?

            0
            «не один» — это, конечно, фигура речи. Речь идёт о достаточно большом коллективе человек хотя бы десять-двадцать), где несколько групп разрабатывают несколько совместно поставляемых приложений. В таких случаях только простейшими операциями уже не обойтись.
              +3

              Вместо того, чтобы границу в 1 человека переносить на коллектив из 10–20 людей (а в следующем комментарии — на компанию в 200+ человек), лучше бы рассказали welovelain про варианты использования, выходящие за пределы pull/add/commit/push/merge:


              • git stash для временного сохранения изменений
              • git rebase -i для причёсывания коммитов во время разработки
              • git reset во всех своих ипостасях (откат, разбиение коммитов, и т. д.)
              • git reflog для отката своего репозитория, если случайно ветку
              • git cherry-pick для бекпортирования отдельных изменений в долгоживущие ветки
              • git range-diff для ревью изменений между версиями ветки
              • git bisect для поиска коммита, вносящего баг
              • git revert для отката изменений, вносящих баги
              • git log -S для поиска коммита по диффу
              • git rerere для особо долбанутых мерджей с конфликтами
          0
          А мы в нашей команде используем git merge примерно никогда. Замените ваш merge на наш rebase — вот и получите флоу, которое описывал автор поста.

          Разработка чего угодно больше одного коммита в своей ветке -> и вот и git rebase --interactive. За день используется несколько раз, когда активный кодинг идет.
          Второй разработчик влил в мастер — вот и git rebase. Повторить каждое утро над своей фиче-веткой, над которой работаешь сейчас.
          git graph как алиас — ну это просто по частоте используется даже чаще, чем git status.

          А больше никакого рокет сайнса то вроде в статье и не описано? --force-with-lease иногда, когда знаешь, что не один над веткой работаешь и не уверен, не запушил ли товарищ что-то, пока ты думал. add -p — ну примерно раз в месяц использую, когда хочу изменения в одном файле разбить на два коммита.
        +2
        Каждый раз при интерактивном ребейзе я не могу вспомнить, сверху самый первый коммит в списке или снизу. С этим что-нибудь можно сделать? Я вообще такой один?
          0
          Не один, у меня та же история каждый раз.
            +2

            Смотрите на список не как на "список коммитов", а как на "список команд". Тогда будет понятно, что они расположены в "естественном" порядке, сверху вниз:


            • применить патч x
            • применить патч y
            • применить патч z

            Меняем строчки местами — меняется порядок команд. Добавляем свои команды (например, exec), и они выполнятся в общем порядке.


            И вообще, если не спешить и поглядывать в комментарии (по крайней мере, в консольном клиенте они есть), то можно заметить контекстную справку, в которой всё это написано:


            pick ...
            pick ...
            
            # These lines can be re-ordered; they are executed from top to bottom.

            Каждый раз перед глазами при ребэйзе.

            +1

            "… git commit -a и git push --force ..." — вы, кажется, перепутали.
            Имелся в виду git commit --amend.


            git commit -a (он же --all) означает "сделать перед коммитом git add --update, то есть, внести все изменения отслеживаемых файлов в индекс.

              +1

              Вы так пугаете людей, что если два человека вносили изменения в мастер из разных веток, то без ребейза вам придётся делать мердж-коммит.
              А, хочу спросить, — если у вас только одна ветка, — вам что, не придётся делать мержд-коммит?!


              Или вы предлагаете просто каждый раз переназначать голову мастера на голову вашей ветки?


              Плюсы такого подхода: исключительно линейная история.
              Минусы:


              • заставляете всех разработчиков всегда ребейзиться на голову мастера
              • если не было явных конфликтов при ребейзе, то теряется история разработки: кажется, что человек внёс правки относительно самого свежего на тот момент состояния мастера
              • откатывать ветку становится весёлой затеей (вместо отката одного мердж-коммита)
              • в мастере будут не только совершенные коммиты, но и всякий хлам — очепятки, забытые файлы и тому подобное; нельзя просто так взять и встать на произвольный коммит, чтоб не получить дурацкие проблемы
              • из-за этого ломается бисекция какого-нибудь бага: нет такого, что "до некоего коммита всё хорошо, потом всё плохо"; наверняка там будет "хорошо… не компилируется… не работает… не компилируется… хорошо… плохо… хорошо… не компилируется… плохо".
              • внесение изменений из мастера в продуктовую ветку — вместо черри-пика одного мердж-коммита потребует черри-пик пачки коммитов от и до (и смотрите, не ошибитесь, где рабочая ветка началась и где закончилась).

              В общем: умные люди зачем-то сделали функцию мердж-коммита, а вы оказались умнее и отказались от неё.


              Вот делать pull с мерджем (если вы работаете в одной ветке в нескольких локальных репозиториях, например), — это да, сделает вам адок в истории. Тут ребейз пригодится.


              Или если мердж с конфликтами. Лучше потратить время и сделать ребейз (то есть, по-новой внести исправления), чем воевать между старыми исправлениями и новыми условиями.

                +1
                Или вы предлагаете просто каждый раз переназначать голову мастера на голову вашей ветки?

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


                Кроме того, сохраняется плюшка, что все изменения идут одним куском. Из других преимуществ подхода: rebase почти никогда не нужен. Конфликты с master? Мерджишь master к себе, решаешь их — один раз — и всё.


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


                заставляете всех разработчиков всегда ребейзиться на голову мастера

                CI-сервис сделает это автоматически. Только в случае конфликтов надо теребить человека, чтобы он их порешал.


                если не было явных конфликтов при ребейзе, то теряется история разработки

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


                откатывать ветку становится весёлой затеей (вместо отката одного мердж-коммита)

                внесение изменений из мастера в продуктовую ветку — вместо черри-пика одного мердж-коммита

                Если сквошить изменения, то эти варианты решаются так же просто, как и с «настоящим» мерджем. Даже наверное проще, так как скорее всего не придётся указывать базовую ветку.


                в мастере будут не только совершенные коммиты, но и всякий хлам

                из-за этого ломается бисекция какого-нибудь бага

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


                И опять же, в случае сквоша — неревантно, там будет один ровно коммит, сколько бы хлама в ветке не было.


                В общем: умные люди зачем-то сделали функцию мердж-коммита, а вы оказались умнее и отказались от неё.

                У умных людей из Linux немного другой процесс: с тысячами разработчиков, иерархией репозиториев и ответственности. Не у всех так же, не всем нужен этот оверхед, и не все привыкли делать так. А когда привыкаешь — переучиваться сложно. Особенно если тебе надо будет переучить ещё и свою команду, а вы все работаете за деньги на кого-то другого, и совсем не очевидно, зачем тратить деньги сейчас на «идеологически правильный» процесс, если и так всё работает.

                  0
                  И опять же, в случае сквоша — неревантно, там будет один ровно коммит, сколько бы хлама в ветке не было.

                  И в котором невозможно понять, что происходило и как. Команде же (возможно, тем же людям) придётся уже через пару месяцев разбираться, что же они меняли и почему.


                  Я не представляю себе, кому и как может сойти такой стиль, кроме как "мы свои $0.05 вложили, а там хоть трава не расти, мы уже все перейдём в соседний проект на +500".


                  Не у всех так же, не всем нужен этот оверхед, и не все привыкли делать так. А когда привыкаешь — переучиваться сложно.

                  "Этʼ точно" ([Сухов]). :(

                    0
                    И в котором невозможно понять, что происходило и как.

                    Сквошить коммиты — это не означает, что надо делать один коммит в неделю с содержанием Моя работа с 1 по 5 марта. При сквош-мердже в итоговый комментарий можно добавить весь нужный контекст, с той красотой, которая нужна. История разработки этого коммита остаётся в «пулл-реквесте» или что там используется для ревью, если нужно уж прям закапываться. Если нужно ещё глубже — код обычно связан с каким-то тикетом в тикетнице, где можно найти ещё больше контекста.


                    Примеры:
                    https://github.com/cossacklabs/acra/commit/c9c8825abe247b8f674917bc493dc7f072fe2549
                    https://github.com/cossacklabs/acra/pull/419


                    Конечно, если комментарии оставлять как попало, то там будет как попало:
                    https://github.com/cossacklabs/acra/commit/d35c6dc421cf8ef016d01afb07c480a2b5393e41


                    Я не представляю себе, кому и как может сойти такой стиль, кроме как "мы свои $0.05 вложили, а там хоть трава не расти, мы уже все перейдём в соседний проект на +500".

                    Вот об этом и говорю, упоминая политическую волю. Если у человека проект, с которого он может легко прыгнуть на +500, то в отсутствие внутренней мотивации «делать красиво», от толковых комментариев лично этому разработчику ни тепло ни холодно. И тут всё зависит от сопроводжающего проект, будет ли он настаивать на качественной истории, если для этого надо потратить N времени на её причёсывание и всё это «впустую». Потому что история коммитов — она как парашют: когда не нужна, то мешается и не помогает; но вот когда нужна, а её нет, то становится очень плохо.

                      0
                      Примеры:
                      https://github.com/cossacklabs/acra/commit/c9c8825abe247b8f674917bc493dc7f072fe2549

                      Ну вот это вы относительно хороший пример привели; и то, объём достаточно заметен, и при анализе "а что же это было?" сразу может возникать вопрос — а точно ли набор изменений в итоговом сжатом коммите соответствует исходному? это ещё проверить надо, если подозрение, что этот коммит вызвал проблему. При раздельных коммитах на подфичи такого вопроса не возникает. 200 строк изменений — ещё разумное предельное количество.


                      А вот второй пример на 2200 строк — это уже случай, не поддающийся визуальной верификации (кроме как если это результат какого-то легко воспроизводимого автоматического изменения).


                      А вот когда смешивается, например, перереформатирование всяких отступов и отделений (да, в Go это нетипично, но не он один), пара рефакторингов, и наконец финальная фича… и всё это потом склеено в один коммит — разбираться в полученной каше, мягко говоря, нереально. Мне приходилось спорить с категорическими сторонниками таких подходов, и я был слегка в ужасе (и рад, что они со мной не работают).


                      И тут всё зависит от сопроводжающего проект, будет ли он настаивать на качественной истории, если для этого надо потратить N времени на её причёсывание и всё это «впустую».

                      У меня практически нулевой опыт с "галерами": только продуктовые компании. В них нормально, что кто-то работает год-два, а кто-то и 20; в общем, peer review следит за тем, чтобы каждый отдельный коммит был понятным. Ну и нам помогает то, что ценность понимания тематики важнее ценности понимания инструментов. Для типовой аутсорс/аутстафф-галеры, вероятно, это и не так — там требуются суперусилия заставить людей грамотно делить и описывать, и обычно эти усилия не применяются, интересует только чтобы результат проходил тесты… :(


                      Потому я таки счёл нужным оставить свои аргументы в истории этого обсуждения.

                0

                [del]

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое