Прежде всего, вы уверены, что это то, что вы хотите сделать? Есть два довольно стандартных решения для подобной ситуации в Git, но ни одно из них не «застегивает» коммиты именно так, как вы хотите. Первый вариант - просто объединить «прочее» с «основным» и удалить ветку «прочее». Это не оставляет линейной истории, но все находится в «основной» ветке, и вы можете просматривать ревизии в любом конкретном порядке, который вы хотите (например, вы можете сделать git log --date-order, чтобы получить коммиты, перечисленные в порядок, который вы хотите). Вы получите эту историю в конце концов:
A1 A2 M3 M4
*--*--*--*
/ \
--* *-- < master
\ /
*----*---*
B1 B2 B3
Вы бы достигли этого, запустив:
git checkout master
git merge other
git branch -d other
Другой вариант - перебазировать вашу "другую" ветку поверх вашей главной ветки. Это даст вам линейную историю, но все ваши коммиты в «другой» ветке появятся после коммитов в «master». Даты будут сохранены, поэтому, если вы хотите знать, когда на самом деле произошли коммиты, вы все равно можете это выяснить, но топологически они будут отсортированы впоследствии:
A1 A2 M3 M4 B1 B2 B3
--*--*--*--*--*--*--*-- < master
Вы можете сделать это, запустив:
git checkout other
git rebase master
git checkout master
git merge other
git branch -d other
Если вы абсолютно уверены, что ни одно из вышеперечисленного не работает для вас, вы можете рассмотреть подход «застежка-молния», который вы пытаетесь сделать. В Git нет автоматизированных инструментов, которые бы сделали это за вас, поэтому вам придется работать немного усерднее для этого. Это также вызовет проблемы у всех, кто основывает свою историю на master, поскольку им всем тогда придется перебазировать свою работу поверх вашей новой master (ваша предложенная линейная история меняет родителей каждого из коммитов в master (это означает, что эти коммиты отличаются от того, что было раньше; это означает, что теперь любой другой основывает свою работу на совершенно новом наборе коммитов, который, как оказалось, имеет те же различия, что и предыдущий набор коммитов).
Если вы не против сделать заказ вручную, вы можете использовать git rebase -i, чтобы упорядочить коммиты так, как вы хотите. Вы должны выполнить следующие команды (где base - первый коммит до того, как две ветви разошлись; если a1 - первый коммит, не общий между ними, тогда вы можете использовать a1~ для ссылки на этот коммит):
git checkout master
git merge other
git rebase -i base
Во время интерактивного перебазирования вам будет представлен текстовый файл, содержащий список изменений, которые вы можете редактировать в любом порядке, в котором вы хотите, чтобы они были применены. Конечно, это полностью вручную, так что только вариант, если вы иметь небольшую историю и хотите изменить коммиты вручную. Если есть какие-либо конфликты слияния, вам может потребоваться разрешить их несколько раз вручную, если вы сделаете это. И, как уже упоминалось, это будет означать, что любой другой, кто основывал свою работу на master, теперь должен будет также сделать ребаз.
Вы также можете несколько автоматизировать этот процесс, создав новую ветку, начинающуюся с base, и вставив вишневые коммиты из одной или другой ветви в эту новую, и, наконец, заменив master этой новой веткой.
Но, как я уже говорил, вы, вероятно, не хотите этого делать. Мои первые два решения, которые не дают вам достаточно истории, которую вы ищете, но дают вам что-то близкое к ней, будут вести себя лучше всего в большинстве рабочих процессов на основе Git.