git rebase в долгоживущих (удаленных) функциональных ветках

Question

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

Сценарий: То, как я хочу работать, выглядит следующим образом:

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

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

Я смотрел на

Git: как поддерживать постоянные параллельные ветви

Как поддерживать (в основном) параллельные ветви с небольшим отличием

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

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

Answer 1

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

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

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

Answer 2

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

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

Если никто кроме вас не использует вашу удаленную ветвь, то с помощью --force isn 'т по сути плохо.Если другие люди используют удаленную ветвь, вам, вероятно, следует в любом случае использовать merge.