第一件事不要忘记添加和提交当前文件之前，采取rebase。
手动解决文件中的冲突后。要标记为冲突已解决，请使用**git add <file>**，然后使用git rebase --continue。然后使用git push
因此，步骤如下

1. git加法
2. git提交
3. git变基
   1.如果有冲突解决冲突&使用git add <file_name>标记文件冲突已解决
4. git变基--继续
5. git推送

如果没有太多关于当前状态的信息，有可能你的一些本地提交已经是你要重定基础的分支的一部分了。
例如，假设你试图在master上重定develop，develop分支包含了很多提交，但是你已经把develop合并到了master中。
在这种情况下，git rebase master可能会丢失一些提交，但git已经检测到它们已经是master的一部分，所以不需要重新应用它们。
您可以使用git rebase --interactive来显示将要重定基的提交列表，如果您没有看到预期的提交，或者看到的提交比预期的多，您可能需要考虑使用--onto来更改重定基提交的起始点。

听起来你的工作目录在你重定基的时候是脏的。你可能应该做好准备，当你重定基的时候，你的工作目录和stage会被擦除。作为一个解决方案，如果你发现你自己有一个非空的工作目录和/或stage，但是你需要重定基到最新的其他分支，你可以做一个stash，即。

git stash

Git会提交2次（甚至3次）来保持你的工作目录和stage不变，当rebase完成后，你可以通过应用stash来恢复这些修改：

git stash apply

我认为在某些情况下，Git甚至不允许你根据工作目录和stage的状态进行合并或重定基，但无论如何，在重定基之前确保它们是干净的可能是个好主意。

如果你在冲突面前做错了什么，就会发生奇怪的事情：

错误：

$ editor path/to/conflicted/file # resolve conflicts in editor
$ git commit --amend # no!

$ editor path/to/conflicted/file # resolve conflicts in editor
$ git commit -a # no!

遵循正确的步骤：

$ editor path/to/conflicted/file  # resolve conflicts in editor
$ git add path/to/conflicted/file # stage resolved file
$ git rebase --continue

你可能会对交互式的重定基工作流感到困惑，当你交互式地重定基并在edit的某个提交处停止时，它看起来类似于冲突的情况：一个rebase在中途停止了，你可以修复一些东西，然后git rebase --continue.但是在交互式rebase edit的情况下，编辑过的提交被完全应用，所以你可以git commit --amend它，或者在它上面添加新的提交，之后rebase将继续.
我过去也曾被这个问题绊倒过几次;我非常习惯于交互式重定基，因为我经常这样做，以至于仅仅从“肌肉记忆”来看，我在解决冲突后就做了一些愚蠢的事情，比如git commit --amend。

首先，我希望您不是直接在本地repo的master分支上工作，而是有一个单独的分支来推送本地更改，在分支上完成工作后，您可以创建一个pull请求或与master分支合并。
假设您有一个单独的分支，请按照以下步骤使用master进行变基，而不会丢失本地更改。如果您在master以外的其他分支中：

git checkout master

然后继续执行以下命令：

git remote -v
git remote add upstream https://github.com/url_of_the_repo_you_are_working_on
git pull upstream master
git checkout branch_name_you_are_working_on
git rebase -i master

此时，本地存储库中的分支将被更新，并且分支中的更改将保持不变。现在，您可以将更改推送到远程分支：

git push -f origin branch_name_you_are_working_on