git rebase на долговечных (удаленных) признаках функций

Question

Фон: Мы используем github для нашего проекта, и я работаю над своей собственной вилкой нашего основного хранилища. Мы используем rebase вместо merge, чтобы избежать больших коммитов.

Сценарий: Так я хочу работать, как это:

1. При внедрении новой функции, создать локальную ветвь мастера вилки и положить в моих изменениях там. Я и другие в группе делают много мелких коммитов, поэтому почти всегда будет несколько коммитов, которые влияют на один и тот же файл на ветке.
2. Наведите локальную ветвь на свою вилку, чтобы у меня была удаленная копия того, над чем я работаю (я не хочу, чтобы все мои изменения были потеряны, если мой ноутбук умирает или потерян. Я пытаюсь сделать это в конце каждого дня).
3. Если вам нужно много времени, чтобы закончить эту функцию, я иногда переустанавливаю мой мастер вилки, чтобы убедиться, что не было никаких изменений, которые могли бы нарушить мою функцию. Обычно это нормально.
4. Чтобы сохранить удаленный экземпляр ветви до даты, я подталкиваю свою локальную ветвь к ней после переустановки.

Задача: Этап 4, где я получаю проблемы. Мне почти всегда приходится иметь дело с быстрыми переадресациями и использовать git push -force.

Я посмотрел на

Git: how to maintain permanent parallel branches

How to maintain (mostly) parallel branches with only a few difference

и не нашли способ сделать свой рабочий процесс работы. Выполнение поиска google в рабочих потоках git в основном возвращает результаты, которые предполагают, что все вы работаете с локальными ветвями и не сохраняете удаленную копию на github (например, http://nvie.com/posts/a-successful-git-branching-model/).

Я относительно новичок в Git, поэтому хотел бы узнать, не хватает ли здесь чего-то. Я бы хотел сделать шаг 4 без использования. Альтернативный рабочий процесс, который по-прежнему позволяет мне использовать rebase вместо merge и сохранять удаленную копию моего локального ветвления, также будет очень полезен.

Answer 1

git push --force - это факт жизни при работе с rebase и удаленными ветками, потому что git push не будет делать без передышки без него. Большинство вещей в git предполагают, что история только добавляется, никогда не редактируется, а rebase нарушает это предположение, поэтому вам нужно сделать некоторые довольно вонючие вещи, чтобы заставить его работать.

Раньше мы использовали рабочий процесс rebase, очень похожий на тот, который вы описываете, но через некоторое время переключился на рабочий процесс слияния. Rebasing дает вам приятную, красивую, линейную историю, но имеет множество недостатков, таких как требование --force, теряя способность видеть состояние ветки до слияния с мастером и т. Д.

Как упоминается в Amber, rebase затрудняет работу с другими людьми в одной ветке - до git push --force ing, вы должны посмотреть состояние удаленной ветви, чтобы увидеть, кто-то еще нажал на нее, и pull --rebase это в, то git push --force. Даже у этого есть условие гонки - если кто-то еще толкает перед вами push --force, их изменения будут перезаписаны вами.

Answer 2

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

Альтернативный вариант merge вместо rebase ing. Вы можете использовать свой тот же рабочий процесс, за исключением слияния, а не для rebase, и вам не придется принудительно нажимать.

Если никто не использует удаленную ветку от вас, то использование --force не является изначально плохим. Если другие люди :, используя удаленный филиал, вы, вероятно, должны использовать merge.