我将很快开发一些iPhone / iPad应用程序，并且正在考虑使用Git作为我的版本控制系统。在过去的项目中（但不是基于iOS），我使用过SVN。我转向Git的主要决定是分散的结构。
我将使用远程服务器作为中央Git存储库（很可能是Atlassian的bitbucket）。我还没有设置它，但与此同时我一直在本地测试Git。
我已经阅读了许多初学者资源，现在已经掌握了很好的基础知识，但有一件事我需要确认我理解得当。
在下面的示例中，我在Mac上使用了本地版本的Git。
我创建了一个名为 git_test 的本地git存储库。在这个存储库中，我有两个名为 file1 和 file2 的虚拟文件。我知道这是我的工作目录，其中包含我的实际文件（而不是blob）。
我也理解远程服务器上的中央存储库应该是裸的，不包含工作目录的实际文件。
假设我有两个用户（用户A和用户B）具有相同的本地存储库。
用户A
用户B
我是否正确地说新blob已上传到远程存储库中的 .git / objects 目录？
然后，当用户A和用户B在其本地系统上执行pull命令时，实际文件而不是blob将使用新blob的内容进行更新。这是对的吗？
抱歉这个冗长的问题。我希望一切都有道理。
答案 0 :(得分：0)
当您推送到远程仓库时，如果您的本地仓库落后于远程仓库，它将拒绝它
不确定是否能回答您的问题
这确保您不会尝试更改已更改的文件 - 它会强制您事先提取最新的更改
另外当你拉到你的本地仓库是的实际文件更改 - 在git repo中我相信它会创建一个新的差异文件iirc但我可能会弄错，我所知道的是它实际上并没有实际覆盖远程文件< / p>
答案 1 :(得分：0)
您不必过多担心裸存储库中的blob。更好的理解是每个存储库都由提交对象组成，这些对象在提交到该存储库时包含确切的文件结构。
在您的示例中，用户A在本地生成commitA，用户B在本地生成commitB，它们都基于裸存储库上的master，它指向提交对象（比如）commitBase。这意味着它们都具有commitBase的父级。
当A推动时，他将commitA推送到裸存储库，将主分支指针移动到commitA。有关file1的所有信息都在commit对象commitA中（以及有关文件结构其余部分的信息）。
在B推送之前，他必须首先将commitA的更改放入他的repo中，因为远程主分支指针不再指向commitBase。直到他在提交对象和分支指针上与远程同步时才能推送。因此，当他将commitA对象放入他的repo时，他将获得fileA作为其中的一部分，如果他执行pull或rebase，它将出现在他的文件系统中，但只会将commit对象放入他的存储库（而不是文件到他的工作目录）如果他取了一个。 Fetch仅使用新的提交对象在内部更新git，而无需更改自己的主分支指针。在合并/重新定位时，git将不得不对工作目录中的文件做出一些决定，比如公共文件是否容易合并，或者新文件是否可以放到磁盘上，或者是否太大冲突，您将不得不手动解决文件中的冲突。
在您的简单示例中，您没有冲突，因此您可以重新绑定并使commitA成为commitA2并具有commitB的父级，或者将commitA对象的父级合并并保留为commitBase，但是生成一个新的commitM对象，合并B和A的结果。
git内部如何在其.git / objects目录中表示这3个存储库中的任何一个目录在这一点上是无关紧要的。它可能正在压缩和移动内容以最大化其所有这些对象的数据库，但在尝试理解文件的提交对象如何工作时，我并不担心这一点。