Вы можете объединить вашу ветку upstream с вашей веткой dev, с помощью настраиваемого драйвера слияния "keepTheirs" :
См. "" git merge -s theirs ", но я знаю этоне существует".
В вашем случае потребуется только один .gitattributes и скрипт keepTheirs, например:
mv -f $3 $2
exit 0
git merge --strategy=theirs Simulation #1
Отображается в виде слияния с восходящим потоком в качестве первого родителя.
Джефроми упоминает (в комментариях) merge -s ours, пообъединение вашей работы в восходящем потоке (или во временной ветви, начинающейся с восходящего потока), а затем перемотка вашей ветки вперед в результате этого слияния:
git checkout -b tmp origin/upstream
git merge -s ours downstream # ignoring all changes from downstream
git checkout downstream
git merge tmp # fast-forward to tmp HEAD
git branch -D tmp # deleting tmp
Это имеет преимущество записиродительский предшественник как первый родительский элемент, так что слияние означает «поглотить эту устаревшую ветку темы», а не «уничтожить эту ветку темы и заменить ее восходящей» .
(Изменить 2011):
Этот рабочий процесс был описан в этом сообщении в блоге OP :
Почему я хочу это снова?
Пока мое репо не имело ничего общего с публичной версией, все было хорошо, но с тех пор я хотел бы иметь возможность взаимодействовать по WIP с другой командойУчастники и сторонние участники, я хочу убедиться, что мои публичные ветки надежны для других, чтобы ветвиться и извлекать из них, то есть больше не нужно перебазировать и сбрасывать то, что я отправил в удаленное резервное копирование, так как теперь оно на GitHub и public.
Так что мне остается действовать.
99% времени моя копия попадает в основной канал, так что я хочу работать с главным и большую часть времени работать в восходящем направлении.
Но время от времени то, что у меня есть в wip, становится недействительным из-за того, что входит в восходящий поток, и я откажусь от некоторой части моего wip.
В этот момент я хочу привести своимастер синхронизируется с апстримом, но не уничтожает какие-либо точки фиксации на моем общедоступном мастере.Т.е. я хочу слияние с апстримом, которое заканчивается набором изменений, делающим мою копию идентичной апстриму .
И это то, что git merge --strategy=theirs должен сделать.
git merge --strategy=theirs Simulation # 2
Показывается как слияние с нашим первым родителем.
(предложено jcwenger )
git checkout -b tmp upstream
git merge -s ours thebranch # ignoring all changes from downstream
git checkout downstream
git merge --squash tmp # apply changes from tmp but not as merge.
git rev-parse upstream > .git/MERGE_HEAD #record upstream 2nd merge head
git commit -m "rebaselined thebranch from upstream" # make the commit.
git branch -D tmp # deleting tmp
git merge --strategy=theirs Simulation # 3
В этом сообщении в блоге упоминается :
git merge -s ours ref-to-be-merged
git diff --binary ref-to-be-merged | git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend
иногда вы хотите сделать это,и не потому, что в вашей истории есть «дерьмо», а , возможно, потому, что вы хотите изменить базовую линию разработки в общедоступном репозитории, где следует избегать перебазирования .
git merge --strategy=theirs Simulation # 4
(то же сообщение в блоге)
В качестве альтернативы, если вы хотите обеспечить быструю переадресацию локальных восходящих веток, потенциальным компромиссом является работа спонимая, что для sid / unstable ветвь вверх по течению может время от времени сбрасываться / перебазироваться (на основе событий, которыев конечном счете, вне вашего контроля со стороны вышестоящего проекта).
Это не имеет большого значения, и работа с этим предположением означает, что легко поддерживать локальную вышестоящую ветвь в состоянии, когда требуется только быстрое обновление.
git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff --binary ref-to-be-merged | git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend
git merge --strategy=theirs Simulation # 5
(предложено Barak A. Pearlmutter ):
git checkout MINE
git merge --no-commit -s ours HERS
git rm -rf .
git checkout HERS -- .
git checkout MINE -- debian # or whatever, as appropriate
git gui # edit commit message & click commit button
git merge --strategy=theirs Simulation # 6
(предложено тем же Michael Gebetsroither ):
вмешался Майкл Gebetsroither, утверждая, что я "обманывал";) и дал другое решение с низкоуровневыми сантехническими командами:
(было бы не git, если бы это было невозможно с командами git only, все в git с diff / patch / apply нереальное решение;).
# get the contents of another branch
git read-tree -u --reset <ID>
# selectivly merge subdirectories
# e.g superseed upstream source with that from another branch
git merge -s ours --no-commit other_upstream
git read-tree --reset -u other_upstream # or use --prefix=foo/
git checkout HEAD -- debian/
git checkout HEAD -- .gitignore
git commit -m 'superseed upstream source' -a