我是git的新手，所以请耐心等待。我有一个包含大量代码的本地存储库，现在我正在使用邮件与我的朋友共享。今天我的朋友在bitbucket上设置了一个git存储库，但有一些变化。
我还对本地存储库进行了一些更改。现在我想将我的更改提交到远程存储库，但我担心我会弄乱文件。 我现在已经完成了这个 -
git init
git remote add origin <remote-url>
我不知道接下来该做什么。请建议。
答案 0 :(得分：1)
我想你应该去取......但是你不能只是“结账”，因为你已经拥有了自己的文件，如果你试图像那样结帐，git可能会警告你。你应该做的最好的事情是
答案 1 :(得分：1)
由于您已经有一个已经工作了一段时间的现有存储库，因此您已经有一些提交创建了与您朋友的存储库中的历史记录无关的历史记录。
如果您还不清楚Git提交的是什么以及它们为您做了什么，以及为什么我按照我的方式绘制提交图片段，请参阅this answer一个不相关的问题。特别注意术语 root commit ，并注意提交如何链接。另请注意，每个提交都有自己唯一的哈希ID（我将其缩写为单字母名称）。这些哈希ID非常重要。
您现有的存储库有一些提交。为方便起见，我假设您只有四个，全部名称为master，我将通过A致电D：
A--B--C--D <-- master
这是您的存储库，由您的 Git处理。在此存储库中，您现在运行：
git remote add origin <remote-url>
远程URL是告诉你的Git通过互联网电话调用Bitbucket并让他们的 Git与你交谈，他们的Git正在查看你朋友的存储库。所以origin现在是＆＃34;我通过这个URL让我的Git与他们的Git交谈以获得提交，或者提交给他们的Git。＆＃34;如果你的朋友名叫吉姆，我们可以打电话给这个＆＃34;吉姆的回购＆＃34;。我可以尝试在任何地方使用origin，但我觉得这不太有效，所以我会和Jim一起跑步。 ： - ）
下一步是运行：
git fetch origin
指示你的Git调用他们的Git并从中获取提交。我不知道Jim的回购origin中有多少次提交，但为方便起见，我只会画三次。他们保证从你的四次提交中获得不同的ID，因为Jim创造了他们，而不是你 - 他们有Jim作为他们的作者和提交者。此外，Jim使用Jim的先前提交（因此他们有他的父ID，而不是你的），按照Jim的时间表（所以他们的时间戳，而不是你的时间）制作了他们，即使 >他们有相同的保存快照。所以我们需要给他们不同的字母名称。
你的Git会问他们的Git他们的提交。更准确地说，它会要求他们拥有你没有的。最初，那是他们所有的。所以你的Git得到了他们所有的提交。这些都具有来自所有提交的不同ID。所以让我们把它们画进来：
A--B--C--D <-- master
P--Q--R <-- origin/master
你应该立即注意两件事，按顺序排列：
名称origin/master来自何处？
为什么两个 root提交？
第一个答案是你的 Git 重命名他们的Git的分支机构。这样做是因为它必须：你的Git需要一个新的，独立的分支名称，以便它们的名字可以与你的名字分开维护。
标准重命名是取其分支名称并推送＆＃34; remote＆＃34;在前。您向远程设置了名称origin，因此Jim master现在是您的origin/master。
有两个 root 提交，因为Jim自己做了他的第一次提交，而没有使用任何提交。 （他怎么可以用你的？他从来没有过他们！）他的承诺＆＃39;实际的ID是大丑陋的哈希，而不是这些单字母的名字。这就是我从D跳到P的原因。这留下了很多中间空间，并且避免暗示，E恰好在D之后出现。
提交P和A完全无关，这是我们的绊脚石。你需要决定，现在该做些什么，而且没有正确答案。
您可以尝试合并这两个不相关的历史记录。较早版本的Git（早于2.9）将尝试它：您所要做的就是运行git merge origin/master。较新的Git版本意识到这不太可能正常工作，并强制您添加标志--allow-unrelated-histories。添加标志不会让它更好用，它只是告诉Git继续尝试它。 如果选择此方法，则必须解决所有合并冲突，然后使用该合并结果进行最终提交：
A--B--C--D--E <-- master
/
P--Q------R <-- origin/master
此合并提交将历史记录联系在一起。如果Jim允许，您现在可以git push将此新提交E以及与其一起使用的A-B-C-D提交到Bitbucket存储库。你可以让你的Git发送所有这些提交，加上他们的 Git设置他们的 master的请求指向提交E（或者更确切地说，它实际的，完整的，难以理解的哈希ID）。
或者，您可以尝试 rebase -i.e。，将您的提交，或者更确切地说，您的提交的一些子集复制到他们的提交中。例如，如果您的提交A是＆＃34;足够接近＆＃34;对于他们的提交P，就其保存的源代码树而言，您可能只想捕获从A到B的您已更改的内容，然后您从B转到C时所做的更改，以及从C转到D时所做的更改。如果你按照提交R的顺序依次堆叠每一个，并让你的Git记住你的副本D作为你的master，你会得到这个：
A--B--C--D [abandoned]
P--Q--R <-- origin/master
\
B'-C'-D' <-- master
其中B'是B的副本，C'是C的副本，D'是D的副本。
有很多方法可以结合所有这些东西。然而，将这些返回给Jim或者分享所有这些工作的关键是让各种提交变得相关。你需要有一些共同的提交 - 当我们绘制这些提交图时，将提交连接到他们的父母的箭头＆＃34;加入＆＃34;在提交。一旦你有了，其余的就容易多了。
Jim仍然需要授予您对他的存储库的写入权限，或者 - 通常在GitHub和Bitbucket上完成 - 您可以在服务器上创建另一个存储库副本（在Bitbucket或GitHub上）吉姆可以访问。然后你将你的提交推送到该服务器上的你的存储库，并向Jim发送一些警告电子邮件，例如 - 告诉他＆＃34;我在我的可广泛访问的存储库，您可以获取并合并到您的可广泛访问的存储库中。请在方便的时候拉它们。＆＃34;我们通常称这些拉取请求，如果你使用了一些＆＃34; fork a repository＆＃34;在某些网站上的按钮，它们可以自动完成将这些警报传递给其他人或团体所需的大部分内容（我一直在呼叫的那个＆＃34; Jim＆＃34;这里）。
但是，在所有情况下，您的第一步是执行某事，以便您的提交通过父/子链接与其提交相关联。你想在这里做什么取决于你。请注意，如果您不确定该怎么做，您可以随时克隆当前克隆，随心所欲地查看它，并查看您是否喜欢结果。如果没有，您可以删除克隆并再次克隆当前克隆并弄乱新的克隆。这为您提供了一种测试每条路径的简便方法。
（有一些方法可以在不克隆你的克隆的情况下做到这一点-Git非常好，不会失去提交 - 但它们可能很棘手，因为如果你讨厌结果和想要失去它，嗯，Git非常擅长不失去提交，这使得失去它们变得非常糟糕。在一个单独的克隆副本中工作会让所有这些担忧彻底消失。）