Git中使用临时分支协助完成推送请求是否存在风险或缺陷？

如果你仅将downstream作为单人使用的临时中转分支、且每次执行删除重建操作前，都确认该分支上不存在未合并到master的提交，该操作本身不会引发代码丢失问题，但存在以下可预见的风险和缺陷：

• 未校验分支内容直接删除的丢代码风险：git branch -D是强制删除分支的命令，不会校验分支是否存在未合并到当前HEAD的提交。如果某次从rep3推送到downstream后，你还没将该分支内容合并到master就执行了重建操作，downstream上的未合并提交会被直接丢弃，且Git不会给出明确的内容丢失提醒。
• 多协作场景的冲突风险：如果后续有多个用户/仓库同时往rep2的downstream分支推送内容，你在重建分支前未同步给所有推送方，会导致其他推送方本地存储的downstream分支历史和rep2上新建的downstream分支历史完全分叉，后续推送会直接报错，只能通过强制推送解决，极易出现提交覆盖的问题。
• 操作冗余易失误：你需要手动登陆rep2执行两次分支操作，流程繁琐，还容易出现登错仓库、删错分支的操作失误。更简单的替代方案是直接在rep3端执行git push origin master:downstream -f，直接强制将远端downstream分支和你本地rep3的master分支对齐，无需登陆rep2做操作。
• 中转方案本身的局限性：你当前用非裸仓库的中转分支解决推送报错的方案本身存在局限，只要rep2的工作区存在未提交的修改、或者有人直接在rep2的master分支做了提交，都可能引发合并冲突。更规范的替代方案是将rep2切换为裸仓库，即可直接往master分支推送，不需要中转分支，从根源上避免该问题。

如果你当前的使用场景为单人操作三个仓库、且每次删除downstream前都会确认分支内容已全部合并到master，该操作暂时不会触发故障，但仍建议用更简便的强制推送方案替代手动重建分支的操作。

内容的提问来源于stack exchange，提问作者tglare