Если посмотреть только на вопрос, краткий ответ таков: не существует простого способа сделать это.Попытка перебазировать только изменения в одном каталоге работает против структуры того, как git хранит данные.
Глядя на обсуждение в комментариях, становится немного яснее, что вы пытаетесь достичь (я думаю), поэтому, возможно,мы можем собрать что-нибудь вместе.Но поймите, кажется, вы находитесь в таком положении, потому что вы и ваш коллега игнорируете функции git, которые бы этого не делали.Я имею в виду: почему вы оба работаете над одной и той же веткой, если хотите иметь возможность действовать независимо от ваших изменений?
Ну, в любом случае, у вас что-то происходит, как это
... x -- x -- x <--(master)
\
F1 -- B1 -- B2 -- F2 -- F3 -- F4 -- B3 <--(branch)
Я предполагаю, по крайней мере, что ваши изменения появляются в отдельных фиксациях от изменений вашего коллеги.Таким образом, F<n> представляет один из ваших коммитов, обновляя интерфейс, а B<n> представляет один из коммитов вашего коллеги, обновляя бэкэнд (сервер).
Если, по крайней мере, это так - и если ваш коммит не делаетне зависит от B коммитов и наоборот - тогда вы бы хотели конечное состояние, такое как
F1' -- F2' -- F3' -- F4' <--(frontend)
/
... x -- x -- x <--(master)
\
B1' -- B2' -- B3' <--(server)
Обратите внимание, что это все еще включает переписывание коммитов B, так что ветвь server не делаетдолжны хранить избыточные копии ваших изменений.Это, вероятно, будет важно, когда придет время реинтегрировать ветви, особенно если перебазировка F коммитов порождает конфликты.
Итак, на что вы надеетесь, это то, что F фиксирует измененияникогда не вступайте в конфликт с B изменениями коммитов - что, по вашему сценарию, по крайней мере правдоподобно.
Поэтому первое, что нужно сделать, - это получить список коммитов, которые необходимо перебазировать.Это можно сделать по имени автора, если вы действительно написали все коммиты F, а они написали все коммиты B.
git rev-list --author=your_name
Или это может быть сделано путем, если вы на 100% уверены, что ваши коммиты - и только ваши коммиты - затрагивают определенные пути.Таким образом, вы можете сказать
git rev-list -- path/to/frontend/code
Или вы можете вручную сканировать весь журнал (git log master..branch) и записывать коммиты, которые вы хотите.
Затем
git checkout branch
git checkout -b frontend
git rebase -i master
Это загрузит редактор с «списком задач», имеющим одну запись на коммит в branch.Удалите записи для B коммитов из списка, а затем сохраните и выйдите.Возможно, вам придется разрешить некоторые конфликты, но это должно быть сделано только для внесенных вами изменений.Тогда у вас будет
F1' -- F2' -- F3' -- F4' <--(frontend)
/
... x -- x -- x <--(master)
\
F1 -- B1 -- B2 -- F2 -- F3 -- F4 -- B3 <--(branch)
Тогда вам нужно создать ветку сервера.Вы хотите убедиться, что , а не , чтобы переместить его вперед к подсказке master, поэтому вы не можете просто перейти к master;но вы можете сделать это:
git checkout branch
git checkout -b server
git rebase -i $(git merge-base master HEAD)
На этот раз, когда появится список задач, вы удаляете коммиты F.Если есть какие-либо конфликты, это означает, что у вас и вашего коллеги действительно были совпадающие изменения, и вам придется их уладить;вы не увидите конфликтов между работой вашего коллеги и master, потому что его работа остается на месте до любых master изменений.
Тогда у вас будет
F1' -- F2' -- F3' -- F4' <--(frontend)
/
... x -- x -- x <--(master)
| \
| B1' -- B2' -- B3' <--(server)
\
F1 -- B1 -- B2 -- F2 -- F3 -- F4 -- B3 <--(branch)
, и если вы захотитезатем вы можете отказаться от оригинала branch
git branch -D branch