Главное неудобство Github — Pull Requests
Я пользуюсь Github очень часто, на нём лежат все мои публичные и приватные проекты, даже этот блог. И гитхаб крутой: хорошая система ревью, встроенный CI (также можно назвать Github Actions?), таск-трекер и вики. Гитхаб нашё всё для любого разработчика и стоит на втором месте после stackoverflow.
Однако я не могу назвать его в полной мере удобным. Есть одна ложка дёгтя.
И это пул-реквесты (PR).
Хорошо про них написал Никита в треде:
I don’t really get Github workflow. Never did. So I want to make a PR, I have to clone a repo, make my changes, file a PR and then KEEP that repo around? Until PR is merged? And if it’s merged, I’m left with an unnecessary repo under my account which I then have to go and delete?
— Niki Tonsky (@nikitonsky) December 24, 2019
Создание PR напоминает пытку, особенно, когда размер фикса стремится к минимальному. Вспомните весь процесс PR и представьте, что вы хотите поправить опечатку.
В списке репозиториев пользователя по умолчанию представлено всё, включая форки. А с учётом воркфлоу для создания PR – процентное соотношение обычно больше у форков. Конечно, есть фильтр, только вот включать его каждый раз не шибко хочется.
Критикуй – предлагай. Ок, решение с PR в гитхабе выглядит правильно (это не отрицает мои слова про неудобство). Негодование вызывают форки и обязательность их создания.
Никита предложил решением ветки, и это на мой взгляд самое прекрасное решение. Но оно трудозатратно, если учесть накопившийся у всех груз форков, старых PR, да и будут проблемы с переобучением. Хотя… оно того стоит.
- PR с временным форком. После создания полноценного PR и его мёржа в целевой репозиторий, временный форк удаляется. Временные форки не отображаются в публичных списках пользователя, видны только ему и при переходе по прямой ссылке. В случае отклонения PR есть возможность быстро удалить временный форк, в идеале в один клик с подтверждением.
- быстрый PR — возможность создать PR во внутреннем редакторе прямо в целевом репозитории. При этом может автоматически создаваться временный форк.
Вряд ли гитхаб в ближайшее время что-то изменит. Даже если он сделает кардинально лучше, это может повлечь волну негодования от старичков, а этого Майкрософту сейчас не нужно.
Может быть, когда-нибудь. Может быть.
P.S. Второй пост про гитхаб подряд. Вот что работа над темой блога со мной делает.