Вы сделали запрос на вытягивание, но он не сливается. Рецензент говорит, что он плохой, или тесты не проходят. В любом случае, вы не можете его добавить в ветку master. Вы продолжаете исправлять ветку, убеждать рецензента, ненавидеть тесты. Остановитесь. Попробуйте более умные тактики.
Сначала fail fast. Быстро отказывайтесь. Если что-то идет не гладко, закройте это. Если жалобы рецензентов связаны не только с стилистическими вопросами, значит, ваше понимание архитектуры ошибочно.
Спросите себя, как это произошло? Почему вы, умный программист, неправильно поняли архитектуру? Очевидно, это не ваша ошибка. Это ошибка в репозитории. Его README не полное, его код недостаточно чистый, его документация устарела.
Что делать? Вините их, отправляя отчеты об ошибках. Затем, когда они исправят репозиторий, попробуйте снова, с новым pull request.
Скорее всего, они не жалуются на все изменения, которые вы внесли. Они что-то считают хорошим, в то время как отказываются принимать что-то другое. Хорошо, уберите плохие части из своего запроса на объединение.
Не тратьте время на попытки продать весь пакет сразу. Вместо этого давайте им столько, сколько они готовы принять. В конце концов, вы объедините несколько запросов на объединение вместо одного. Чем больше, тем лучше, по крайней мере для нас в Zerocracy, где мы вознаграждаем каждый объединенный запрос на объединение.
Это может быть дефект в их существующем кодовой базе. Довольно часто так и есть. Ваш код не может быть объединен, не потому что он сломан, а потому что один из существующих тестов ненадежен. Это сложно, и может стать неприятной ситуацией.
Не впадайте в отрицательные эмоции или раздражение. Вы знаете, что это не ваша вина. Но они этого не знают. Они верят, что ваш код дефектный, а их код идеальный. Более того, все рабочие процессы CI зеленые на мастере, в то время как ваша ветка красная. Кого обвинить? Очевидно, вас.
Вам нужно собрать достаточно доказательств и отправить отчет об ошибке. В нем нужно объяснить, что не так в их мастер-ветке. Никогда не упоминайте свой запрос на объединение. Это ловушка! Если вы попытаетесь использовать свой запрос на объединение как доказательство их ошибок, они не послушают вас.
Забудьте о своем запросе на объединение на время. Отправьте отчет об ошибке так, будто вы чужой, который только что нашел ошибку в мастере.
Это может быть сложно, поскольку мастер зеленый. Тем не менее, нет другого выхода. Опять же, они не послушают вас, если вы обвините их в неудаче вашего запроса на объединение. В лучшем случае они объяснят вам основы непрерывной интеграции.
Как и начинающие игроки в покер (неопытные игроки) пытаются выиграть каждую раздачу, начинающие разработчики пытаются объединить каждый запрос на включение. Это ошибка. Некоторые проблемы просто не могут быть исправлены, и некоторые функции не могут быть реализованы прямо сейчас. На них будет время позже.
Совершенно нормально закрыть запрос на включение после отрицательного обзора. Нет необходимости чувствовать обязанность завершить его. Лучше потратить время на более легкие ошибки для исправления и более простые функции для реализации.
Как бы трудно это ни было, не просите их помочь вам. “Я не могу понять, почему это не объединяется!” Не говорите так.
Они могут помочь, но им будет неприятно. Вы не будете выглядеть надежным программистом. Чем больше вы просите о помощи, тем больше портите свою репутацию. Вы должны уметь решать проблемы самостоятельно.
Неудачное PR - это не провал. Это урок. Быстро терпите неудачу, умело распределяйте вину и двигайтесь дальше, становясь сильнее.
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-11-09 at 16:29
