Я нахожусь в ветке B. После нескольких коммитов несколько файлов готовы / необходимы ветке A, но многие не готовы / не нужны. Я хочу объединить только эти файлы, сохраняя правильную историю git. Позже, когда я действительно сливаюсь, мне не нужны вводящие в заблуждение следы происхождения этих изменений - они должны правильно ссылаться на коммиты, из которых они произошли, даже если изменения в других файлах, которые были частью этих коммитов, не были слиты (пока ). Я предполагаю, что это означает разделение коммитов на части, которые относятся к этим файлам или не имеют отношения к ним.
Все предлагаемые решения для этого теряют историю этих изменений и вызывают большую проблему, когда я позже хочу объединить B с A, но некоторые изменения B уже там. Я хочу решение, позволяющее избежать этого.
В черепахе я могу просмотреть журнал для одного файла и выбрать старую версию, к которой нужно вернуться. Итак, в принципе, я мог бы создать новую ветку C из B и вернуть все файлы, которые я не хочу объединять, обратно в точку, когда B разветвлялся от A. Тогда я мог бы объединить C на A. Это, кажется, правильно отслеживает историю git и позволяет мне объединить B в A, не удивляясь, что некоторые B изменения уже есть.
Но сложно вручную идентифицировать и восстанавливать 20 файлов, когда я просто хочу объединить 2. Почему это не обычная одноэтапная операция? Как работает откат черепахи - поскольку он может работать с одним файлом, он должен быть суб-фиксацией, что является важной функцией, которую я ищу. Отбрасывает ли это тот факт, что я перехожу от новой ревизии к более старой, и заставляет это выглядеть так, будто я только что внес некоторые ручные изменения, которые затем будут конфликтовать с возможным слиянием B с A?
