Разница в том, что при использовании git worktree репозиторий по-прежнему остаётся один, отсюда следующие преимущества:
git clone создаст полную копию репозитория, то есть все-все объекты будут выгружены в папку .git, в то время как git worktree выгрузит именно рабочую копию и один-единственный крохотный файл .git с указателем на основной репозиторий. Для больших репозиториев это имеет значение (к примеру, репозиторий одной известной IDE занимает порядка 4 Гб, а рабочая копия ветки, соответствующей одной из версий — всего 800 Мб).
Двумя одинаковыми, но независимыми репозиториями сложнее управлять. Если Вы сделали изменение в одной копии, её надо синхронизировать со второй, чтобы изменения стали в ней видны (и наоборот). Это лишние действия :) Да, иметь две одинаковые рабочие копии (то есть одной и той же ветки) с помощью git worktree запрещено — как раз чтобы не допустить рассинхронизации изменений в этой ветке в рамках одного репозитория. Тем не менее, если в одной рабочей копии сделать какие-то изменения, они тут же становятся видимыми в основном репозитории и во всех остальных его рабочих копиях, потому что хранятся все объекты git только в основной папке репозитория (папка .git есть только там).
Если делать git clone с удалённого репозитория, нужен доступ к нему (а если репозиторий большой, то нужно ещё время и/или хороший канал). Разумеется, можно клонировать с локального репозитория, но тогда у свежесозданного репозитория в качестве remote-ссылки будет этот локальный репозиторий. То есть, снова нужны дополнительные действия по настройке его до такого же состояния. Рабочая же копия, получаемая с помощью git worktree — это только рабочая копия: репозиторий где был, там и остался, так что настраивать ничего не нужно.
Это не значит, что иметь два локальных репозитория с одного и того же remote — плохо. Но есть ряд случаев, когда путь с git worktree проще и удобнее.
Полагаю, в разговорной речи большинство так и говорит: «коммитить», «пушить», «пуллить» и т.д. Это, безусловно, неправильно, но и переходить на «зафиксировать», «протолкнуть», «затянуть» совсем не хочется. В общем, какой-то компромисс…
Именно так и поступает алгоритм pull request-а, описанный в статье. Если интересно, я могу привести точную последовательность git операций, которую выполняет Bitbucket Server для показа диффа pull request-а и для его слива в целевую ветку.
В этой ветке речь зашла о том, какие коммиты хочется видеть в истории: кто-то предпочитает избегать merge-коммитов, кто-то любит историю с одним коммитом на фичу, кому-то больше по душе маленькие авторские коммиты.
Однако задача pull request-а состоит не в том, чтобы организовать коммиты, а в том, чтобы аккуратно и достоверно отобразить, к какому состоянию целевой ветки приведёт сливание его содержимого в неё, и именно её аспекты рассматриваются в этой статье.
Не могу согласиться с тем, что описанный Вами способ проще. Он, на самом деле, очень похож на описанный в статье процесс, за исключением того, что вместо merge-коммита Вы предлагаете разрешать только fast forward. В таком варианте невозможно отобразить, какие именно конфликты произошли, поскольку если они есть, merge вообще не происходит.
Необходимость же повторения этого процесса в случае, если master тем временем изменился, никуда не девается. Это то, что в статье называется пересмотром пулл реквеста (rescope).
Если же Вы имели в виду исключительно ручной процесс, то он не позволяет иметь более одного ревьюера (собственно, выполняющего эти команды), что является сильно урезанным пулл реквестом. Ну, и на более-менее живом проекте придётся делать много рутинных операций, чтобы догонять постоянно убегающий master.
Но при таком условии кто-то ведь всё равно сквошить должен: или создатель коммита, или тот, кто в Вашем сценарии мёржит в master, правильно? Так что это одинаково удобно (или неудобно), на мой взгляд.
Кроме того, сквошить можно в любой момент, даже после ревью, прямо перед слиянием пулл реквеста, — он это спокойно переваривает.
Что касается чистой истории, это вопрос, как Вы отметили, спорный. К тому же, git умеет фильтровать из неё merge коммиты.
Промахнулся веткойЭто не значит, что иметь два локальных репозитория с одного и того же remote — плохо. Но есть ряд случаев, когда путь с git worktree проще и удобнее.
В этой ветке речь зашла о том, какие коммиты хочется видеть в истории: кто-то предпочитает избегать merge-коммитов, кто-то любит историю с одним коммитом на фичу, кому-то больше по душе маленькие авторские коммиты.
Однако задача pull request-а состоит не в том, чтобы организовать коммиты, а в том, чтобы аккуратно и достоверно отобразить, к какому состоянию целевой ветки приведёт сливание его содержимого в неё, и именно её аспекты рассматриваются в этой статье.
Необходимость же повторения этого процесса в случае, если master тем временем изменился, никуда не девается. Это то, что в статье называется пересмотром пулл реквеста (rescope).
Если же Вы имели в виду исключительно ручной процесс, то он не позволяет иметь более одного ревьюера (собственно, выполняющего эти команды), что является сильно урезанным пулл реквестом. Ну, и на более-менее живом проекте придётся делать много рутинных операций, чтобы догонять постоянно убегающий master.
Кроме того, сквошить можно в любой момент, даже после ревью, прямо перед слиянием пулл реквеста, — он это спокойно переваривает.
Что касается чистой истории, это вопрос, как Вы отметили, спорный. К тому же, git умеет фильтровать из неё merge коммиты.