我是 git 新手。我所做的是分叉了几个我感兴趣的存储库，然后将它们克隆到我的计算机上以使用它们。
一些原始项目可能会因为我弄乱我的本地副本而显着更新，或者我可能会进行一些微不足道的更改。
据我了解，我可以“重新定位”我的克隆以“拉动”原始的更改。
这对我的更改有什么影响？例如，假设有一个DoSomething.cpp原始文件。我修改它，也许修复一个小错误或添加一个功能。现在！1年后，原来的项目经过多次修改，好多了。我想将这些更改“拉”到我的克隆中，但也要保留我的更改！（所以这有点与推动相反）
这很容易做到吗？如果是这样，基本思想是什么？
我想要的是我的克隆与原始克隆的任何更改（我已更改的内容）都不会被覆盖，但我实际上可以将我的更改与原始克隆（在我的 fork 上）合并，并能够实际检查和接受更改。（例如，如果DoSomething.cpp在原件上进行了更改，那么我需要比较更改以确保它们兼容。
我想这并不难，因为我是 fork 的所有者，我可以对其进行 rebase 或硬重置，然后将我的本地更改推送到我的 fork？（不确定它是否会起作用，因为版本控制问题的可能性很大）
你是对的，变基是你可以让你的代码保持最新的一种方式，并且是非常常用的。
根据我的经验，变基在管理 git 历史记录方面更有用。它使您的历史保持良好和线性，它使工作看起来像是按顺序而不是并行发生的。另一方面，常规合并将涉及大量发散/收敛的提交。您可以使用git log --graph直观地看到这种差异。
简而言之，rebase接受您的提交，将它们转换为补丁，然后将它们应用到您正在变基的分支。如果有冲突，git 会停止并要求你解决它们，然后你可以让它继续。所以你仍然在合并和解决冲突，但只是以一种使历史线性化的方式。
首先，您应该知道，无论您“合并”还是“变基” ，您都不会丢失您的更改，并且 git 会给您机会提交您的更改并解决冲突（如果有的话），然后将您的修改推送回您的远程仓库正在拉扯。
当你git pull告诉 git 这样做时：（拉取默认是使用“合并”）
从远程提取文件的最新副本，将它们与我的本地更改合并，如果存在您无法自动解决的冲突，请通知我以便我手动解决；这很简单。
当你git pull --rebase告诉 git 这样做时：
临时删除*从我的本地副本（我修改的文件）中的更改，从远程提取最新副本，在其上合并我的更改&如果存在您无法自动解决的冲突，请通知我以便我解决它手动。（从技术上讲，什么都没有被删除；这只是为了让这个原本模糊的逻辑更清晰。）
差异是微妙的，在第二种情况下，您的更改似乎就像您刚刚在从远程提取的最新副本的顶部进行了这些更改......但正如您所看到的，在这两种情况下您的更改绝对保留（否则git有什么用！）。
你应该合并还是变基？这是长时间的讨论，有些地方比另一个更好，并且有最佳实践；此页面中已经提到了一些有用的评论，有关更多信息，您可以在线搜索，只需输入“git merge vs rebase”，您将看到大量关于它的页面：）
希望这可以帮助。
找出你git status所在的分支，用 完成，它会在第一行或第二行显示分支的名称。
对于测试，我建议首先将您的更改分支到一个单独的分支中：
git checkout -b my-patches
现在确保所有更改都已提交。为此，您再次调用git status. 理想情况下，它应该显示Working directory clean，但如果不是这样，请使用git add将您的更改添加到索引并git commit最终提交它们。如果您想将更改拆分为几个不同的补丁集（在发生冲突时会很方便），我建议您阅读如何使用git commit -p. 您这样做，直到您的所有更改不再列出git status。将列出一些您未触及的文件git status，可能是构建的结果。如果没有您有兴趣保留的更改，那很好。
如果有任何 makefile 等支持清理目录（make clean例如），请立即运行它们。
master然后使用（替换为您在步骤 1 中找到的任何分支名称）切换回您的原始分支：
git checkout master
如果您想确保一切正常，请运行：
git diff my-patches
它应该列出您在 fork 中更改的行。如果没有，那就是出了点问题。
现在是可怕的部分。您现在将丢弃对该分支所做的任何更改。请注意，如果您按照步骤 3 中的说明将所有更改提交到单独的分支，它们就可以了。如果您不确定，可以通过复制整个存储库文件夹来进行备份。然后你运行（再次，master用你以前的任何东西代替）：
git fetch
git reset --hard origin/master
理想情况下，您的分支现在应该具有分支的确切状态origin/master。确保一切正常。然后，您使用以下方法合并您的更改：
git merge my-patches
Git 会尽最大努力让它尽可能轻松，但可能会有冲突。>>>>Git 将用和标记在相应的文件中`<<<<标记它们。为了解决冲突，我建议你做一些互联网研究或阅读打开的 Git Book 中有关基本合并冲突的部分。确保之后提交合并。
困难的部分已经结束。您现在可以删除临时分支：
git branch -d my-patches
我使用临时分支的原因是能够轻松地将存储库的状态恢复到合并尝试之前的状态。当然，也可以在单独的分支中检查远程状态，但我更喜欢这样。
您是否将上游遥控器添加到您的分叉存储库中？这是让你的 fork 与它的 master 保持同步的最简单方法。这是第 3步。