Ответ 1
Вы можете объединить свою ветвь вверх по течению в ветку dev с помощью настраиваемого драйвера слияния "keepTheirs" :
См. " "git merge -s theirs" , но я знаю, что этого не существует.
В вашем случае потребуется только один .gitattributes, а keepTheirs script как:
mv -f $3 $2
exit 0
git merge --strategy=theirs Моделирование # 1
Показывает как слияние, с восходящим потоком в качестве первого родителя.
Jefromi упоминает (в комментариях) merge -s ours, объединив вашу работу над восходящим (или на ветке temp, начиная с восходящего потока), и затем быстро переадресуйте свою ветку на результат этого слияния:
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
Это имеет преимущество записи предка-предшественника в качестве первого родителя, так что слияние означает "поглотить эту устаревшую ветку темы", а не "уничтожить эту ветку темы и заменить ее вверх" .
(Edit 2011):
Этот рабочий процесс был опубликован в этом сообщении блога OP:
Почему я хочу снова это сделать?
Пока мое репо не имеет ничего общего с публичной версией, все было в порядке, но с тех пор я хочу, чтобы у меня была возможность сопоставлять WIP с другими членами команды и внешними участниками, я хочу убедиться, что моя публичные ветки надежны для других, чтобы отламывать и тянуть, т.е. больше не переустанавливать и reset по вещам, которые я нажал на удаленную резервную копию, так как теперь она находится на GitHub и публичной.
Итак, это оставляет меня тем, как я должен действовать.
В 99% случаев моя копия попадает в ведущего мастера, поэтому я хочу работать с моим мастером и в большинстве случаев нажимать вверх по течению.
Но время от времени то, что у меня есть вwip, становится недействительным по тому, что происходит в восходящем направлении, и я оставлю часть моегоwip.
В этот момент я хочу вернуть моего мастера в синхронизацию с восходящим потоком, но не уничтожить какие-либо пункты фиксации на моем публично продвинутом главном устройстве. То есть Я хочу слияние с восходящим потоком, который заканчивается набором изменений, который делает мою копию идентичной вверху.
И это то, что долженgit merge --strategy=theirs.
git merge --strategy=theirs Моделирование # 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 Моделирование # 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 Моделирование # 4
(тот же пост в блоге)
В качестве альтернативы, если вы хотите, чтобы локальные ветки upstream быстро пересылались, потенциальный компромисс должен работать с пониманием того, что для sid/unstable ветка восходящего потока может время от времени быть reset/rebased (на основе события, которые в конечном счете выходят из-под контроля на стороне проекта).
Это не имеет большого значения, и работа с этим предположением означает, что легко поддерживать локальную ветвь восходящего потока в состоянии, когда оно требует только быстрых обновлений.
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 Моделирование # 5
(предложенный Барак А. Перлмуттер):
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 Моделирование # 6
(предложенный тем же Michael Gebetsroither):
Майкл Гебсетромид взволнован, заявив, что я "обманывал";) и дал другое решение с командами сантехники нижнего уровня:
(это не будет git, если это будет невозможно с git только командами, все в 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