不要使用 git 重置 -- hard. 来擦除他们可能完全不可取的更改。 相反 :

git pull
git reset origin/master
git checkout <file1> <file2> ...

当然,你可以使用Git抓取而不是Git拉动, 因为显然它不会合并, 但如果你通常拉动它, 继续拉动这里是有道理的。

所以这里发生的情况是 git put 更新您的源/ 主管参考文件; git 重置更新您本地的分支引用与源/ 主管的引用相同, 无需更新任何文件, 所以您的检查状态没有变化; 然后按需要, git 检查退出将文件返回到您本地的分支索引状态 。 如果在现场和上游主控中添加了完全相同的文件, 索引已经符合重置之后的文件, 因此在常见情况下, 您不需要在

如果上游分支也包含您想要自动应用的承诺,您可以在进程上跟随细微的变异:

git pull
git merge <commit before problem commit>
git reset <problem commit>
git checkout <file1> <file2> ...
git pull

看起来最好的办法是首先做到:

git clean

以删除所有未跟踪的文件,然后继续使用通常的 Git 调用...

这里的答案似乎大多集中在主分支上; 但是,有时我在两个不同的地方 研究同一个功能分支, 我希望一个在另一个在重新基点上得到反映, 而不是跳过很多圈子。

根据Rna的回答和Torek对类似问题的回答, 我得出了一个非常有效的答案:

git fetch
git reset --hard @{u}

从一个分支运行它, 它只会重新设置你的地方分支 到上游版本。

也可以将它写进别名(git strengpull)中:

git 配置别名.forcepull "! git 获取; git 重设 - hard u}"

或者,在您的. git config 文件 :

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"

享受吧!

"我的地方变化很小,或者我的地方变化不起作用。 我只是想重置一切 回到原创。 我知道所有的地方变化都会丢失。"

如果情况是这样的话:

git reset --hard
git pull

一旦您进行了 Git 拖动, 您就会得到不匹配的文件列表。 如果文件数量不大, 那么您就可以检查这些文件, 此动作将会覆盖这些文件 。

git 检出 - & lt; filename & gt;

i 通常会这样做,如果为了快速检查我修改服务器上的本地文件(没有推荐的和在您得到这个问题:d背后的大致原因), i 在找到解决方案后检查已修改的文件。

这是恢复变化的最佳做法:

git 承诺执行您的分阶段更改, 以便将其保存在 reflog( 见下文) git 获取最新的上游更改 git 重设 -- 硬源/ master 硬重置到源主分支

reflog 记录本地仓库中更新的分支和其他引用。 或简单地放入 - reflog 是您更改的历史 。

所以这总是一个伟大的实践 承诺。 承诺被附在折叠纸上, 保证你永远有办法 检索删除的代码 。