获取master的新变化，并在最新master的基础上重新建立功能分支

git checkout master
git pull
git checkout feature
git pull --rebase origin master
git push origin feature

git在特性分支上的合并主有什么问题?这将保留您的工作，同时使其与主线分支分离。

A--B--C------F--G
       \         \
        D--E------H

编辑:啊，对不起，没有读你的问题声明。当你执行重基时，你将需要力量。所有修改历史记录的命令都需要——force参数。这是防止您丢失工作的故障保险(旧的D和E将丢失)。

所以你执行了一个git rebase，使树看起来像这样(尽管部分隐藏，因为D和E不再在一个命名的分支中):

A--B--C------F--G
       \         \
        D--E      D'--E'

所以，当你试图推动你的新特征分支(其中有D'和E')时，你会失去D和E。

而不是使用-f或——force开发人员应该使用

--force-with-lease

Why? Because it checks the remote branch for changes which is absolutely a good idea. Let's imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses --force and would rewrite all Lisa's changes. If James had used --force-with-lease he would have received a warning that there are commits done by someone else. I don't see why anyone would use --force instead of --force-with-lease when pushing after a rebase.

对我来说，以下简单的步骤是有效的:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

完成以上所有操作后，我们可以通过以下命令删除myFeature分支:

git push origin --delete myFeature

问题是git push假设远程分支可以快进到你的本地分支，也就是说，本地分支和远程分支之间的所有区别都是在本地有一些新的提交，就像这样:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

当你执行git rebase commit时，D和E会被应用到新的base并创建新的提交。这意味着在调整后，你会有这样的东西:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

在这种情况下，远程分支不能快进到本地。虽然，理论上本地分支可以合并到远程分支(显然在这种情况下你不需要它)，但由于git push只执行快进合并，它会抛出一个错误。

force选项的作用是忽略remote branch的state并将它设置为你推入的commit。所以git push——force origin feature-branch只是用local feature-branch覆盖了origin/feature-branch。

在我看来，只要你是唯一在这个分支上工作的人，就可以在master的基础上重新构建特性分支，并强制将它们推回远程存储库。

因为OP确实理解问题，只是寻找一个更好的解决方案…

把这个作为一个实践怎么样?

Have on actual feature-develop branch (where you never rebase and force-push, so your fellow feature developers don't hate you). Here, regularly grab those changes from main with a merge. Messier history, yes, but life is easy and no one get's interupted in his work. Have a second feature-develop branch, where one feature team member regulary pushes all feature commits to, indeed rebased, indeed forced. So almost cleanly based on a fairly recent master commit. Upon feature complete, push that branch on top of master.

这个方法可能已经有了一个模式名。