Сворачивание промежуточных коммитов в более поздние коммиты, а не в более ранние

Предположим, у меня есть три коммита

A --> B' --> B

Фиксация B' представляет собой промежуточное состояние, когда работа не завершена и тесты не проходят. Возможно, я сделал коммит B', чтобы переключиться с работы на моей домашней машине на мою рабочую машину.

Допустим, я нахожусь в ветке темы, на которую кроме меня никто не смотрит. Но все три коммита находятся на удаленке, иначе я не смог бы использовать B' для передачи изменений с одной машины на другую.

Если я сделаю git rebase -i <commit-before-A> (или если A будет первой фиксацией, то git rebase i --root) и выберу fixup или squash фиксацию B', то изменения в B' будут свернуты в фиксацию A.

Но это не подходит. Я хочу, чтобы коммиты A и B представляли собой разумные контрольные точки в работе, где изменения не находятся в полузавершенном состоянии, которое никто не понял бы, кроме меня. Если я fixup коммит B', то останется коммит A с полусырыми изменениями, которые раньше были у B'. Я хочу, чтобы коммит B' был свернут в B, поскольку B' представляет собой промежуточную работу по направлению к коммиту B.

Возможные решения:

1а. Просто оставьте коммит B' и назовите его "фиктивный коммит", чтобы никто не обратил на него внимания. Это в моей тематической ветке (хотя она удалена), так что кого это волнует.

1б. Если я думаю, что люди потенциально могут посмотреть на мою текущую ветку темы и осудить меня за непрофессионализм, дайте B' свою собственную ветку, которая, я уверен, никого не волнует, а затем, как только B будет готова, закоммитить ее и объединить обратно в исходную ветку, затем удалите временную ветку. Так это выглядит

  BRANCH DELETED
  B' --> B''
 /         \
A ---------> B
 BRANCH REMAINING

2. Избавьтесь от B', прежде чем я сделаю коммит B. Итак, если B' было сделано для переключения машин, как только я доберусь до другой машины, немедленно git reset --soft, затем, как только я закончу изменения, сделайте коммит B, затем git push --force на удаленный, затем, если и когда я вернусь к первому машина, используйте git pull --force. Прискорбно «переписывать историю» таким образом, и использование --force довольно часто кажется опасной привычкой.
3. drop совершить B' вместо squash или fixup. Git, похоже, не очень разумно относится к этому и требует разрешения слияния, даже когда A --> B' --> B очевидно является быстрым изменением вперед. Опять же, вы переписываете историю, и --force потребуется несколько раз.
4. Если две машины находятся в одной сети, вместо этого используйте общий доступ к файлам. Это кажется мне грубым и негибким.
5. Сделайте один из них и живите с этим; это дело вкуса и всем не угодишь.

Имейте в виду, что цель этого вопроса не в том, чтобы начать спор о вкусах; это раскрыть плюсы и минусы, о которых я не думал, или представить мне варианты, о которых я не думал.

Похожие сообщения:

• Можно ли отправить git stash в удаленный репозиторий?
• Коммит Git не завершен, но не может быть продолжен на этой машине
• Должен ли я использовать git stash, чтобы сохранять текущие изменения моего проекта и отправлять их на github для доступа на других компьютерах?
• Когда коммитить код?