Относительно толчка мерзавца

Question

Я клонировал репозиторий на свой локальный компьютер. Затем я создал новую ветку (из текущего master), используя git checkout -b dev/abc/test1.Я единственный человек, работающий в этой отрасли.Я работал над этой веткой несколько часов, а затем сделал коммиты, сделал git push и создал запрос на удаление.Рецензенты сделали несколько комментариев к этому запросу.

Прежде чем приступить к работе с этими комментариями, я сделал git checkout master, а затем git pull, чтобы обновить ветку master.Позже я хотел объединить эти изменения (в master было много изменений с момента последнего обновления) в мою ветку dev/abc/test1.

Следовательно, я сделал git checkout dev/abc/test1.Тогда я сделал git reset --hard origin/master, а затем git merge origin/master.Итак, все мои изменения из этой ветки были потеряны, как и ожидалось.Я вручную скопировал вставленные изменения, которые я сделал из запроса извлечения.Теперь я начал работать с этими комментариями рецензента и исправил их все, сделал git commit, а затем git push, но только для того, чтобы увидеть сообщение

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

Чтобы избежать этого, я продолжил с git push --force.

Будет ли это иметь негативное влияние?Я вижу один из комментариев, говорящих здесь: Невозможно перейти на GitHub - постоянно повторяется необходимость слияния , что 'forcing' is most of the time, if not always, the wrong answer.Повлияет ли мой подход на хранилище каким-либо негативным образом?(Как примечание, я единственный отдельный участник ветки dev/abc/test1)

Answer 1

Если вы находитесь в процессе рассмотрения запроса GitHub, принудительное нажатие является допустимым. Это автоматически обновит ваш запрос на получение, и GitHub обнаружит, что изменилось.

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

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

Answer 2

Когда вы сделали git push --force, вы принудительно переписали удаленную ветку dev/abc/test1.Это означает, что предыдущая удаленная ветвь потенциально была стерта навсегда.В вашем случае не должно быть побочных эффектов, потому что вы единственный, кто использует ветку.Причина, по которой принудительное нажатие обычно плохо, заключается в том, что, как правило, удаленные ветви совместно используются несколькими разработчиками одновременно.Когда вы переписываете историю удаленной ветки, вы можете нанести ущерб любому, кто разделяет ветку.Когда этот другой человек перейдет на git pull, он увидит новую историю.

Обратите внимание, что, возможно, по иронии судьбы, лучшее, что вам нужно сделать, это просто заменить вашу локальную копию * 1006.* с удаленной веткой.Таким образом, вместо того, чтобы делать полный сброс на master, вы могли бы сделать полный сброс на dev/abc/test1 ветку трекинга, используя:

git reset --hard origin/dev/abc/test1

Это могло бы отменить все, что вы делали локально, что могло бы иметьпопросил вас сбросить до master.

Answer 3

В этом случае вы переписываете историю вашей dev/abc/test1 ветви. Пока никто не использует эту ветку, тогда все должно быть в порядке.

Я бы предложил следующий рабочий процесс, который будет означать, что вам не нужно принудительно нажимать в следующий раз.

git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push

Это будет иметь тот же результат, не переписывая историю.